한 줄 요약
쿠버네티스 공식 문서의 개념 첫머리에 놓인 짧은 개요 페이지다. 클러스터가 어떤 부품들로 이뤄지는지를 컨트롤 플레인·노드·애드온 세 묶음으로만 갈라 보여 준다.
핵심 내용
- 클러스터의 뼈대는 두 갈래다. 클러스터는 컨트롤 플레인 하나와 워커 노드 하나 이상으로 구성된다. 문서가 "핵심 컴포넌트"라는 제목 아래 가장 먼저 못 박는 문장이다.
- 컨트롤 플레인 5개 —
kube-apiserver(쿠버네티스 HTTP API를 노출하는 핵심 서버),etcd(모든 API 서버 데이터를 담는 일관성·고가용성 키-값 저장소),kube-scheduler(아직 노드에 할당되지 않은 파드를 찾아 적절한 노드에 배정),kube-controller-manager(컨트롤러를 실행해 API 동작을 구현),cloud-controller-manager(클라우드 공급자와 통합, 선택 사항). - 노드 컴포넌트 3개 —
kubelet(파드와 그 안 컨테이너가 실행 중임을 보장),kube-proxy(노드의 네트워크 규칙을 유지해 서비스를 구현, 선택 사항), 컨테이너 런타임(컨테이너 실행을 담당하는 소프트웨어). - 노드에는 쿠버네티스 밖 소프트웨어도 필요할 수 있다. 문서는 리눅스 노드가 로컬 컴포넌트를 관리하려고 systemd를 함께 돌리는 경우를 예로 든다.
- 애드온 4가지 예시 — DNS(클러스터 전반의 DNS 해석), 웹 UI 대시보드(웹 인터페이스로 클러스터 관리), 컨테이너 리소스 모니터링(컨테이너 메트릭 수집·저장), 클러스터-레벨 로깅(컨테이너 로그를 중앙 저장소에 보관). 애드온은 쿠버네티스 "기능을 확장"하는 자리다.
- 아키텍처는 고정돼 있지 않다. 이 컴포넌트들을 어떻게 배포하고 관리할지는 유연하다. 소규모 개발 환경부터 대규모 프로덕션까지 요구에 맞춰 조정된다는 말로 문서는 페이지를 닫는다.
주요 주장 / 데이터
cloud-controller-manager와kube-proxy에는 "(선택 사항)"이 명시돼 있다. 흔히 "쿠버네티스 필수 부품 8개"로 외우지만 공식 문서 기준으로 이 둘은 조건부다. 클라우드 위가 아니면 CCM은 없어도 된다. 서비스 구현을 다른 방식(예: eBPF 기반 CNI)이 맡으면 kube-proxy도 빠질 수 있다.etcd는 컨트롤 플레인 안에 들어 있다. 별도 인프라가 아니라 컨트롤 플레인 컴포넌트 목록의 두 번째 항목으로 실려 있다. 설명도 "모든 API 서버 데이터를 위한" 저장소로 한정된다.- 스케줄러의 일은 "아직 할당되지 않은 파드"를 찾는 것이다. 실행이나 재시작이 아니라 배정만 담당한다는 뜻이다 — 실제로 띄우는 일은
kubelet몫이다. - 이 페이지 자체가 "상위 수준 개요"임을 밝힌다. 각 컴포넌트 상세와 아키텍처 구성 방법은 별도의 "클러스터 아키텍처" 페이지로 넘긴다. 입문자가 처음 읽을 지도이지 참조 문서가 아니다.
출처 정보
- 저자/발행처: Kubernetes 공식 문서 (The Kubernetes Authors / CNCF), 한국어 번역판
- 수집일: 2026-09-01
- URL: https://kubernetes.io/ko/docs/concepts/overview/components/
- 범위: 해당 페이지 본문 전체(핵심 컴포넌트·노드 컴포넌트·애드온·아키텍처 유연성). 링크로 이어지는 개별 컴포넌트 상세 페이지와 "클러스터 아키텍처" 페이지는 포함하지 않았다 — 입문 범위에 맞춰 개요 한 쪽으로 끊었다.