해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 25 - Kube-Nation: Exploring the Land of Kubernetes
원본 프레젠테이션에서는 'Kube-Nation'이라는 주제로, 쿠버네티스 클러스터의 구조를 하나의 국가에 비유하여 설명한다.
해당 글에서는 해당 비유를 생략하고 아키텍처를 구성하는 기술적 핵심 요소에 집중하여 내용을 정리하였음.
쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 실행하기 위한 노드의 집합이다.
클러스터는 크게 클러스터 전체를 관리하고 통제하는 컨트롤 플레인(Control Plane)과 실제 애플리케이션이 배포되어 동작하는 워커 노드(Worker Nodes)로 구성된다.
컨트롤 플레인은 클러스터의 상태를 관리하고, 모든 결정을 내리는 두뇌와 같은 역할을 한다.
사용자의 요청을 받아 워커 노드에 작업을 할당하고, 클러스터가 원하는 상태를 유지하도록 지속적으로 관리한다.
kube-apiserver: 클러스터의 유일한 진입점(Entrypoint) 역할을 하는 API 서버. 모든 상호작용은 이 API 서버를 통해 이루어지며, 클러스터의 상태를 변경하거나 조회하는 모든 요청을 처리하고 검증하는 역할
etcd: 클러스터의 모든 설정 데이터와 상태 정보를 저장하는 고가용성 키-값(Key-Value) 데이터베이스. (어떤 노드에 어떤 파드가 실행 중인지, 현재 클러스터의 상태는 어떤지 등의 모든 정보 기록 공간)
kube-scheduler: 새로 생성된 Pod를 어떤 워커 노드에 할당할지 결정하는 역할. (각 노드의 리소스 상태, 레이블, 제약 조건 등을 고려하여 가장 적합한 노드를 찾아 파드를 배치)
kube-controller-manager: 클러스터의 상태를 지속적으로 모니터링하고 원하는 상태로 유지하는 컨트롤러들의 집합. (ex. 특정 파드가 죽으면 이를 감지하고 새로운 파드를 생성하는 등의 작업을 수행하여 클러스터의 안정성을 보장)
워커 노드는 컨트롤 플레인으로부터 명령을 받아 실제 컨테이너화된 애플리케이션(파드)을 실행하는 작업 공간이다.
kubelet: 모든 워커 노드에 존재하는 에이전트. 컨트롤 플레인의 kube-apiserver와 통신하며, 자신에게 할당된 파드의 컨테이너들이 정상적으로 실행되고 건강한 상태를 유지하도록 관리하고 감독하는 역할
kube-proxy: 각 노드의 네트워크 규칙을 관리하고 통신을 담당하는 네트워크 프록시. 클러스터 내부 또는 외부로의 네트워크 트래픽을 라우팅하고, 서비스 (Service)를 통해 여러 파드에 대한 로드 밸런싱을 가능하게 함.
컨테이너 런타임 (Container Runtime): 실제로 컨테이너를 실행하는 소프트웨어로, Docker, containerd, CRI-O 등이 있으며, kubelet의 요청에 따라 컨테이너 이미지를 가져와 실행함.
파드 (Pod): 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위.
하나 이상의 컨테이너 그룹과 스토리지, 네트워크 속성 등을 공유하며, 일반적으로 하나의 파드는 하나의 애플리케이션을 의미함.
서비스 (Service): 여러 개의 파드에 안정적으로 접근할 수 있도록 고유한 IP 주소와 DNS 이름을 부여하는 네트워크 추상화 계층.
파드는 생성과 삭제가 빈번하여 IP가 계속 바뀌지만, 서비스는 해당파드 그룹에 대한 단일 진입점을 제공하여 안정적인 통신을 보장함.