2024. 3. 3. 20:14ㆍBACKEND
본 포스팅은 Kubernetes Architecture 를 이해하고 구성 요소들의 개념과 역할을 이해하는 것을 목표합니다.
🔗 Kubernetes Series
모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.
본 포스팅에서는 Kubernetes 혹은 K8s 을 살펴보려 합니다.
이론과 실습 중 무엇이 선행되어야 할지 생각해봤을 때,
제 기준에서 Kubernetes는 개념 정도만 먼저 알아보고, 실제로 사용해보며 깊이 들어가는 것이 좋지 않을까 싶습니다.
어떤 역할을 하는, 왜 생겨난 서비스인지를 파악한 후, 무작정 따라해보고 이유를 찾아가며 배우면 좋을 듯 합니다.
그럼 지금부터 쿠버네티스 아키텍처에 대한 전반적인 내용을 살펴보도록 하겠습니다.
Kubernetes의 목적은 컨테이너들을 배포 및 운영 스팩을 미리 정의해두어
자동 배포, 스케일링, 관리할 목적의 오픈 소스 시스템입니다.
TL;DR
Kubernetes의 클러스터에는 아래와 같이 여러 개의 구성 요소가 있습니다.
요약하자면, 가장 상위 개념으로, Master Node와 Worker Node가 있습니다.
쿠버네티스에서, 각각을 Control Plane 과 Data Plane으로 부를 수 있습니다.
Master Node에는 클러스터에 대한 정보를 저장하는 etcd가 있습니다.
Node에서 애플리케이션이나 컨테이너 스케쥴링을 담당하는 Kube-scheduler 이 있습니다.
Node Controller, Replication Controller 등 다양한 기능을 처리하는 다양한 Controller가 있습니다.
클러스터 내의 모든 작업을 컨트롤하는 역할을 하는 Kube API 서버가 있습니다.
Worker Node에는 Kube API 서버의 명령에 따라 컨테이너를 관리하는 Kubelet과,
클러스터 내의 서비스 간 통신을 가능하게 하는 Kube Proxy가 있습니다.
Architecture
Kubernetes의 클러스터에는 아래와 같이 여러 개의 구성 요소가 있습니다.
Control Plane / Master Node
- Etcd
- Scheduler (kube-scheduler)
- Controller Manager
- Kube API Server
Data Plane / Worker Node
- kubelet
- kube-proxy
Container Runtime Engine
위 다이어그램을 보면 복잡해 보여서 덜컥 포기하고 싶어질 수 있는데요.
쉬운 이해를 위해, 각 요소를 실제 화물선 운반과 비교해 보도록 하겠습니다.
두 개의 화물선이 있다고 가정해봅시다. 각 화물선에는 많은 컨테이너들을 싣고 있습니다.
Master Node
컨테이너를 어느 화물선에 실을 지, 혹은 화물선들의 방향을 조정하고 모니터링 등의 관리를 위한 모선(mastership)이 필요합니다.
이 관리는 다른 화물선들과는 다른 공간에서 구별되어 운영되곤 하는데,
Container 관리 시의 Master Node와 동일합니다.
이처럼 관리를 위한 Master Node는 쿠버네티스 클러스터를 관리하는 Controle Plane의 역할과 동일합니다.
서로 다른 노드에 대한 정보를 저장하거나, 컨테이너를 배치 시키고, 노드와 컨테이너들을 모니터링합니다.
Etcd
수 많은 컨테이너들이 운행될 경우, 몇개의 화물선에 얼마나 많은 컨테이너가 있는지에 대한 정보가 필요한데요.
이 모든 정보는 ETCD 라는 높은 가용성의 key-value 스토리지에 저장됩니다.
추후 이어질 포스팅에서, Etcd에 어떤 데이터가 어떠한 방식으로 저장되는지 알아볼 필요가 있습니다.
Kube-scheduler
모선(mastership)에 있는 컨테이너들을 화물선에 할당할 때, 크레인을 사용해서 컨테이너를 옮깁니다.
이 크레인은 특정 컨테이너가 어떤 화물선에 배치되어야 하는지를 식별할 수 있습니다.
가령, 해당 화물선의 수용량이나 특정 화물선에 이미 선박된 컨테이너가 몇 개 있는지,
혹은 화물선의 목적지, 운반 가능한 타입인지 등의 조건들을 이미 알고 있는 것이죠.
바로 이 크레인이 kube-scheduler 의 역할입니다.
쿠버네티스에서 스케쥴러는 큰 역할을 담당하기 때문에,
추후 포스팅에서 스케쥴 과정에 대한 내용을 깊이 파는 시간을 갖겠습니다.
Controller Manager
이 모선(mastership)에는 또한, 특정 운영에 특화된 업무를 맞는 부서들이 있습니다.
가령, 운영 부서는 각 화물선의 화물 수를 조정하거나, 트래픽을 통제하는 등의 일들을 합니다.
어떤 팀은 이슈를 처리하거나 경로에 맞는 화물선으로 경로를 조정하는 등의 일들을 처리하곤 합니다.
쿠버네티스에서도 비슷하게 서로 다른 영역 들에 특화된 컨트롤러들이 존재합니다.
가령, Node Controller는 노드를 관리합니다. Replication Controller들은 레플리케이션 그룹에 동시에 할당되어야 하는 개수(desired number)에 맞춰 새로운 노드들을 클러스터에 할당하거나 제거합니다.
Kube API Server
그런데, 지금까지 쿠버네티스 클러스터의 Master Node 내 컴포넌트들은 어떻게 서로에게 정보나 상태를 전달할까요?
Kube API 서버가 바로 이 커뮤니케이션의 중추가 됩니다.
Kube API 서버는 클러스터 내 모든 오퍼레이더들을 오케스트레이팅합니다.
외부 사용자들에게 Kubernetes API를 노출시켜,
워커 노드들이 해당 서버와 커뮤니케이션할 수 있게 하여 클러스터의 운영을 관리합니다.
클러스터의 상태를 모니터링하기 위해 요구되는 필요한 변경 사항을 반영합니다.
Container Runtime Engine
이렇게 쿠버네티스 세상에서는 모든 것들이 컨테이너로 동작합니다.
그래서 모든 환경 또한 컨테이너에 맞게 동작되게 됩니다.
전체 시스템을 관리하기 위한 형식의 서로 다른 컴포넌트들은 컨테이너의 형식으로 호스팅될 수 있습니다.
또, DNS 서비스 또한 컨테이너 형식으로 배포됩니다.
이 모든 컨테이너들을 실행시킬 소프트웨어가 필요한데, 바로 컨테이너 런타임 엔진입니다.
대표적으로 Docker가 있습니다.
그래서 쿠버네티스 클러스터들의 모든 노드들이 컨테이너 환경에서 실행되기 위해 Docker가 필요한 것입니다.
만약 컨테이너로 실행시키길 원한다면 Master Node 또한 포함된 환경을 말합니다.
쿠버네티스는 Docker 뿐만아니라 다른 Runtime Engine으로 Container 나 Rocket 등을 지원합니다.
Worker Node
이 번엔, 각각의 화물선에 조금 더 집중해보도록 하겠습니다.
kubelet
모든 화물선에는 선장이 있습니다. 선장은 이 화물선의 모든 이벤트들을 관리합니다.
선장의 주요 임무는 모선(mastership)과 통신하며 모선에게 다른 그룹에 합류할 의사나,
해당 화물선에 적재되는 컨테이너들에 대한 정보를 받는다거나,
적절한 컨테이들이 필요 시 적재할 수 있는지를 알려주고 해당 화물선이나 컨테이너 들에 대한 상태에 대한 보고를 마스터로 부터 받습니다.
쿠버네티스의 kubelet이 바로 쿠버네티스 내의 선장의 역할입니다.
kubelet은 클러스터 위의 각 노드에서 실행되는 Agent입니다.
Kube API 서버로부터 오는 지시 사항을 듣고, 필요할 때 컨테이너를 배포하거나 제거합니다.
Kube API 서버는 주기적으로 노드의 상태나 해당 노드의 컨테이너의 상태를 모니터하기 위해 kubelet으로 부터 상태값을 가져옵니다.
Kube Proxy Service
하지만, Worker node에서 실행되고 있는 애플리케이션은 종종 다른 Worker Node와 통신하고 싶어질 수 있습니다.
가령, 웹 서버가 한 컨테이너에서 실행될 때 다른 워커 노드에서 실행 중인 데이터베이스와 연결하고 싶을 때가 있죠.
Kube Proxy Service는 Worker Node에서 실행 중인 컨테이너가,
서로 통신할 수 있도록 작업자 노드에 필요한 규칙이 있는지 확인합니다.
그럼 다음에는 각 구성 요소를 더욱 상세한 내용으로 소개하는 포스팅으로 만나뵙겠습니다.
| Ref. |
🔗 Udemy: certified-kubernetes-administrator-with-practice-tests
'BACKEND' 카테고리의 다른 글
| Kubernetes Taints & Tolerations, 제대로 이해하기 (1) | 2024.03.24 |
|---|---|
| Kubernetes Deployment, 제대로 이해하기 (0) | 2024.03.17 |
| Redis ZSET, 제대로 이해하기 (1) | 2023.12.27 |
| Kubernetes Architecture, 제대로 이해하기 - Control Plane (2) | 2023.11.22 |
| Docker Swarm, 제대로 이해하기 - Swarm & Service (2) | 2023.10.30 |
Backend Software Engineer
𝐒𝐮𝐧 · 𝙂𝙮𝙚𝙤𝙣𝙜𝙨𝙪𝙣 𝙋𝙖𝙧𝙠