[CKA] 1. Cluster Architecture
[CKA] 1. Cluster Architecture — #CKA #쿠버네티스 #개발자의도구들 #ClusterArchitecture #쿠버네티스클러스터 kubernetes의 목적 애...
#CKA #쿠버네티스 #개발자의도구들 #ClusterArchitecture #쿠버네티스클러스터
kubernetes의 목적
애플리케이션을 컨테이너 형태로 자동화된 방식으로 호스팅하여 필요한 만큼의 애플리케이션의 인스턴스를 쉽게 배포하고 애플리케이션 내의 서비스간에 쉽게 통신할 수 있도록 하는 것입니다.
Cluster Architecture
화물선: 워커노드(Worker Node)
항구에서 실제로 컨테이너를 싣고 목적지까지 운반하는 것은 화물선입니다. 화물선은 관제센터의 지시에 따라 정해진 규격의 컨테이너를, 정해진 수량만큼, 정확한 목적지로 운송합니다.
쿠버네티스에서는 이 화물선을 워커노드라고 부릅니다. 워커노드는 실제 애플리케이션 컨테이너가 실행되는 공간으로, 온프레미스 환경의 물리 서버나 클라우드의 가상 머신이 이에 해당합니다.
kubelet: 각 화물선의 선장
각 화물선에는 선장이 있습니다. 선장은 중앙 통신탑(kube-apiserver)과 교신하며 지시를 받고, 배의 상태를 보고합니다. 이 선장의 역할을 하는 것이 바로 kubelet입니다.
💡 핵심: kubelet은 반드시 kube-apiserver를 통해 마스터노드와 통신합니다.
직접 etcd나 다른 컴포넌트에 접근하지 않습니다.
관제센터: 마스터노드(Master Node)
화물선이 단순히 짐을 나르는 역할이라면, 항만관제센터는 훨씬 복잡한 임무를 수행합니다. 어떤 배에 어떤 화물을 실을지 결정하고, 운항 일정을 조율하며, 모든 선박의 상태를 감시합니다. 문제가 생기면 즉시 대응하고, 이 모든 정보를 기록으로 남깁니다.
쿠버네티스에서는 이를 마스터노드라고 부르며, 역할에 따라 여러 컴포넌트로 나뉘어 있습니다.
마스터노드 컴포넌트의 배치
기본적으로 마스터노드의 핵심 컴포넌트들(kube-apiserver, kube-scheduler, kube-controller-manager, etcd)은 동일한 마스터 노드에서 함께 실행됩니다. 별도의 노드로 분리되어 있지 않습니다.
단, 고가용성(HA) 환경에서는 다음과 같이 구성할 수 있습니다.
- 여러 마스터 노드에 컴포넌트를 복제하여 분산 배치
- etcd를 별도의 클러스터로 분리 (External etcd topology)
마스터노드 내부의 통신 규칙
마스터노드 내에서도 컴포넌트 간 통신은 명확한 규칙을 따릅니다.
- kube-scheduler → kube-apiserver를 통해 통신
- kube-controller-manager → kube-apiserver를 통해 통신
- kubelet → kube-apiserver를 통해 통신
- kube-apiserver → etcd에 직접 접근 (유일하게 etcd와 통신 가능한 컴포넌트)
마스터노드 컴포넌트 상세
etcd: 운항일지 보관소
모든 선박의 출항 기록, 적재 화물 목록, 항해 경로가 빠짐없이 기록되는 보관소입니다. 언제, 어떤 배가, 어디로, 무엇을 실어 날랐는지 모든 정보가 이곳에 저장됩니다.
etcd는 클러스터의 모든 상태 정보를 key-value 형태로 저장하는 분산 데이터 저장소입니다. 노드 정보, Pod 상태, 설정값 등 클러스터 운영에 필요한 모든 데이터가 이곳에 보관됩니다.
kube-scheduler: 배차 담당관
새로운 화물이 들어오면 어떤 배에 실을지 결정해야 합니다. 배차 담당관은 각 선박의 현재 적재량, 목적지, 운항 일정을 고려해 최적의 배를 선정합니다.
kube-scheduler는 새로 생성된 Pod를 어떤 노드에 배치할지 결정합니다. 노드의 리소스 상황, 제약 조건, 친화성 규칙 등을 종합적으로 고려해 가장 적합한 노드를 선택합니다.
kube-controller-manager: 운항 감독부
여기서부터 조금 더 자세히 살펴봐야 합니다. 항만관제센터에는 단순히 한 명의 감독관이 있는 것이 아니라, 여러 전문 감독관으로 구성된 운항 감독부가 있습니다. 선박 상태를 점검하는 감독관, 화물 수량을 관리하는 감독관, 각자의 전문 영역이 있죠.
kube-controller-manager는 이런 여러 컨트롤러를 하나의 프로세스로 묶어 실행하는 컴포넌트입니다. 내부에는 다양한 컨트롤러가 포함되어 있습니다.
Node Controller: 선박 상태 감독관
각 화물선이 정상적으로 운항 중인지 감시합니다. 배가 응답하지 않거나 항로를 이탈하면 즉시 감지하고 조치를 취합니다.
- 노드의 상태를 주기적으로 모니터링
- 노드가 응답하지 않으면 NotReady 상태로 표시
- 일정 시간 복구되지 않으면 해당 노드의 Pod를 다른 노드로 재스케줄링
Replication Controller: 화물 수량 감독관
"이 화물은 반드시 3개 배에 나눠 실어라"라는 지시가 있다면, 항상 그 수량을 유지해야 합니다. 배 한 척이 침몰하면 즉시 다른 배에 화물을 옮겨 실어 수량을 맞춥니다.
- 지정된 수의 Pod 복제본이 항상 실행되도록 보장
- Pod가 삭제되거나 실패하면 새로운 Pod를 생성
- Pod가 초과되면 삭제하여 원하는 수량 유지
그 외 주요 컨트롤러
kube-apiserver: 중앙 통신탑
항구의 모든 통신은 중앙 통신탑을 거칩니다. 배차 담당관이 선장에게 지시를 내릴 때도, 감독관이 선박 상태를 확인할 때도, 보관소에 기록을 남길 때도 모두 이 통신탑을 통합니다. 직접 연락하는 법은 없습니다.
kube-apiserver는 쿠버네티스의 모든 컴포넌트가 통신하는 단일 창구입니다.
- REST API를 제공하며, 인증과 권한 검사를 수행
- etcd와의 유일한 통신 경로 역할
- kubectl 명령어도 이 API 서버를 통해 클러스터와 상호작용
- scheduler, controller-manager, kubelet 모두 apiserver를 통해서만 정보를 주고받음
통신 흐름 정리
| 출발 | 목적지 | 경로 |
|---|---|---|
| kubelet | etcd (상태 저장) | kubelet → apiserver → etcd |
| scheduler | etcd (Pod 배치 정보) | scheduler → apiserver → etcd |
| controller-manager | etcd (상태 조회/변경) | controller → apiserver → etcd |
| kubectl (사용자) | 클러스터 | kubectl → apiserver → 각 컴포넌트 |
마치며
쿠버네티스라는 이름 자체가 그리스어로 '조타수' 또는 '항해사'를 뜻합니다. 컨테이너라는 이름도 실제 해운 컨테이너에서 따온 것이죠. 이처럼 쿠버네티스의 설계 철학 자체가 항구와 선박의 운영 방식에서 영감을 받았습니다.
복잡해 보이는 쿠버네티스 아키텍처도 이렇게 항구의 모습으로 바라보면 각 컴포넌트의 역할과 관계가 자연스럽게 이해됩니다. 특히 기억해야 할 핵심은 다음과 같습니다.
- 모든 통신은 kube-apiserver를 통한다 (etcd 직접 접근 제외)
- kube-controller-manager는 여러 컨트롤러의 집합이다
- kubelet은 워커노드에서 실행되며, apiserver를 통해 마스터와 통신한다