쿠버네티스의 개념

  • 대표적인 도커 오케스트레이션 툴
    • 도커
    • 도커 컴포트
    • 도커 오케스트레이션
      • Clustering : 여러 개의 컨테이너를 합쳐 하나의 시스템으로 만들어 컨테이너를 배치
      • Auto-placement : 여러 개의 서버를 가지므로 어떤 컨테이너를 어떤 서버에 적절히 배치하는가
      • Auto-restart : 장애로 인해 컨테이너를 새로 띄운다.
      • 무중단 배포 : 신규 컨테이너를 배포할 때 중단 없이 배포한다.
  • 네임스페이스
    • 논리적인 클러스터
    • 개별적인 Access control 정책, 네트워크 정책
  • 리소스
    • Pod : docker container와 유사하다, 최소단위
    • Node : 서버
    • Sevice : 네크워크 담당
  • 앱 정의서
    • 리소스의 정의 (YAML 파일 형식 - 선언형 명령)
  • Desired State : 바라는 상태
    • 쿠버네티스는 현재 상태가 있고 바라는 상태로 가려한다.
    • YAML 파일로 바라는 상태를 수정 → 현재 상태가 바라는 상태로 변경됨 ⇒ 기존에 현재 상태가 여러가지 이유로 리소스가 삭제 되거나 바뀌어도 바라는 상태로 계속 바뀌게 되는 형식이다.
    • 이러한 방식으로 새로운 기능이 추가된다.
  • 라벨 & 셀렉터
    • 리소스에 label을 달 수 있다.
    • selector를 통해서 해당 라벨을 가지고 있는 리소스를 선택할 수 있다.

쿠버네티스의 아키텍처

  • 마스터 노드와 워커 노드가 존재
  • Master
    • kube-api-server
      • 쿠버네티스의 모든 컴포넌트와 통신하는 역할
      • 모든 컴포넌트의 리퀘스트를 받고 리스폰스 하는 역할
      • 워커노드와 다리 역할
    • etcd
      • api 서버로부터 들어온 데이터를 저장 및 제공해주는 역할
      • RDB가 아닌 Key-Value 형태의 데이터
      • 쿠버네티스 안의 모든 메타정보를 저장하고있다.
    • kube-scheduler
      • Auto-Placement 기능 : 어떤 노드가 가능한지 확인 (Scheduling)
    • kube-controller manager
      • current state와 desire state를 확인하며 달라지면 kube-scheduler를 통해서 리소스 관리
      • 루프를 통해서 지속적으로 확인
    • cloud-controller manager
      • public cloud를 사용하는 경우 통신 기능 제공
  • Woker
    • kubelet
      • kube-api-server로 부터 어떤 컨테이너를 실행해야 하는지 전달 받아 실제로 컨테이너를 실행한다.
      • 워커노드의 상태를 전달
    • kube-proxy
      • 컨테이너간의 네트워크를 담당

쿠버네티스의 장점

  • 컨테이너 스케줄링이 편리
  • Auto Scaling을 통해 확장성이 좋다
  • 모니터링이 쉬워진다.
  • 장애에 견고해진다.
  • Hybrid / 멀티 클라우드 구현 ( aws, google, micro azure, on-promise )

'BACK > MSA' 카테고리의 다른 글

[MSA] MSA 개요  (0) 2021.12.15

1. MSA 란?

 - Micro Service Architecture의 줄임말

 - 말 그대로 작은 단위의 서비스로, 독립적으로 관리, 배포 가능한 각각의 독립적인 기능을 제공하는 서비스 아키텍쳐를 의미한다.

 

2. MSA의 목표

 - 빠르게 개발해 지속적으로 배포할 수 있어야 한다.

 - 수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다.

 

3. MSA의 장점

 - 플랫폼의 각 서비스는 개별적으로 배포, 업그레이드할 수 있다. API 가 명확하기 때문에 다른 서비스의 수명 주기와 상관 없이 서비스를 업그레이드할 수 있다.

 - 플랫폼의 각 서비스를 다른 컴포넌트와 상관 없이 여러 서버로 Scale Out할 수 있어 고가용성 요구사항을 충족하거나 대용량 트래픽 처리하는데에 유용하다.

 - 각 서비스는 모듈화가 되어있고 각 모듈으느 Message Driven API 방식으로 통신하는데 이러한 방식은 빠른 개발과 쉬운 유지보수를 할 수 있게 한다.

 

4. MSA의 단점

 - 서비스의 새 인스턴스를 추가하려면 수동으로 로드밸런서를 구성하고 새 노드를 설정해야한다. 이 과정에서 오류가 발생하기 쉽다.

 - 통신하는 다른 시스템에서 오류가 발생했을 때 플랫폼 전체로 전이된다는 근본적인 문제가 있다.

 - 플랫폼 전체를 모니터링하는 과정이 훨씬 더 복잡하다.

 - 모든 서비스의 인스턴스 구성을 일관성 있게 최신 상태로 유지하는 작업에도 반복적인 수작업이 발생하며 이에 따른 품질 문제가 발생할 수 있다.

 - 테스트가 어렵다.

 

5. MSA의 전제 조건

 - 아무것도 공유하지 않는 아키텍처를 유지해야한다.

 - 명확한 인터페이스를 통해서만 통신해야한다.

 - 개별적인 런타임 프로세스로 배포해야 한다. (= 도커 컨테이너와 같이 독립된 런타임 프로세스로 실행해야한다.)

 

6. MSA의 디자인 패턴

 1) 서비스 검색 : 클라이언트가 마이크로서비스와 그 인스턴스를 찾을 수 있어야 한다.

  - 인스턴스는 자동으로 등록 및 등록 해지한다.

  - 요청사항은 사용가능한 인스턴스 중 하나로 라우팅된다.

 2) 에지 서버 : 일부 마이크로서비스만 외부에 공개하고 그외의 서비스는 외부에서 접근하지 못하도록 숨기는게 바람직하다.

 3) 리액티브 마이크로서비스

  - 논블로킹 I/O를 사용해 스레드가 할당되지 않게 한다.

 4) 구성 중앙화

  - 마이크로서비스 집합에 대한 구성 정보를 한 곳에 저장하고 환경별 설정을 지원한다.

 5) 로그 분석 중앙화

  - 각 서비스를 제공하는 인스턴스를 감지하고 로그를 한곳에 수집한다.

'BACK > MSA' 카테고리의 다른 글

[MSA] Kubernetes  (0) 2021.12.22

+ Recent posts