2. CKA udemy 강의 정리 - Section 2 [k8s 컴포넌트]

쿠버네티스 클러스터의 전체 구조

---

쿠버네티스 클러스터는 크게 두 종류의 서버로 구성되며, 모든 통신은 kube-apiserver 중심으로 이루어진다. 
특히, etcd에는 kube-apiserver만 접근이 가능하다. 

• Master Node : 클러스터 관리하는 곳
  • 보통 고가용성을 만족하고자 서버를 3대 정도 구성하여 운영함
    (클러스터를 안정적으로 운영하려면 마스터 서버 5대로 구성할수도 있음.)
• Worker Node(초기 minion이라 지칭) : 실제 컨테이너를 실행시키는 곳. 
  • 실제 사용하는 컨테이너 대부분은 노드에서 실행됨.

마스터 노드에도 워커 노드의 구성 컴포넌트들인 kubelet과 kube-proxy 가 존재한다.

 

쿠버네티스 컴포넌트

---

클러스터는 단일 컴퓨터가 아니라 여러대의 컴퓨터를 하나의 묶음으로 다루는 것을 의미하므로 여러가지 컴포넌트들을 가지고 있다.

• 마스터 컴포넌트 (Master Component, Control Plane Component) : 실제 클러스터 전체를 관리
• 노드 컴포넌트 (Node Component)  : 각 노드의 파드 실행을 관리하는 등의 쿠버네티스 실행 환경을 관리
• 애드온 (addon) : 필수는 아니지만, 클러스터 안에서 필요한 기능을 실행하는 파드 

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

1. etcd (엣시디)

• 쿠버네티스에서 필요한 모든 데이터를, 키-값 형태로 저장하는 데이터베이스
• 분산 시스템에서 노드 사이의 상태를 공유하는 raft 알고리즘(consenus 알고리즘)을 구현한 것.
• etcd는 서버 1개당 프로세스 1개만 사용 가능
• etcd 자체를 클러스터링한 후 여러개의 마스터 서버에 분산 실행하여 데이터 안정성을 보장하도록 구성하여 etcd에서 장애가 나타나고 시스템의 가용성 확보 가능 (때문에 안정적이지만 혹시 모를 클러스터 복구를 위해 백업을 권장 함) 
• etcd의 의미 : etcd는 약어가 아닌 리눅스의 구성 정보를 주로 가지고 있는 etc 디렉터리와 distributed(퍼뜨렸다)의 합성어. 구성 정보를 퍼뜨려 저장하겠다는 의미이다.

2. API 서버 (kube-apiserver)

• 쿠버네티스 클러스트의 중심 역할을 하는 통로
• 주로 상태 값을 저장하는 etcd와 통신하며, 쿠버네티스에 보내는 모든 요청은 kube-apiserver를 통해 다른 컴포넌트로 전달됨.
• 수평적 확장이 가능하므로 서버 여러 대에 여러개의 kube-apiserver를 실행해 사용할 수 있다. 

3. 컨트롤러 매니저 (kube-controller-manager)

• 쿠버네티스 클러스터의 오브젝트 상태를 관리, pod들을 관리하는 컨트롤러
• 컨트롤러 각각은 개별 프로세스지만, 복잡도를 줄이기 위해 모든 컨트롤러를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행됨.

4. 스케쥴러 (kube-scheduler)

• 현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해 새롭게 만든 파드를 실행함
• 파드를 조건(하드웨어, anti-affinity 만족 여부 등) 에 맞는 워커 노드에 지정하고, 파드가 워커 노드에 할당되는 일정을 관리하는 역할 

5. kubectl (큐브컨트롤)

• 쿠버네티스 클러스터에 명령을 내리는 역할. 
• 통상적으로 API 서버와 주로 통신하므로 이 자료에서는 API 서버가 위치한 마스터 노드에 구성되어있다.
• 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 바이너리(binary)로 배포되기 때문에 꼭 마스터 노드에 있을 필요는 없다.

노드 컴포넌트 (Worker Node)

5. kubelet(쿠블릿)

• 파드의 구성 내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링
• 노드 안에 있는 컨테이너더라도 쿠버네티스가 만들지 않은 컨테이너는 관리하지 않음

6. 컨테이너 런타임(CRI, Container Runtime Interface)

• 실제로 파드를 이루는 컨테이너를 실행시킴
• 예) 도커, containerd(쿠버 버전 1.10부터는 도커없이 기본 런타임으로 사용 가능), rinc 등등

7. 파드(Pod)

• 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인, 쿠버네티스 애플리케이션의 기본 실행 단위
• 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단함 
• 파드는 휘발성이며, 한 파드 내에 여러개의 컨테이너 존재 가능

8.kube-proxy

• 쿠버네티스 클러스터 내부에서 네트워크 요청을 전달하는 역할
• 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 통신할 수 있는 네트워크를 설정
• kube-proxy가 없었더라면 쿠버네티스 내부에 위치한 특정 파드로 요청을 보내기 위해 해당 파드의 정확한 IP를 알아야한다. 
  하지만 파드 IP는 파드가 배포될 때마다 매번 바뀌기 때문에 오브젝트를 통해 고정적으로 파드에 접근할 수 있도록 하는 방법을 
  제공하게 되는데 이를 관리하는 컴포넌트가 kube-proxy.

애드온 (addon)

9.네트워킹 애드온

10. DNS 애드온

11. 대시보드 애드온

12. 컨테이너 자원 모니터링

13. 클러스터 로깅

 

---

참고

1. https://www.samsungsds.com/kr/insights/kubernetes-3.html

2. https://kubernetes.io/docs/concepts/overview/components/#control-plane-components