쿠버네티스는 사람이 관리하는 것을 자동화해주고, 다양한 업체의 노하우가 모여있는 시스템이다.
쿠버네티스 아키텍처
Desired State : 상태 체크(Observe) -> 차이점 발견(Diff) -> 조치(Act)
쿠버네티스는 시스템 내부적으로, 상태를 체크하고 차이점을 발견한다. 예를 들어, 컨테이너가 1개 떠있어야 하는 상황이라면, 실제로 1개가 정상적으로 떠 있는게 맞는지 체크를 한다. 만약에 차이점을 발견하면(Diff), 이를 조치(Act)하는 Loop를 지속적으로 수행한다.
쿠버네티스에서는 이러한 Desired State를 유지하기 위해서 다양한 구성요소가 있다. 크게 1) 마스터와 2) 노드가 있으며, 세부 요소에는 아래와 같은 구성요소가 존재한다.
마스터: Scheduler, Controller, etcd, API server
노드 : Proxy, Kubelet
마스터 - etcd
- 모든 상태와 데이터를 저장
- 분산 시스템으로 구성하여 안정성을 높임(고가용)
- 가볍고 빠르면서 정확함(일관성)
- Key-value 형태로 데이터 저장
- 모든 상태가 저장되어 있기 때문에 백업은 필수
마스터 - API server
- etcd의 상태를 바꾸거나 조회 하는 것
- etcd와 유일하게 통신하는 모듈
- REST API 형태로 제공
- 내부 모듈(컨트롤러, 스케쥴러)와 통신
마스터 - Scheduler
- 새로 생성된 Pod을 감지하고, 실행할 노드를 선택
- 노드의 현재 상태와 Pod의 요구사항을 체크
- 즉, 어떠한 노드에 어떠한 컨테이너를 생성할지 감지하고 있음
마스터 - Controller
- 끊임 없이 상태를 체크하고 원하는 상태(Desired State)를 유지함
- 즉, Loop가 계속해서 돌아가면서 상태 변화를 채크함
마스터 이외에, 노드는 크게 2개의 컴포넌트가 존재한다. 마스터와 통신을 할 때, API Server만을 바라보며, Kubelet은 Pod을 실행 및 중지하고 상태를 체크한다.
노드 - Proxy
- 네트워크 프록시와 부하 분산 역할
- iptables 또는 IPVS를 사용 (설정만 관리)
노드 - Kubelet
- Kubelet은 Pod을 실행/중지하고 상태를 체크하기 때문에, 각 Pod마다 존재한다.
이러한 것을 모두 통합하여 다시 흐름을 보면 아래와 같다.
시나리오 체크
- (0) 관리자가 Pod을 API server에 요청
- (1) API server는 etcd에 "Pod-생성요청"을 입력
- (2) 컨트롤러가 새로 생긴 Pod이 있는지 계속 체크하면서, Pod-생성요청을 확인
- (3) 컨트롤러가 Pod-생성요청을 API server에 요청하고, API server는 etcd에 Pod 할당 요청이라는 상태로 변경
- (4) Scheduler는 Pod 할당이 존재하는 것을 발견하고, 여러개 노드 중에서 어디 생성할까 체크하고, 특정 노드에 Pod을 할당함. 이후, API server가 할당 정보를 다시 받아서 etcd에 노드 할당이라고 업데이트
- (5) Kubelet이 노드에 할당된 Pod 중에 미실행 Pod을 파악하고 실행하며, 정보를 API Server가 etcd에 업데이트
'블로그 > 데이터 엔지니어링' 카테고리의 다른 글
[K8s] Pod & ReplicaSet & Deployment (0) | 2024.01.18 |
---|---|
[K8s] 왜 쿠버네티스일까? (0) | 2024.01.17 |
[k8s] 컨테이너 오케스트레이션 등장과 개념 (0) | 2024.01.17 |
GA4와 Bigquery로 행동 로그 쌓기 삽질하며 배운 점 (0) | 2022.05.22 |