🧭 클러스터 구조 개요
Kubernetes 클러스터는 크게 두 영역으로 나뉩니다:
- Control Plane (제어 플레인): 클러스터의 브레인 역할
- Worker Node (작업 노드): 실제 컨테이너가 돌아가는 환경
이 두 영역이 상호작용하며 클러스터 전체의 상태를 유지합니다.
⚙️ 제어 플레인 구성요소 분석
1. kube-apiserver
- 클러스터의 진입점으로, 모든 명령은 API Server를 통해 전달됩니다.
- 인증/인가, 요청 유효성 검사, 상태 저장 등 다양한 역할 수행
- 실무 팁:
kubectl커맨드는 모두 여기로 향합니다. API latency 모니터링 중요
2. etcd
- 클러스터의 상태 정보를 저장하는 분산 키-값 저장소
- 모든 리소스 상태 (파드, 서비스, 설정 등) 가 저장됨
- 실무 팁: 고가용성 구성 필수. 백업 전략 반드시 수립해야 함
3. kube-scheduler
- 스케줄링되지 않은 Pod를 찾아 적절한 노드에 할당
- 리소스 상황, taint/toleration, affinity 등을 고려함
- 실무 팁: 커스텀 스케줄러를 붙여 특정 워크로드를 별도 노드로 분리 가능
4. kube-controller-manager
- 컨트롤러 집합체로, Deployment, Node, ReplicaSet 등 관리
- 선언적 상태 유지의 핵심
- 실무 팁: 실제 문제의 원인을 트래킹할 때 컨트롤러 로그 확인 필수
5. cloud-controller-manager (선택적)
- AWS, GCP 등 퍼블릭 클라우드 리소스와의 통합 역할
- 노드 등록, 로드밸런서 관리 등
- 실무 팁: 클라우드 환경에서만 사용되며, bare-metal에는 필요 없음
🖥️ 노드 구성요소 분석
1. kubelet
- 각 노드에 존재하며, 해당 노드의 Pod가 제대로 동작하는지 주기적으로 체크
- 컨테이너 런타임과 직접 통신
- 실무 팁: 상태 불량 시 kubelet 로그 (
/var/log) 확인이 빠른 진단에 유용
2. kube-proxy
- 각 노드의 네트워크 규칙 설정 및 서비스 IP 라우팅 처리
- iptables 또는 IPVS 기반으로 동작
- 실무 팁: 네트워크 이슈 시 가장 먼저 살펴볼 요소
3. Container Runtime
- 컨테이너 실행의 실질적 엔진 (예: containerd, CRI-O)
- kubelet이 이 런타임을 통해 컨테이너를 구동
- 실무 팁: 도커는 deprecated 됨. containerd로 전환하는 것이 표준화 추세
🧩 Addons (클러스터 기능 확장)
- CoreDNS
- 클러스터 내 DNS 서비스 제공
- 서비스 이름으로 통신이 가능하게 만듦
- Dashboard
- 웹 UI를 통한 클러스터 시각화 관리
- Metrics Server / Prometheus
- 자원 사용량 모니터링
- EFK / Loki
- 중앙 집중식 로그 수집 및 분석
⚒️ 실무 적용 포인트
kube-apiserver의 SLA는 전체 클러스터 가용성과 직결됨 → 장애 대응 프로세스 마련etcd백업/복구 시나리오 정립 → 사고 발생 시 복구 속도에 결정적- 노드 단의 kubelet 이슈는 대부분 컨테이너 실행 문제로 이어짐 → 사전 모니터링 중요
👨🏻💻 Backend Developer