[K8S] 쿠버네티스 이해 하기

1. 쿠버네티스란 ?

과거의 애플리케이션은 모든 기능이 하나의 거대한 단위로 묶인 모놀리식(Monolithic) 아키텍처가 일반적이었다. 이는 개발과 배포가 단순하다는 장점이 있지만, 애플리케이션이 복잡해질수록 수정, 테스트, 배포가 어려워지고 특정 기능의 장애가 전체 시스템의 장애로 이어지는 문제를 가지고 있다.

이러한 문제를 해결하기 위해 등장한 것이 **마이크로서비스 아키텍처(MSA)**이다. 각 기능을 독립적인 작은 서비스로 분리하여 개발하고 배포하는 방식이다. MSA는 유연성과 확장성, 장애 격리 측면에서 큰 이점을 제공하지만, 수많은 서비스를 관리하고 배포, 연결하는 것은 새로운 차원의 복잡성을 야기했다.

쿠버네티스는 바로 이 마이크로서비스 환경의 복잡성을 해결하기 위한 솔루션이다. 여러 서버(노드)를 하나의 거대한 컴퓨팅 리소스로 묶고, 수많은 컨테이너화된 애플리케이션들이 자동으로 배포, 확장, 복구되도록 관리하는 컨테이너 오케스트레이션 플랫폼이다. 즉, 쿠버네티스는 '클라우드 시대의 운영체제'라고 할 수 있다.

---

2. 쿠버네티스의 핵심 개념

쿠버네티스는 단순히 컨테이너를 실행하는 도구가 아닌, 분산 시스템을 **원하는 상태(Desired State)**로 유지하기 위한  철학을 기반으로 한다.

• 선언적 API와 상태 관리 (Declarative API & Desired State Management)
  • 쿠버네티스는 "무엇을 하라"는 명령형(Imperative)이 아닌, "어떤 상태여야 한다"는 선언형(Declarative) 방식을 사용한다. 사용자는 YAML 파일을 통해 '애플리케이션 A는 3개의 복제본을 가져야 한다'와 같이 원하는 최종 상태를 정의하고 API 서버에 전달한다. 쿠버네티스의 컨트롤러들은 현재 클러스터의 상태를 지속적으로 감시하며, 만약 현재 상태가 사용자가 선언한 원하는 상태와 다를 경우, 그 차이를 해결하기 위한 작업을 자동으로 수행하는 것이다.
• 자동 복구 (Self-Healing)
  • 상태 관리의 연장선으로, 실행 중이던 컨테이너(Pod)가 중지되거나 노드에 장애가 발생하면, 쿠버네티스는 이를 '원하는 상태'와의 불일치로 감지한다. 이후 별도의 개입 없이 자동으로 새로운 Pod를 생성하여 정의된 복제본 수를 유지함으로써 서비스의 높은 가용성을 보장한다.
• 서비스 디스커버리 및 로드 밸런싱 (Service Discovery & Load Balancing)
  • Pod는 생성될 때마다 새로운 내부 IP를 할당받으며 일시적인 존재이다. 따라서 IP 주소로 직접 통신하는 것은 거의 불가능하다. 쿠버네티스는 **서비스(Service)**라는 고유한 오브젝트를 통해 여러 Pod 그룹에 대한 단일 진입점과 고정된 DNS 이름을 제공한다. 외부 또는 내부의 요청이 서비스로 들어오면, 해당 서비스에 연결된 Pod들에게 트래픽을 자동으로 분산(Load Balancing)시킨다.
• 자동화된 배포와 롤백 (Automated Rollouts & Rollbacks)
  • 새로운 버전의 애플리케이션을 배포할 때, 기존 Pod를 한 번에 중단시키는 대신 순차적으로 새로운 버전의 Pod로 교체하는 롤링 업데이트(Rolling Update)를 기본으로 지원한다. 배포 과정에서 문제가 발생하면, 이전 버전으로 롤백하는 기능 또한 자동화되어 있어 안정적인 애플리케이션 관리가 가능하다.

---

3. 쿠버네티스 아키텍처

쿠버네티스 클러스터는 전체 시스템을 관리하고 제어하는 **컨트롤 플레인(Control Plane)**과, 실제 애플리케이션 컨테이너가 배치되어 실행되는 워커 노드(Worker Node) 그룹으로 구성된다.

 

3.1. 컨트롤 플레인 구성 요소

클러스터의 '두뇌' 역할을 하며, 클러스터의 모든 결정을 내리고 상태를 관리한다.

