(2) - 쿠버네티스 컴포넌트 개요

https://kubernetes.io/ko/docs/concepts/overview/components/

 

 

 

Kubernetes 클러스터 개요

Kubernetes 클러스터는 크게 **컨트롤 플레인(Control Plane)**과 **노드(Node)**로 나뉘며, 각 구성요소는 클러스터 상태 유지와 애플리케이션 실행

Kubernetes의 모든 컴포넌트는 API Server를 중심으로 유기적으로 동작

---

컨트롤 플레인 컴포넌트

클러스터의 전반적인 상태를 관리하는 컴포넌트로 구성됨.

• kube-apiserver
  Kubernetes의 중심 엔드포인트로, 모든 컴포넌트와 외부 요청을 받는 HTTP API 서버 역할 수행. 클러스터 상태에 대한 모든 요청과 명령은 여기서 처리됨.
• etcd
  클러스터 전반의 상태 데이터를 저장하는 일관되고 고가용성을 갖춘 키-값 저장소. 예: 파드 상태, 컨피그맵, 시크릿 등.
• kube-scheduler
  새로운 파드가 클러스터에 생성될 때, 어떤 노드에 실행시킬지 판단하는 스케줄링 로직 담당 컴포넌트. API 서버에서 아직 노드에 할당되지 않은 파드 목록을 받아 결정 수행.
• kube-controller-manager
  클러스터 상태를 **원하는 상태(desired state)**로 유지하기 위한 다양한 컨트롤러들을 실행하는 매니저 컴포넌트. 예: ReplicaSet, Node, Endpoints 컨트롤러 등.
• cloud-controller-manager (선택 사항)
  클라우드 인프라(예: AWS, GCP)와의 통합을 담당하는 컴포넌트. 노드 자동 등록, 외부 로드 밸런서 구성 등과 관련된 기능 포함.

---

노드 컴포넌트

각 노드에서 실행되며, 파드와 컨테이너가 원활히 실행되도록 유지하는 런타임 환경 제공.

• kubelet
  노드에서 실행되는 에이전트 역할 컴포넌트로, kube-apiserver로부터 할당된 파드를 받아 컨테이너 런타임에 전달하고 실행 상태를 지속적으로 체크함.
• kube-proxy (선택 사항)
  서비스 오브젝트의 정의에 따라 클러스터 내부 네트워크 라우팅 및 로드 밸런싱을 담당하는 컴포넌트. iptables 또는 eBPF 기반으로 구현 가능.
• 컨테이너 런타임
  컨테이너를 실제로 실행하는 소프트웨어. 대표적으로 containerd, CRI-O, Docker 등이 있으며, Kubernetes는 CRI(Container Runtime Interface)를 통해 런타임을 추상화함.

 노드에는 이 외에도 시스템 수준의 로컬 컴포넌트(supervisord, systemd 등)가 필요할 수 있음.

컴포넌트 간 상호작용 흐름 예시

1. 사용자가 파드 생성 요청을 kubectl로 보냄 → kube-apiserver가 요청 수신
2. etcd에 파드 객체 정보 저장
3. kube-scheduler가 해당 파드를 감지하고 노드 할당 결정
4. kubelet이 해당 노드에서 파드 실행
5. kube-proxy가 서비스 정의에 따라 네트워크 경로 설정
   
   
   
   
   이처럼 Kubernetes는 API Server를 중심으로 모든 동작이 연결되며, 각 컴포넌트는 독립적이면서도 유기적으로 구성

 

---

 

애드온(Addons) 구성요소

클러스터의 기능을 확장하는 부가적인 컴포넌트로 구성됨.

• CoreDNS
  Kubernetes 클러스터의 내부 서비스 검색을 위한 DNS 기능 제공. 모든 서비스 이름을 DNS 형식으로 변환 가능.
• Web UI (Dashboard)
  웹 인터페이스를 통해 클러스터를 관리할 수 있도록 지원하는 구성요소.
• Container Resource Monitoring
  컨테이너 리소스 메트릭을 수집하고 저장하는 모니터링 구성요소.
• Cluster-level Logging
  각 컨테이너의 로그를 중앙 로그 저장소에 기록하기 위한 로깅 구성요소.

---

아키텍처 유연성

Kubernetes는 클러스터 구성 방식에 있어 높은 유연성을 제공함.

소규모 개발 환경부터 대규모 프로덕션 환경에 이르기까지 다양한 요구사항에 따라 아키텍처를 조정할 수 있는 유연성 보장.

• 분산 구성 또는 중앙 집중형 구성 선택 가능성
• 클러스터 컴포넌트의 개별 배포 또는 통합 관리 가능성
• 온프레미스, 클라우드, 하이브리드 환경에서의 적용 가능성