[쿠버네티스 #2] ⚓쿠버네티스 아키텍처 (Control Plane/Node) 알아보기

쿠버네티스 컴포넌트는 컨트롤 플레인(Control Plane) 컴포넌트와 노드(Node) 컴포넌트로 나누어볼 수 있습니다.

 

 

컨트롤 플레인(Control Plane)	노드(Node) 컴포넌트
구성요소 API Server Scheduler Controller Manager etcd	구성요소 proxy kubelet

 

컨트롤 플레인(Control Plane) 컴포넌트

• 마스터 노드(Master Node)를 두어 컨트롤 플레인(Control Plane) 역할을 수행합니다.
• 쿠버네티스 클러스터의 기능 제어를 전체적으로 담당합니다.
• 모든 구성요소는 API Server로만 통신합니다. (Controller Manager가 etcd의 데이터를 변경하기 위해서는 API Server를 통해 요청을 보내야 합니다.)
• 해당 요소들은 개별적 프로세스로 동작합니다.
• 여러 노드에 컨트롤 플레인의 구성 요소 인스턴스를 다수 띄워 가용성을 향상할 수 있습니다.

 

kube-apiserver

• 안내 데스크처럼 쿠버네티스 클러스터로 들어오는 요청을 가장 앞에서 접수하는 역할을 합니다.
• 내부 및 외부 요청이 유효한지 판별하고 유효한 요청을 처리합니다.
• Kubernetes API를 노출하는 Kubernetes 제어 평면의 구성 요소입니다.
• etcd와 유일하게 통신하는 모듈로 상태를 바꾸거나 조회합니다.
• REST API 형태

 

etcd

• 쿠버네티스 클러스터가 동작하기 위해서 필요한 클러스터 및 리소스의 구성 정보, 상태 정보 및 명세 정보를 키-값형태로 저장하는 저장소입니다.
• 모든 클러스터 데이터에 대한 Kubernetes의 백업 저장소로 사용됩니다.
• 분산 시스템으로 구성해 고가용성을 확보합니다.
• 중요하기 때문에 백업 필수입니다.

쿠버네티스 배포판에서는 etcd대신 SQLite를 사용하기도 합니다.

 

 

kube-scheduler

• 할당된 노드가 없는 새로 생성된 pod을 감지하여 어떤 노드로 배치할지 결정하는 작업을 담당합니다.
• 노드 및 Pod의 각종 요구사항과 제약사항을 종합적으로 판단하는 역할을 합니다.
• 노드의 현재상태와 Pod의 요구사항을 체크합니다.

 

kube-controller-manager

• API 서버 감시 기능을 통해 클러스터의 상태를 감시하고 클러스터를 원하는 상태로 이동하도록 변경합니다.
• 논리적으로 다양한 컨트롤러가 존재합니다.
• 스케줄러를 참고하여 정확한 수의 포드가 실행되게 합니다.(끊임없이 상태를 체크해 원하는 상태를 유지)
• 논리적으로는 분리되어있지만 복잡성을 낮추기 위해 단일 바이너리로 컴파일되어 단일 프로세스 내에서 실행됩니다.

 

 

 

노드(Node) 컴포넌트

• 컨트롤 플레인 컴포넌트의 요청을 받아 각 노드에서 동작을 담당합니다.
• Matser와 통신 시 apiserver만 바라봅니다.

 

kubelet

• 노드에서 컨테이너가 동작하도록 관리해 주는 핵심 요소입니다.
• YAML을 쿠버네티스 클러스터에 적용하기 위해 kubectl 명령어를 사용할 때, 이 YAML이 kube-apiserver로 전송된 후 kubelet으로 전달됩니다. kubelet은 이 YAML을 통해 전달된 Pod을 생성 혹은 변경하고, 이후 이 YAML에 명시된 컨테이너가 정상적으로 실행되고 있는지 확인합니다.
• 각 노드에서 실행됩니다.

 

Proxy

• 네트워크 프록시와 부하 분산 역할을 합니다.
• 쿠버네티스는 Pod IP가 매번 바뀌는데서 오는 어려움을 해결하기 위해 오브젝트를 통해 고정적으로 Pod에 접근할 수 있도록 하는 방법을 제공합니다.
• iptables 또는 IPVS 방식을 사용합니다. (설정만 관리)

 

Container Runtime

• Pod에 포함된 컨테이너 실행을 실질적으로 담당하는 애플리케이션

 

 

 

 

Desired State

• 현재 상태와 원하는 상태를 계속 체크하고 문제가 있다면 자동으로 조치(현재 상태를 원하는 상태로 변경)합니다.
• 기본적인 쿠버네티스의 구동 원리의 핵심
• 내부적으로 Scheduler / Controller / Kubelet 모두 이러한 cycle을 통해 etcd에 있는 데이터가 변경되면 감지

 

 

 

조회 흐름

조회 발생 흐름

1. 정보 조회: Controller가 체크하고 있는 상태를 조회할 때 API Server에 물어본다.
2. 정보 조회 권한 체크: API Server는 요청 Controller가 해당하는 Resource를 볼 수 있는지 권한 체크 후, etcd에 정보 조회를 하고 Controller에 알려주게 된다.

 

상태 변경 흐름

1. 원하는 상태 변경: API Server는 Controller에게 원하는 상태 변경에 대한 전달을 한다.
2. 원하는 상태로 리로스 변경: 조치를 통해 리소스 변경
3. 변경 사항 전달: API Server에게 변경 사항 전달
4. 정보 갱신 권한 체크: 조회가 아닌 변경 권한이 있는지 체크
5. 정보 갱신: etcd에 정보 갱신

 

하나의 Pod 생성 과정

1. 관리자가 API Server에 Pod요청
2. 요청 받은 API Server는 etcd에 Pod 요청을 기록
3. 새 Pod을 계속 체크하는 Controller에 의해 확인
4. Controller가 API Server에게 Pod 할당 요청
5. API Server는 etcd에 Pod 할당 요청으로 상태 변경
6. 계속 할당 요청 확인 하는 Scheduler에 의해 확인
7. Scheduler가 API Server에게 Pod 특정 노드 할당
8. API Server는 etcd에 Pod 특정 노드 할당, 미실행 상태로 업데이트
9. Kubelet이 노드 중 미실행 Pod 확인
10. Kubelet이 Pod 생성
11. API Server가 etcd에 Pod 생성 업데이트, Pod 특정 노드 할당, 실행중 상태

 

 

 

---

쿠버네티스 알아보기 3편: 쿠버네티스를 이루고 있는 여러 가지 구성 요소