클러스터 아키텍처

클러스터 아키텍처 (Cluster Architecture)

Kubernetes 뒤에 숨은 아키텍처 개념들을 설명해드릴게요. 이 페이지를 읽고 나면 클러스터가 어떤 조각들로 이루어져 있고, 각 조각이 어떤 역할을 하는지 한눈에 파악할 수 있어요.

Kubernetes 클러스터는 **컨트롤 플레인(control plane)**과 컨테이너화된 애플리케이션을 실행하는 **워커 머신(node)**으로 구성돼요. Pod를 실행하려면 모든 클러스터에 최소 1개의 워커 노드가 필요합니다.

워커 노드는 애플리케이션 워크로드의 구성 요소인 Pod를 호스팅해요. 컨트롤 플레인은 클러스터 안의 워커 노드와 Pod를 관리합니다. 운영 환경(production)에서는 컨트롤 플레인이 보통 여러 대의 컴퓨터에 걸쳐 실행되고, 클러스터도 여러 노드를 실행해서 **내결함성(fault-tolerance)**과 **고가용성(high availability)**을 확보해요.

이 문서는 완전하고 동작하는 Kubernetes 클러스터를 갖추기 위해 필요한 각 컴포넌트를 정리해줍니다.

출처: Kubernetes 공식 문서 — Cluster Architecture

아키텍처에 대하여 (About this architecture)

위 다이어그램(그림 1)은 Kubernetes 클러스터의 예시 참조 아키텍처를 보여줘요. 실제 컴포넌트 배치는 특정 클러스터 구성과 요구사항에 따라 달라질 수 있습니다.

다이어그램에서 각 노드는 kube-proxy 컴포넌트를 실행해요. Service API와 관련 동작이 클러스터 네트워크에서 사용 가능하려면 각 노드에 네트워크 프록시 컴포넌트가 필요합니다. 다만 일부 네트워크 플러그인은 자체적인 서드파티 프록시 구현을 제공하는데, 그런 플러그인을 쓸 때는 노드에서 kube-proxy를 실행할 필요가 없어요.

컨트롤 플레인 컴포넌트 (Control plane components)

컨트롤 플레인의 컴포넌트들은 클러스터에 대한 전역적인 결정(예: 스케줄링)을 내리고, 클러스터 이벤트를 감지하고 대응해요(예: Deployment의 replicas 필드가 충족되지 않았을 때 새 Pod를 시작하기).

컨트롤 플레인 컴포넌트는 클러스터의 어떤 머신에서든 실행될 수 있어요. 다만 간단하게 하기 위해 설치 스크립트는 보통 모든 컨트롤 플레인 컴포넌트를 같은 머신에서 실행하고, 그 머신에서는 사용자 컨테이너를 실행하지 않아요. 여러 머신에 걸쳐 실행되는 컨트롤 플레인 구성 예시는 kubeadm으로 고가용성 클러스터 만들기를 참고하세요.

kube-apiserver

API 서버는 Kubernetes 컨트롤 플레인의 컴포넌트로, Kubernetes API를 노출해요. API 서버는 Kubernetes 컨트롤 플레인의 프런트 엔드(front end) 역할을 합니다.

Kubernetes API 서버의 주요 구현은 kube-apiserver예요. kube-apiserver는 수평 확장(인스턴스를 더 배포해서 확장)하도록 설계됐어요. kube-apiserver 인스턴스를 여러 개 실행하고 그 인스턴스 사이에 트래픽을 분산시킬 수 있습니다.

etcd

모든 클러스터 데이터의 백킹 스토어(backing store)로 사용되는 일관성 있고 고가용성인 키-값 저장소예요.

클러스터가 etcd를 백킹 스토어로 쓴다면 데이터에 대한 백업 계획을 반드시 세워두세요.

etcd에 대한 심층 정보는 공식 문서에서 볼 수 있어요.

kube-scheduler

새로 생성됐지만 아직 노드가 배정되지 않은 Pod를 감시하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트예요.

스케줄링 결정에 고려되는 요소로는 개별·집합적 리소스 요구사항, 하드웨어/소프트웨어/정책 제약, 어피니티(affinity)와 안티-어피니티(anti-affinity) 명세, 데이터 지역성(data locality), 워크로드 간 간섭, 마감 기한 등이 있어요.

kube-controller-manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트예요.

논리적으로 각 컨트롤러는 별개의 프로세스지만, 복잡성을 줄이기 위해 모두 하나의 바이너리로 컴파일되어 단일 프로세스로 실행돼요.

