Kubernetes와 그 아키텍처

Source: Dev.to

Docker 사용 시 문제점

• 단일 호스트 자원 경쟁 – 하나의 호스트에 많은 컨테이너가 있을 경우, 과도한 메모리를 사용하는 컨테이너가 다른 컨테이너의 성능에 영향을 미칠 수 있으며, 우선순위에 따라 다른 컨테이너가 강제 종료될 수 있습니다.
• 자동 복구 부족 – 컨테이너가 충돌하면 애플리케이션에 접근할 수 없게 되고, 컨테이너를 수동으로 재시작해야 합니다.
• 자동 스케일링 부재 – Docker은 워크로드를 자동으로 상·하향 조정하는 메커니즘을 제공하지 않습니다.
• 엔터프라이즈 지원 없음 – Docker 자체에는 엔터프라이즈 수준의 지원 기능이 포함되어 있지 않습니다.

Kubernetes가 이러한 문제를 해결하는 방법

Kubernetes는 위 제한 사항을 해소하는 오케스트레이션 기능을 추가하여 자동화된 상태 검사, 스케일링 및 프로덕션 환경을 위한 견고한 지원을 제공합니다.

Kubernetes 아키텍처

데이터 플레인

• 컨테이너 런타임 – 컨테이너를 실행합니다 (예: Docker, containerd). Java 애플리케이션을 위한 Java 런타임과 유사합니다.
• kube‑proxy – 컨테이너와 서비스 간 네트워킹을 관리하고, 로드 밸런싱을 수행하며, IP 주소를 할당합니다.
• kubelet – 해당 노드에 할당된 Pod가 실행 중이고 정상 상태인지 보장합니다. 컨트롤 플레인과 통신하고, 컨테이너 런타임을 사용해 Pod 내부의 컨테이너를 시작합니다.

컨트롤 플레인

• API Server – 모든 명령의 핵심 구성 요소이자 진입점입니다. 객체(예: Pod)를 저장하고 다른 구성 요소에 노출합니다.
• Scheduler – 각 Pod를 실행할 노드를 결정합니다. 스케줄되지 않은 Pod를 감시하고, 후보 노드를 평가한 뒤 정책 및 자원 가용성을 기반으로 최적의 노드를 선택합니다.
• etcd – 클러스터 상태와 설정 데이터를 보관하는 분산 키‑값 저장소입니다.
• Controller Manager – 클러스터의 원하는 상태를 유지합니다 (예: 지정된 복제본 수가 실행 중인지 확인).

워크플로우 개요

1. 사용자 요청 – 사용자가 API Server에 요청을 보냅니다 (예: kubectl apply).
2. 상태 영구화 – API Server가 요청을 검증하고 원하는 객체 정의를 etcd에 저장합니다.
3. 스케줄링 – Scheduler가 노드 할당이 없는 새로운 Pod를 감지하고, 사용 가능한 노드를 평가한 뒤 각 Pod를 적절한 노드에 할당합니다.
4. 노드 실행 – 선택된 노드의 kubelet이 할당을 받아 컨테이너 런타임에 Pod의 컨테이너 실행을 지시합니다.
5. 네트워킹 – kube‑proxy가 새로 생성된 Pod에 대한 서비스 라우팅 및 로드 밸런싱을 구성합니다.
6. 제어 루프 – Controller Manager 내의 컨트롤러들이 실제 상태를 지속적으로 모니터링하고 원하는 상태와 비교하여, 필요에 따라 스케일링이나 자체 복구와 같은 작업을 트리거합니다.