글 쓰기에 앞서
아직 Kubernetes가 뭐 하는 녀석인지 모른다면 앞에 1편을 먼저 보고 오는 것을 추천한다.
https://hackerpark.tistory.com/entry/Kubernetes-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
[Kubernetes] 쿠버네티스란 무엇인가? (k8s 공부 - 1편)
글 쓰기에 앞서 최근 쿠버네티스와 직접적인 업무를 진행하면서 정리를 해야 한다고 매번 느꼈지만 미루고 미루다가 마음먹고 공부하는 내용들을 정리해서 기록하려고 한다. 처음 쿠버네티스
hackerpark.tistory.com
클러스터(Cluster)가 뭘까?
Kubernetes는 여러 서버를 하나의 논리적인 시스템으로 묶어서 통합적인 시스템 관리를 가능하게 해 준다.
이렇게 Kuberntes가 관리하는 하나의 논리적인 시스템 자체를 Cluster라고 부른다.
결국 Kubernetes가 곧 Cluster인 셈이다.
(공식 문서에서는 Kubernetes를 배포하면 Cluster를 얻을 수 있다고 적혀있다.)
클러스터의 구성 요소
Kubernetes는 위의 구성도에 나와있듯이 크게 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 구성되어 있는데, 이들의 가장 큰 목적은 Cluster를 통해 Container Application을 효율적으로 관리하는 것이라고 할 수 있을 것이다.
컨트롤 플레인과 워커 노드
컨트롤 플레인 (Control Plane)
- 과거 버전의 Kubernetes에서는 Master Node라고 정의되어 있었는데, Master-Slave를 쓰지 않는 추세에 맞춰 Kubernetes 1.20 버전부터 Control Plane으로 이름이 변경되었다.
Control Plane은 Cluster를 실질적으로 제어하고 작동시키는 Kubernetes의 관리자 역할을 하며, 한 Cluster내에 여러 Control Plane을 구성할 수 있다.
워커 노드 (Worker Node)
- 과거 버전의 Kubernetes에서는 Slave Node라고 정의되어 있었는데, Master-Slave를 쓰지 않는 추세에 맞춰 Kubernetes 1.20 버전부터 Worker Node로 이름이 변경되었다.
Worker Node는 Cluster에서 실제로 Container Application을 실행시키는 역할을 하며, 기본적으로 여러 Worker Node들이 모여 Cluster를 구성하고, Worker Node 하나가 여러 개의 Container Application들을 호스팅 한다.
그렇다면 효율적인 Container Application 관리 방법을 보기에 앞서 kubernetes가 여러 서버들을 논리적으로 묶은 Cluster에서 Container를 실행하는 과정을 간략하게 정리해 보았다.
위의 간략한 실행 과정을 토대로 시뮬레이션하면서 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node) 각각의 구성 요소가 어떤 동작을 하는지 알아보자.
또한 생략되어 있는 내용들에 대해서도 가볍게 정리를 해보려고 한다.
1. Container (App) 실행 요청 (kube-apiserver)
사용자가 Container App을 실행하려고 시도를 하는데 이러한 사용자와 통신을 하는 모듈이 kube-apiserver다.
kube-apiserver는 사용자, Control Plane 구성요소들과 통신하여 Cluster 내에서 모든 작업을 오케스트레이션 한다.
또한 Cluster의 상태를 모니터링하며 사용자 요구에 따라 전체 Node의 통제 및 관리를 담당하고 있다.
2. 실행할 서버 선택 (kube-scheduler)
kube-scheduler는 container(app)의 배포를 담당한다. Container가 특정 Worker Node에 배포가 가능한지 여부를 확인하면서 여러 가지 조건을 통해 실행할 Worker Node를 결정한다.
그리고 결정된 Worker Node에 Container(app)을 배포한다.
kube-scheduler가 Worker Node에 Container(app)의 배포를 결정하는데 확인하는 조건은 굉장히 많고 복잡하다.
여러 가지 조건에는 Container의 리소스 요구 사항, Worker Node의 사용가능한 리소스 용량, 여러 정책(policy)들과 제약 조건들, 테인트(Taint)와 톨러레이션(Toleration), 어피니티(Affinity) 등의 여러 rule이 있다.
이러한 rule들을 모두 체크하고 설정된 정책에 가장 알맞은 Worker Node를 식별하여 Container를 배포한다.
3. Container 실행 (kubelet & Container Runtime Engine)
kube-scheduler에 의해 결정된 Worker Node에 Container(App)이 배포된다.
Kubelet은 Worker Node 마다 설치되는 Agent로 kubelet 하나가 Worker Node 하나를 총괄하고 있다고 해도 과언이 아니다.
Kubelet은 Control Plane에 자신이 맡고 있는 Node와 Node에서 관리 중인 Container(app)의 상태 및 리소스 사용량을 주기적으로 보고하며, container의 보안과 로그, image 검증 등의 역할을 수행하고, Container(app)의 실행 및 삭제와 네트워크 설정 등 Worker Node에서의 관리자 역할을 수행한다.
Kubelet은 Container를 실행하기 위해서 Container Runtime Engine을 사용하기 때문에 각각의 Worker Node에는 Container를 실행하기 위해서는 Container Runtime Engine이 설치되어야 한다.
Container Runtime Engine에는 Docker, Containerd, CRI-O, rkt 등등 여러 종류가 존재하고 Kubernetes에서는 CRI(Container Runtime Interface)를 준수하는 모든 Engine이 사용가능하다. (이론상가능)
4. Container(app)들의 상태 데이터 관리 및 저장 (etcd)
Cluster가 다루는 모든 정보들은 엄청나게 많다. (Container가 몇 시에 어떤 Node에 적재됐는지, Node에는 어떤 Container들이 있는지, 각각의 Object의 상태나 변경점, Pod 같은 Clutser에 대한 meta 정보 등..)
etcd는 Cluster 내부에서 지속적으로 관리하는 데이터들을 key-value 형식으로 저장하는 database이다.
사용자가 kube-apiserver를 통해 이루어지는 행위나 얻을 수 있는 데이터는 대부분 etcd에 저장되어 있다고 생각하면 된다.
5. Container(app)과 구성요소들의 관리 (Controller Manager)
Controller Manager는 Cluster의 상태를 관리하고, Cluster가 원하는 상태로 유지하기 위한 작업들을 수행한다.
예를 들어 Worker Node가 연결이 제대로 되어있는지, 장애가 발생하진 않았는지 확인하고 관리하고 Container(app)의 복제본 수가 제대로 유지되고 있는지 체크하며 줄어들면 생성하고, 증가하면 줄여주는 작업을 통해 개수를 유지한다.
이 외에도 배포나 롤백, 각각의 Object들에 대한 상태유지를 위해 작업을 하기 때문에 상당히 넓은 범위의 업무를 수행하고 있다.
그렇기 때문에 Controller Manager는 단일 바이너리, 단일 프로세스로 실행되지만, 각자 맡은 Object들의 관리를 맡은 개별의 Controller로 구분 지어진다.
Replication Controller : Container(app)의 복제본 수를 지정된 수로 유지하는 역할을 하며 Container(app)의 확장성을 보장한다.
Deployment Controller : Container(app)의 버전에 따라 Roll Out & Roll Back을 관리하는 역할을 하며 롤백, 배포 전략을 통해 Container(app)의 안정성을 유지하고 지속적인 개발과 배포를 가능하게 한다.
StatefulSet Controller : 상태(State)를 가지는 Container(app)을 관리하는 역할을 하며 container(app)간에 의존성을 유지하면서 확장성과 안정성을 확보한다. (ex: database container)
Daemonset Controller : 배포 가능한 모든 Worker Node에 Container(app)을 배포하는 역할을 하며 Node가 추가되거나 제거될 때 자동으로 Container(app)을 생성하거나 제거하여 Cluster의 모든 Worker Node에서의 일관된 환경을 유지한다.
Job Controller : 일회성으로 실행된 Container(app)을 관리하는 역할을 하며 특정 작업(job)이 완료될 때까지 Container(app)을 실행하고, 성공 or 실패를 확인하여 설정된 정책으로 관리한다. 또한 완료된 job을 자동으로 정리하여 Cluster의 자원 효율을 증가시킨다.
사실 이 외에도 각각의 kubernetes에서 관리되는 object들 (service, configmap, volume, cronjob, ...) 등의 controller가 있지만 여기서 다룰 내용의 범위를 넘어가기 때문에 이는 이후 개별 object들의 정리를 하는 포스팅에서 다뤄볼 예정이다.
6. Cluster의 Network (kube-proxy)
kube-proxy는 Cluster의 Control Plane로부터 Worker Node에 전달되는 명령을 수신하는 역할을 담당하며, Network 정책을 적용하고 Container(app)간에 통신을 가능하게 해 준다.
또한 Container(app)간에 네트워크 트래픽의 로드밸런싱을 수행하여 네트워크 부하를 분산하고 서비스의 가용성과 성능을 향상한다. (Round-Robin, IP Hash 등의 로드밸런싱 알고리즘을 지원)
Cluster 내용 요약정리
컨트롤 플레인 (Control Plane) 구성 요소
- kube-apiserver : Cluster의 API서버로, kube-apiserver가 제공하는 RESTful API를 통해 인증과 권한을 처리하고, 인증된 사용자를 통해 cluster내로 요청된 작업을 처리한다. 각 Node의 kubelet을 통해 Cluster내의 리소스를 관리하고 스케쥴링, 이벤트 및 로깅등의 여러 작업들을 처리한다.
- kube-scheduler : Cluster 상태를 관리하고, Cluster가 원하는 상태로 유지하기 위해 동작한다. 여러 Controller를 통해 container(app) 상태를 모니터링하고 상황에 맞는 역할을 수행한다.
- kube-controller-manager : Cluster 상태를 관리하고, Cluster가 원하는 상태로 유지하기 위해 동작한다. 여러 Controller를 통해 container(app) 상태를 모니터링하고 상황에 맞는 역할을 수행한다.
- etcd : 분산된 key-value 형식의 database로 cluster의 상태 정보를 안정적으로 저장하고 관리하는 역할을 수행한다.
워커 노드 (Worker Node) 구성 요소
- kubelet : Cluster의 Worker Node에서 실행되는 Agent로 Worker Node의 Container(app)를 모두 관리하고 주기적으로 Control Plane에 Node와 Container들에 대한 정보를 보고함으로써 Worker Node의 핵심 관리자 역할을 수행한다.
- Container Runtime Engine : Kubelet이 Container를 실행하기 위해 사용하는 Runtime Engine으로 CRI(Container Runtime Interface)를 준수하는 Engine만을 Kubernetes에서 지원한다. (과거에는 Docker를 지원하기 위해 Docker-shim 이라는 모듈이 있었으나 관리적인 측면과 확장성의 문제로 인해 1.24 버전의 kubernetes에서부터는 사라졌다.)
- kube-proxy : Cluster의 네트워크를 담당하는 Agent로 Cotainer간에 통신과 네트워크 로드밸런싱을 수행하고, Node간의 통신을 담당하고 있다.
'Kubernetes > 이론' 카테고리의 다른 글
| [Kubernetes] 쿠버네티스란 무엇인가? (k8s 정리 - 1편) (2) | 2023.12.17 |
|---|