컨트롤러에는 다양한 타입이 있습니다. 몇 가지 예시를 들면:

  • Node 컨트롤러: 노드가 다운될 때 이를 감지하고 대응하는 역할을 담당해요.
  • Job 컨트롤러: 일회성 작업을 나타내는 Job 객체를 감시하고, 그 작업을 완료할 Pod를 생성해요.
  • EndpointSlice 컨트롤러: EndpointSlice 객체를 채워서 Service와 Pod 사이의 연결을 제공해요.
  • ServiceAccount 컨트롤러: 새 네임스페이스에 기본 ServiceAccount를 생성해요.

위 목록은 완전한 목록이 아니에요.

cloud-controller-manager

클라우드 특화 제어 로직을 포함하는 Kubernetes 컨트롤 플레인 컴포넌트예요. 클라우드 컨트롤러 매니저는 클러스터를 클라우드 제공자의 API에 연결해주고, 그 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터와만 상호작용하는 컴포넌트에서 분리해줘요. cloud-controller-manager는 클라우드 제공자에 특화된 컨트롤러만 실행해요. Kubernetes를 자사(온프레미스)에서 또는 PC 안의 학습 환경에서 실행 중이라면 클러스터에 클라우드 컨트롤러 매니저가 없을 거예요.

kube-controller-manager처럼 cloud-controller-manager도 논리적으로 독립적인 여러 제어 루프를 단일 바이너리에 결합해서 단일 프로세스로 실행해요. 수평 확장(복사본을 더 실행)해서 성능을 높이거나 장애를 견디게 할 수 있습니다.

클라우드 제공자 의존성이 있을 수 있는 컨트롤러는 다음과 같아요:

  • Node 컨트롤러: 클라우드에서 노드가 응답을 멈췄을 때 삭제됐는지 확인하기 위해 클라우드 제공자에 확인하는 역할
  • Route 컨트롤러: 기본 클라우드 인프라에 라우트를 설정하는 역할
  • Service 컨트롤러: 클라우드 제공자 로드 밸런서를 생성·업데이트·삭제하는 역할

노드 컴포넌트 (Node components)

노드 컴포넌트는 모든 노드에서 실행되며, 실행 중인 Pod를 유지하고 Kubernetes 런타임 환경을 제공해요.

kubelet

클러스터의 각 노드에서 실행되는 에이전트예요. 컨테이너가 Pod 안에서 실행되고 있음을 보장해요.

kubelet은 다양한 메커니즘을 통해 제공된 PodSpec 집합을 받아서, 그 PodSpec에 기술된 컨테이너가 실행 중이고 정상(healthy) 상태임을 보장해요. kubelet은 Kubernetes가 만든 것이 아닌 컨테이너는 관리하지 않아요.

kube-proxy (선택 사항)

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, Kubernetes Service 개념의 일부를 구현해요.

kube-proxy는 노드에서 네트워크 규칙을 유지해요. 이 네트워크 규칙들은 클러스터 안팎의 네트워크 세션에서 Pod로의 네트워크 통신을 허용해줍니다.

kube-proxy는 운영체제의 패킷 필터링 계층이 있고 사용 가능하거나 이용 가능하면 그걸 사용해요. 그렇지 않으면 kube-proxy가 트래픽을 직접 전달해요.

Service에 대한 패킷 전달을 자체적으로 구현하면서 kube-proxy와 동등한 동작을 제공하는 네트워크 플러그인을 쓴다면, 클러스터의 노드에서 kube-proxy를 실행할 필요가 없어요.

컨테이너 런타임 (Container runtime)

Kubernetes가 컨테이너를 효과적으로 실행할 수 있게 해주는 기본적인 컴포넌트예요. Kubernetes 환경 안에서 컨테이너의 실행과 수명 주기를 관리하는 역할을 담당합니다.

Kubernetes는 containerd, CRI-O, 그리고 Kubernetes CRI(Container Runtime Interface)의 다른 구현체 같은 컨테이너 런타임을 지원해요.

애드온 (Addons)

애드온은 Kubernetes 리소스(DaemonSet, Deployment 등)를 사용해서 클러스터 기능을 구현해요. 클러스터 수준 기능을 제공하기 때문에 애드온의 네임스페이스 리소스는 kube-system 네임스페이스에 속해요.

대표적인 애드온들은 아래에 설명하고, 사용 가능한 애드온 전체 목록은 Addons에서 확인할 수 있어요.

DNS

다른 애드온은 반드시 필요하지 않지만, 많은 예제가 의존하기 때문에 모든 Kubernetes 클러스터에는 클러스터 DNS가 있어야 해요.