• kube-apiserver (API 서버): 쿠버네티스 컨트롤 플레인의 유일한 프론트엔드이자 모든 상호작용의 중심점이다. 사용자(kubectl), 클러스터 내부 컴포넌트 등 모든 요청을 수신하고, 이를 검증한 뒤 etcd에 저장한다.
• etcd (분산 저장소): 클러스터의 모든 설정 데이터와 상태 정보를 저장하는 고가용성의 키-값(key-value) 저장소이다. 클러스터의 '신뢰할 수 있는 단일 진실 공급원(Single Source of Truth)' 역할을 수행한다.
• kube-scheduler (스케줄러): 새로 생성되었지만 아직 노드에 할당되지 않은 Pod를 감시한다. 각 Pod의 리소스 요구사항, 제약 조건 등을 고려하여 가장 적합한 워커 노드를 찾아 해당 노드에 Pod를 배치(스케줄링)하는 역할을 한다.
• kube-controller-manager (컨트롤러 매니저): 쿠버네티스의 핵심적인 자동 복구 및 상태 관리 로직을 실행한다. 노드 컨트롤러, 레플리케이션 컨트롤러 등 다양한 컨트롤러를 실행하며, '원하는 상태'와 '현재 상태'를 일치시키기 위해 끊임없이 작동한다.

3.2. 워커 노드 구성 요소

컨트롤 플레인으로부터 명령을 받아 실제 컨테이너를 실행하고 관리한다.

• kubelet (노드 에이전트): 각 워커 노드에서 실행되는 핵심 에이전트로, API 서버와 통신하며 해당 노드에 할당된 Pod들이 정상적으로 실행되도록 보장한다.
• kube-proxy (네트워크 프록시): 각 워커 노드의 네트워크 규칙(iptables 등)을 관리하며, 클러스터의 서비스(Service) 개념을 구현하고 트래픽을 실제 Pod로 전달하는 역할을 한다.
• Container Runtime (컨테이너 런타임): 실제로 컨테이너를 실행하는 소프트웨어이다. (예: containerd, CRI-O). kubelet의 요청을 받아 컨테이너 이미지를 내려받고 컨테이너를 실행 및 중지한다.

---

4. 주요 시스템 파드의 구조와 역할

쿠버네티스의 컨트롤 플레인 컴포넌트들 또한 컨테이너로 실행되며, 일반적으로 kube-system 네임스페이스에 Pod 형태로 존재한다.

• kube-apiserver Pod: API 서버 프로세스를 실행하는 Pod이다.
• etcd Pod: etcd 데이터베이스를 실행하는 Pod로, 안정성을 위해 보통 3개 이상의 홀수 개로 구성된다.
• kube-controller-manager Pod: 컨트롤러 매니저 프로세스를 실행하는 Pod이다. 리더 선출을 통해 여러 개 중 하나만 활성 상태로 동작한다.
• kube-scheduler Pod: 스케줄러 프로세스를 실행하는 Pod이다. 컨트롤러 매니저와 마찬가지로 하나만 활성화된다.
• kube-proxy Pods (DaemonSet): 클러스터의 모든 노드에 하나씩 배포되어야 하므로 데몬셋(DaemonSet) 형태로 관리된다.
• coredns Pods (Deployment): 클러스터 내부의 DNS 서버 역할을 수행하며, 서비스 이름을 IP 주소로 변환해준다. 디플로이먼트(Deployment) 형태로 관리된다.

---

5. 쿠버네티스 핵심 오브젝트

사용자는 쿠버네티스에게 '원하는 상태'를 YAML 파일 형태의 오브젝트(Object)로 정의하여 전달한다. 다음은 가장 기본적이고 중요한 오브젝트들이다.

• Pod: 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위이다. 하나 이상의 컨테이너 그룹으로 구성되며, 이 컨테이너들은 스토리지와 네트워크를 공유한다.
• ReplicaSet: 명시된 수의 동일한 Pod가 항상 실행되도록 보장하는 역할을 한다. 일반적으로 직접 사용하기보다는 Deployment를 통해 관리된다.
• Deployment: ReplicaSet의 상위 개념으로, Pod와 ReplicaSet에 대한 선언적 업데이트를 제공한다. 롤링 업데이트, 롤백, 배포 일시 중지/재개 등의 핵심 기능을 담당한다.
• Service: 여러 Pod에 대한 안정적인 단일 네트워크 엔드포인트를 제공한다. ClusterIP, NodePort, LoadBalancer 등의 타입을 통해 클러스터 내부 또는 외부로 서비스를 노출시키는 방법을 정의한다.
• Namespace: 단일 물리 클러스터 내에서 여러 개의 가상 클러스터를 만들 수 있는 논리적인 격리 공간이다. 개발, 스테이징, 운영 환경을 분리하거나 여러 팀이 클러스터를 공유할 때 사용된다.
• ConfigMap / Secret: 설정 데이터와 민감한 정보(비밀번호, API 키 등)를 코드와 분리하여 관리하기 위한 오브젝트이다.
• PersistentVolume (PV) / PersistentVolumeClaim (PVC): Pod는 일시적이므로 데이터를 영구적으로 저장할 수 없다. PV(클러스터 관리자가 제공한 스토리지 자체)와 PVC(사용자가 요청하는 스토리지)를 통해 컨테이너의 데이터를 영속적으로 관리한다.