❓쿠버네티스를 배포하면 클러스터를 얻는다. 클러스터 내부 구성요소를 알아보자
- 클러스터는 컨테이너화된 애플리케이션을 실행하는
Node라는 워커머신의 집합을 최소 1개 이상 가진다. - 배포 환경에서 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.
- 쿠버네티스 아키텍처를 이해하기 위해
_1. 컨트롤 플레인 컴포넌트
_2. 노드 컴포넌트
_3. kubectl
를 공부한다.
1. 컨트롤 플레인 컴포넌트 (마스터)
클러스터에 관한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응한다.
컨트롤 플레인 컴포넌트의 구성 요소
- Kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- cloud-controller-manager
Kube-apiserver
💡 쿠버네티스 컨트롤 플레인의 프론트엔드
- 쿠버네티스 API 서버의 모든 기능은
kube-apiserver이다. - 쿠버네티스 API 를 노출하고 내부,외부의 요청을 처리한다.
- 수평적으로 확장 가능해 더 많은 인스턴스를 배포, 확장할 수 있다.
- 여러 apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절 가능
etcd
💡 클러스터의 데이터 담당
- 모든 클러스터 데이터를 담는 쿠버네티스 디ㅜㅅ단의 저장소로 사용된다.
key-value저장소- 클러스터의 모든 설정, 상태 데이터는 etcd에 저장되고, 나머지 모듈은 모두 stateless 하게 동작하기 때문에 잘 백업해두면 언제든지 클러스터 복구 가능
- 오직 API 서버와 통신하고 다른 모듈은 API 서버를 거쳐 etcd 데이터에 접근
kube-scheduler
💡 파드 관리 담당
- 노드가 배정되지 않은 새로 생성된 파드 감지, 실행할 노드 선택해 할당
kube-controller-manager
💡 컨트롤러 프로세스를 실행
- 각 컨트롤러는 분리된 프로세스지만, 복잡성을 낮추기 위해 모두 단일 프로세스 내에서 실행된다.
- 오브젝트별로 철저하게 분업화되어 Deployment는 ReplicaSet을 생성하고, ReplicaSet은 Pod를 생성하고 Pod는 스케줄러가 관리
cloud-controller-manager
- 클라우드별 컨트롤 로직을 포함한다.
- 클라우드 컨트롤 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결한다.
2. 노드 컴포넌트
컨트롤 플레인 컴포넌트와 통신하며 동작 중인 파드를 유지시키고, 쿠버네티스 런타임 환경을 제공한다.
노드의 구성 요소는
- kubelet
- kube-proxy
- 컨테이너 런타임
kubelet
💡 각 노드에서 실행되는 에이전트
- 파드 스펙(PodSpec)의 집합을 받아 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실시 한다.
- 노드에 할당된 Pod의 생명 주기를 관리한다.
kube-proxy
💡 각 노드에서 실행되는 네트워크 프록시
- 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙을 통해 Pod가 내부 네트워크 세션이나 클러스터 바깥과의 통신을 할 수 있도록 한다.
컨테이너 런타임
- 컨테이너 실행을 담당하는 소프트웨어 ex) 도커
containered,CRI-O와 같은 컨테이너 런타임 및 모든Kubernetes CRI(컨테이너 런타임 인터페이스) 구현체를 지원한다.
3. Kubectl(Command line tool)
💡 컨트롤 플레인의 API 서버와 통신하기 위해 kubectl 이라는 명령행 도구를 사용한다.
- 컨트롤 플레인 내부 API 서버는 json 또는 protobuf 형식을 이용한 http 통신을 지원한다.
- apiserver와 쉽게 통신하기 위해 사용한다.