클러스터 DNS는 환경의 다른 DNS 서버와 더불어 Kubernetes 서비스에 대한 DNS 레코드를 제공하는 DNS 서버예요.

Kubernetes가 시작한 컨테이너는 DNS 검색에 이 DNS 서버를 자동으로 포함합니다.

웹 UI (Dashboard)

Dashboard는 Kubernetes 클러스터를 위한 범용 웹 기반 UI예요. 사용자가 클러스터에서 실행 중인 애플리케이션과 클러스터 자체를 관리하고 문제를 해결할 수 있게 해줍니다.

컨테이너 리소스 모니터링

컨테이너 리소스 모니터링은 컨테이너에 대한 일반적인 시계열 메트릭을 중앙 데이터베이스에 기록하고, 그 데이터를 탐색할 수 있는 UI를 제공해요.

클러스터 수준 로깅

클러스터 수준 로깅 메커니즘은 컨테이너 로그를 검색/탐색 인터페이스를 갖춘 중앙 로그 저장소에 저장하는 역할을 담당합니다.

네트워크 플러그인

네트워크 플러그인은 CNI(Container Network Interface) 명세를 구현하는 소프트웨어 컴포넌트예요. Pod에 IP 주소를 할당하고 Pod들이 클러스터 안에서 서로 통신할 수 있게 하는 역할을 담당합니다.

아키텍처 변형 (Architecture variations)

Kubernetes의 핵심 컴포넌트는 일관되게 유지되지만, 배포되고 관리되는 방식은 달라질 수 있어요. 이런 차이를 이해하는 것은 특정 운영 요구사항을 충족하는 클러스터를 설계하고 유지하는 데 중요합니다.

컨트롤 플레인 배포 옵션

컨트롤 플레인 컴포넌트는 여러 방식으로 배포될 수 있어요:

  • 전통적 배포 (Traditional deployment): 컨트롤 플레인 컴포넌트가 전용 머신이나 VM에서 직접 실행되며, 보통 systemd 서비스로 관리돼요.
  • 정적 Pod (Static Pods): 컨트롤 플레인 컴포넌트가 특정 노드에서 kubelet이 관리하는 정적 Pod로 배포돼요. kubeadm 같은 도구가 쓰는 일반적인 방식이에요.
  • 셀프 호스팅 (Self-hosted): 컨트롤 플레인이 Kubernetes 클러스터 자체 안에서 Pod로 실행되며, Deployment와 StatefulSet 또는 다른 Kubernetes 프리미티브로 관리돼요.
  • 관리형 Kubernetes 서비스: 클라우드 제공자가 컨트롤 플레인을 추상화해서, 그 컴포넌트를 서비스 오퍼링의 일부로 관리해줘요.

워크로드 배치 고려사항

컨트롤 플레인 컴포넌트를 포함한 워크로드의 배치는 클러스터 크기, 성능 요구사항, 운영 정책에 따라 달라질 수 있어요:

  • 더 작거나 개발용 클러스터에서는 컨트롤 플레인 컴포넌트와 사용자 워크로드가 같은 노드에서 실행될 수 있어요.
  • 더 큰 운영 클러스터는 보통 특정 노드를 컨트롤 플레인 컴포넌트에 할당해서 사용자 워크로드와 분리해요.
  • 어떤 조직은 핵심 애드온이나 모니터링 도구를 컨트롤 플레인 노드에서 운영하기도 해요.

클러스터 관리 도구

kubeadm, kops, Kubespray 같은 도구는 클러스터를 배포하고 관리하는 다양한 접근법을 제공하며, 각각 컴포넌트 배치와 관리 방식이 달라요.

커스터마이즈와 확장성

Kubernetes 아키텍처는 상당한 커스터마이즈를 허용해요:

  • 커스텀 스케줄러를 기본 스케줄러와 함께 배포하거나 그것을 완전히 대체할 수 있어요.
  • API 서버는 CustomResourceDefinition과 API Aggregation으로 확장할 수 있어요.
  • 클라우드 제공자는 cloud-controller-manager를 사용해 Kubernetes와 깊게 통합할 수 있어요.

Kubernetes 아키텍처의 유연성 덕분에 조직은 운영 복잡성, 성능, 관리 오버헤드 같은 요소를 균형 잡으면서 클러스터를 특정 요구에 맞게 조정할 수 있어요.

다음으로 볼 것 (What's next)

다음 내용을 더 배워보세요:

더 알아보기 (Learn more)