Kubernetes는 컨테이너화된 애플리케이션을 대규모로 배포, 관리, 확장하기 위한 오픈소스 컨테이너 오케스트레이션 시스템이다. 복잡한 컨테이너 환경을 효율적으로 조율하고 관리하는 프로그램이라고 할 수 있다. 주로 Docker와 같은 컨테이너 기술과 함께 사용되어 컨테이너 관리 플랫폼의 역할을 수행한다
k8s
“Kubernetes”의 첫 글자 ‘k’와 마지막 글자 ‘s’ 사이에 있는 여덟 글자(ubernete)를 숫자 ‘8’로 대체한 누메로님(numeronym)으로 ‘케이츠(kates)’라고 있는데
Kubernetes의 필요성
단일 서버(호스트)에 여러 컨테이너(예: Spring 애플리케이션, MySQL, Redis, Kafka)를 배포하여 운영하는 시나리오를 생각해보자. 이러한 컨테이너들을 수동으로 관리하는 것은 매우 비효율적이다
- 수동 관리의 어려움: 특정 컨테이너가 중단되었을 때 재시작하거나, 부하가 증가했을 때 컨테이너 수를 늘리거나(스케일 아웃), 부하가 줄었을 때 컨테이서 수를 줄이는(스케일 인) 등의 작업을 사람이 직접 판단하고 실행하는 것은 거의 불가능하다
- 안정적인 운영의 한계: 수동 관리 방식으로는 안정적인 서비스 운영을 보장하기 어렵다
Kubernetes 아키텍처
초기에는 단일 호스트 내에서 Kubernetes 프로그램과 애플리케이션 컨테이너를 함께 실행하는 방식도 고려될 수 있다. 하지만 이 경우 컨테이너 부하 증가 시 호스트 전체를 복제해야 하므로 무거운 Kubernetes 프로그램까지 함께 복제되어 자원 낭비가 발생한다. 이러한 비효율성을 개선하기 위해서 Kubernetes는 마스터 노드(Master Node)와 워커 노드(Worker Node)로 구성된 분리된 아케틱처를 채택한다
마스터 노드(Master Node)라는 단어를 사용했지만 앞으로는 Kubernetes 공식 용어인 컨트롤 플레인(Control Plane)을 사용한다. Master 대신 Control Plane을 쓰는 이유는 포용성과 기술적 정확성 때문이다. 과거 용어는 인종·성별 차별적 맥락이 있어 업계에서는 배제하고 있다. 또한 Control Plane이 분산 아키텍처를 더 정확히 설명하며 업계 전반에 걸친 언어 개선 흐름의 일부이다. DDD에서 배운 일관된 단어로 표현하기 위해서 공식 용어를 사용하는 것이 좋을 듯 하다.
- 컨트롤 플레인(Control Plane): Kubernetes의 핵심 프로그램들이 설치되어 클러스터 전체를 관리하고 제어하는 “컨트롤 타워”역할을 한다
- 워커 노드(Worker Node): 실제 애플리케이션 컨테이너(Pod)가 실행되는 공간이다. 컨트롤 플레인과 통신하며 할당된 Pod들을 실행하고 관리한다
클러스터 내에서 워커 노드에 부하가 발생하면 컨트롤 플레인은 새로운 워커 노드를 추가하여 Pod만 증설하도록 통신한다. 이렇게 함으로써 필요한 부분만 확장하여 자원의 효율성을 극대화 할 수 있다. 컨트롤 플레인과 워커 노드들을 묶어서 클러스터(Cluster)라고 부른다
Kubernetes 클러스터의 주요 구성 요소
Kubernetes 클러스터는 컨트롤 플레인과 워커 노드에 여러 핵심 구성 요소들이 분산되어 작동한다
컨트롤 플레인(Control Plane)의 주요 구성 요소
API Server
- 개발자(kubectl 프로그램 사용)나 클러스터 내부 구성 요소, 외부 도구로부터 오는 모든 통신 요청을 받아들이는 Kubernetes의 핵심 진입점이다
- RESTful API를 통해 클러스터의 상태를 관리하고 모든 통신의 허브 역할을 한다
- 개발자가 kubectl을 통해 “Pod를 3개로 늘려라”와 같은 통신을 하면 API Server가 이를 수신한다
Scheduler
- 새롭게 생성된 Pod를 감지하고 이 Pod를 실행할 최적의 워커 노드를 선택하는 역할을 한다
- CPU, 메모리, 네트워크 등의 자원 요구 사항과 현재 워커 노드들의 부하 상태를 고려하여 가장 적합한 워커 노드를 결정한다
Controller Manager
- 클러스터의 현재 상태를 모니터링하고 사용자가 정의한 원하는 상태(Desired State)를 유지하기 위해 지속적으로 조정하는 역할을 한다
- 예를 들어, 개발자가 “Pod 3개를 유지하라”고 설정했는데 Pod가 하나가 죽으면, Controller Manager가 이를 감지하고 새로운 Pod를 생성하여 3개의 Pod 상태로 복구한다. Deployment, ReplicaSet과 같은 개념을 관리한다
etcd
- 클러스터의 모든 상태, 데이터, 설정 정보, 비밀 값(Secret), 환경 설정(Config Map)등을 저장하는 고가용성 분산 데이터베이스이다
- Kay-Value 형태로 데이터를 저장하며, 클러스터의 “뇌” 역할을 한다. 컨트롤 플레인의 안정성과 고가용성은 etcd의 안정성과 직결된다
워커 노드 (Worker Node)의 주요 구성 요소
Pod
- Kubernetes에서 배포될 수 있는 가장 작은 배포 단위이다
- 하나 이상의 컨테이너(주로 Docker 컨테이너)와 이들을 위한 스토리지, 네트워크 자원을 함께 캡슐화한 그룹이다. 컨테이너와 거의 동일한 개념으로 생각할 수 있다
- 워커 노드에서 실제 애플리케이션 역할을 수행한다
Kubelet
- 각 워커 노드에서 에이전트이다
- API Server와 통신하며 컨트롤 플레인으로 부터 요구(예: Pod 실행, 중지)를 워커 노드에서 실행하고 Pod의 상태를 주기적으로 API Server에 보고하는 역할을 한다
- “Pod를 하나 더 만들라”는 전달을 받으면 실제로 Pod를 생성하고 관리한다
Kube-Proxy
- 워커 노드에서 실행되며, Pod 간의 통신이나 외부에서 Pod로의 접근을 가능하게 하는 네트워크 프록시 및 로드 밸런서 역할을 한다
- 서비스에 대한 네트워크 규칙을 설정하여 트래픽을 적절한 Pod로 포워딩(라우팅)한다. 사용자의 요청을 받아 Pod1, Pod2, Pod3 … 중 적절한 Pod로 연결시켜준다
개발자와 Kubernetes의 상호작용
개발자는 자신의 PC에서 kubectl이라는 명령줄 도구를 사용하여 Kubernetes 클러스터에 명령을 내린다. kubectl은 “Kubernetes + controller”의 약자로, 개발자와 Kubernetes가 의사소통하기 위한 인터페이스이다. 개발자는 kubectl을 통해서 컨트롤 플레인의 API Server에 요구사항을 전달하고 이를 통해 클러스터의 상태를 제어한다
클라우드 환경에서의 Kubernetes – EKS (AWS Elastic Kubernetes Service)
직접 Kubernetes 클러스터를 구성하고 관리하는 것은 많은 시간과 노력이 필요하다. 특히 컨트롤 플레인의 안정성과 고가용성을 직접 유지하는 것은 매우 어려운 일이다
AWS EKS와 같은 관리형 Kubernetes 서비스는 이러한 운영 부담을 줄여준다
- EKS의 장점: EKS에서 클러스터를 생성하면, AWS가 컨트롤 플레인의 생성 및 관리를 전적으로 담당한다. 개발자는 컨트롤 플레인의 안정성에 대해 걱정할 필요 없이 원하는 수의 워커 노드(AWS EC2 인스턴스로 구성)를 선택하여 추가하고 애플리케이션 Pod를 배포하는 데 집중할 수 있다
- EC2와 워커 노드: AWS 환경에서 워커 노드는 EC2(Elastic Compute Cloud) 인스턴스로 실행된다. EC2는 특정 사양과 운영 체제를 가진 가상 컴퓨터를 쉽게 생성할 수 있는 AWS의 컴퓨팅 서비스이다. Pod는 이 EC2 인스턴스(워커 노드) 내에서 실행된다
EKS와 같은 관리형 서비스를 활용하면 Kubernetes의 복잡한 내부 구성 요소를 세세하게 관리하는 대신, 애플리케이션 개발과 배포에 더 집중할 수 있다. 물론, DevOps 전문가나 심화 학습이 필요한 경우 각 요소에 대한 깊은 이해는 여전히 중요하다