쿠버네티스(Kubernetes, K8s)

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다. 수많은 컨테이너를 지휘하는 '오케스트라 지휘자' 혹은 대규모 화물선의 '항만 관리 시스템'과 같은 역할을 수행합니다.

 

쿠버네티스의 핵심 원리는 관리자가 선언한 '원하는 상태(Desired State)'를 지속적으로 모니터링하고 유지하는 것입니다. 예를 들어, 커넥티드 카 서비스를 위한 백엔드 API 서버를 컨테이너로 운영한다고 가정해 보겠습니다. 트래픽이 몰리는 출퇴근 시간에 서버(컨테이너)를 10대로 늘리고, 한가한 새벽 시간에는 2대로 줄이도록 설정할 수 있습니다. 운영 중 특정 노드(서버)에 장애가 발생하여 컨테이너 3개가 다운되면, 쿠버네티스는 즉시 이를 감지하고 정상적인 다른 노드에 새로운 컨테이너 3개를 자동으로 띄워 '원하는 상태'를 복구합니다. 이 모든 과정인 확장(Scaling)과 자동 복구(Self-healing)가 사람의 개입 없이 이루어집니다.

---

쿠버네티스 아키텍처 및 구조

쿠버네티스 클러스터는 크게 두 부분으로 나뉩니다. 클러스터 전체를 관리하고 통제하는 컨트롤 플레인(Control Plane)과 실제 애플리케이션 컨테이너가 구동되는 워커 노드(Worker Node)입니다.

1. 컨트롤 플레인 (Control Plane) 구성요소

클러스터의 두뇌 역할을 하며, 글로벌 의사 결정을 내리고 클러스터 내 이벤트를 감지하여 반응합니다.

• kube-apiserver: 쿠버네티스의 모든 통신이 통과하는 중앙 관문입니다. 사용자의 제어 명령어(kubectl)나 클러스터 내부 컴포넌트들의 요청을 검증하고 처리합니다.
• etcd: 클러스터의 모든 데이터를 저장하는 고가용성 키-값(Key-Value) 저장소입니다. 클러스터의 '현재 상태'와 '원하는 상태' 정보, 구성 데이터가 모두 이곳에 안전하게 보관됩니다.
• kube-scheduler: 노드가 배정되지 않은 새로 생성된 애플리케이션(Pod)을 감지하고, CPU나 메모리 등 자원 요구사항을 분석하여 실행될 최적의 노드를 선택하여 배치합니다.
• kube-controller-manager: 클러스터의 상태를 모니터링하고 원하는 상태로 유지하는 백그라운드 프로세스(컨트롤러)들을 무한 루프로 실행합니다. 노드 다운을 감지하거나 적정 개수의 애플리케이션 복제본이 실행되도록 보장하는 역할을 합니다.
• cloud-controller-manager: AWS, GCP, Azure 등 퍼블릭 클라우드 제공업체의 API와 상호작용하여 클라우드 인프라 자원(로드밸런서, 스토리지 등)을 관리하고 연동합니다.

2. 워커 노드 (Worker Node) 구성요소

실제 서비스되는 애플리케이션 컨테이너가 할당되어 실행되는 작업 환경입니다.

• kubelet: 각 노드에서 실행되는 핵심 에이전트로, 컨트롤 플레인(apiserver)의 지시를 받아 컨테이너가 확실하게 실행되고 건강한 상태를 유지하도록 감시하고 보고합니다.
• kube-proxy: 각 노드에서 실행되는 네트워크 프록시입니다. 노드 내부 및 외부의 네트워크 트래픽을 적절한 컨테이너로 라우팅하는 네트워크 규칙(iptables/IPVS 등)을 관리합니다.
• 컨테이너 런타임 (Container Runtime): 컨테이너를 실제로 실행하고 격리하는 소프트웨어입니다. 과거에는 Docker를 주로 사용했으나, 현재는 표준화된 containerd, CRI-O 등을 주로 사용합니다.

 

이러한 구조 위에서 애플리케이션은 파드(Pod), 디플로이먼트(Deployment), 서비스(Service)와 같은 쿠버네티스 오브젝트 단위로 정의되어 배포됩니다.

---

파드(Pod)와 서비스(Service)

1. 파드 (Pod): 쿠버네티스의 최소 실행 단위

쿠버네티스는 컨테이너를 개별적으로 하나씩 배포하지 않고, 파드(Pod)라는 더 큰 논리적 단위로 묶어서 배포하고 관리합니다. 고래 떼(Pod of whales)에서 유래한 명칭처럼, 연관된 컨테이너들이 함께 다니는 그룹을 의미합니다.

• 동일한 자원 공유 (Network & Storage): 하나의 파드 내에 있는 컨테이너들은 동일한 IP 주소와 포트 공간을 공유합니다. 따라서 파드 내부의 컨테이너끼리는 localhost를 통해 매우 빠르게 통신할 수 있습니다. 또한 동일한 저장 공간(볼륨)을 마운트하여 데이터를 쉽게 공유할 수 있습니다.
• 일시적이고 소모적인 존재 (Ephemeral): 파드는 영구적이지 않습니다. 서버(노드)에 장애가 발생하거나 자원이 부족해지면 쿠버네티스는 파드를 가차 없이 삭제하고 다른 건강한 노드에 새로운 파드를 생성합니다. 파드가 재생성될 때마다 내부 IP 주소는 무작위로 변경됩니다.

예시 (사이드카 패턴): 웹 서버 컨테이너(예: Nginx) 하나만 단독으로 파드에 넣을 수도 있지만, 밀접하게 결합된 두 컨테이너를 함께 묶을 때 파드의 진가가 발휘됩니다. 메인 웹 서버 컨테이너가 작동하면서 로그를 파일로 남기면, 동일한 파드 내에 있는 로그 수집 보조 컨테이너(Sidecar)가 그 파일을 읽어 중앙 로그 서버로 전송합니다. 이 둘은 항상 같은 노드에서 동시에 켜지고 꺼져야 하므로 하나의 파드로 묶어 배포하는 것이 원칙입니다.

---

2. 서비스 (Service): 안정적인 네트워크 연결의 핵심

앞서 설명한 대로 파드는 쉽게 생성되고 삭제되며, 그때마다 IP 주소가 바뀝니다. 만약 프론트엔드 파드가 백엔드 파드와 통신해야 하는데 백엔드 파드의 IP가 계속 바뀐다면 연결이 끊어질 것입니다. 서비스(Service)는 이렇게 동적으로 변하는 파드 집합에 변하지 않는 고정 IP 주소와 도메인 이름(DNS)을 부여하는 추상화된 네트워킹 구성요소입니다.

• 라벨(Label)과 셀렉터(Selector) 원리: 서비스는 트래픽을 보낼 목적지 파드를 찾을 때 IP가 아닌 '이름표(Label)'를 사용합니다. 예를 들어 app=backend라는 라벨이 붙은 파드가 3개 있다면, 서비스는 이 3개의 파드를 자신의 목적지 그룹으로 인식합니다. 파드가 죽어서 새로운 IP를 가진 파드가 생성되더라도 app=backend 라벨만 붙어 있다면 서비스가 알아서 새로운 파드로 트래픽을 연결해 줍니다.
• 로드밸런싱(Load Balancing): 서비스는 자신에게 들어온 요청을 연결된 여러 파드들에게 균등하게 분산시켜 줍니다.

---

레플리카세트(ReplicaSet), 디플로이먼트(Deployment), 리소스쿼터(ResourceQuota)

쿠버네티스에는 컨테이너 애플리케이션의 고가용성을 보장하고, 무중단 배포를 수행하며, 클러스터의 자원을 효율적으로 분배하기 위해 사용하는 핵심 오브젝트인 레플리카세트(ReplicaSet), 디플로이먼트(Deployment), 리소스쿼터(ResourceQuota)가 있습니다.

1. 레플리카세트 (ReplicaSet): 지정된 파드 개수 유지 보장

레플리카세트는 사용자가 선언한 특정 개수의 파드(Pod) 복제본이 항상 실행되도록 보장하는 컨트롤러입니다.

• 작동 원리 (Reconciliation Loop): 레플리카세트는 지속적으로 클러스터 내의 파드 상태를 모니터링합니다. 현재 실행 중인 파드 개수가 설정된 replicas 수치보다 적으면 새로운 파드를 생성하고, 많으면 남는 파드를 삭제합니다.
• 라벨 셀렉터 (Label Selector): 서비스(Service)와 마찬가지로 레플리카세트도 라벨(Label)을 기준으로 관리할 파드를 식별합니다. (예: app=ai-agent 라벨이 붙은 파드를 관리)

예시: 커넥티드카 차량 내에서 발생하는 사용자의 음성 명령을 처리하는 'AI 카 에이전트 API' 파드를 항상 5개로 유지하도록 레플리카세트를 설정했다고 가정해 보겠습니다. 트래픽 폭주나 워커 노드의 하드웨어 장애로 인해 파드 2개가 다운되면, 레플리카세트는 이를 즉각 감지하고 정상적인 다른 노드에 파드 2개를 새로 생성하여 항상 '5개'라는 원하는 상태(Desired State)를 복구합니다.

---

2. 디플로이먼트 (Deployment): 무중단 배포와 버전 관리의 핵심

디플로이먼트는 레플리카세트를 관리하는 상위 수준의 컨트롤러입니다. 실제 운영 환경에서는 파드나 레플리카세트를 직접 생성하지 않고, 디플로이먼트를 통해 애플리케이션을 배포하고 관리하는 것이 표준입니다.

• 무중단 배포 (Rolling Update): 애플리케이션의 새로운 버전이 릴리즈될 때, 기존 서비스의 중단 없이 점진적으로 파드를 교체합니다.
• 버전 롤백 (Rollback): 새로 배포한 버전에 치명적인 버그가 발견될 경우, 디플로이먼트의 히스토리(Revision) 관리 기능을 통해 명령어 한 줄로 이전의 안정적인 버전으로 즉각 되돌릴 수 있습니다.
• 레플리카세트 제어: 디플로이먼트 설정 파일(YAML)의 파드 템플릿 이미지를 변경하면, 디플로이먼트는 새로운 레플리카세트를 생성하여 새 버전의 파드를 띄우고, 구버전의 레플리카세트 파드 수는 점진적으로 0으로 줄입니다.

예시: 'AI 카 에이전트' 백엔드 시스템을 v1.0에서 최신 인식 모델이 적용된 v2.0으로 업데이트해야 합니다. 디플로이먼트를 사용하면 사용자 요청을 계속 처리하는 와중에, v2.0 파드를 하나씩 띄우고 정상 작동이 확인되면 v1.0 파드를 하나씩 내리는 롤링 업데이트를 수행합니다. 이를 통해 차량 내 서비스 다운타임 없이 매끄러운 배포가 가능합니다.

---

3. 리소스쿼터 (ResourceQuota): 네임스페이스 단위의 자원 통제

리소스쿼터는 단일 애플리케이션이 아닌 네임스페이스(Namespace, 논리적 클러스터 분할 단위) 전체의 리소스 사용량을 제한하는 정책 오브젝트입니다.

• 자원 독점 방지: 클러스터 전체의 컴퓨팅 자원(CPU, 메모리) 한도를 설정하여 특정 프로젝트나 팀이 클러스터 자원을 고갈시키는 것을 막습니다.
• 오브젝트 개수 제한: 파드(Pod), 서비스(Service), 컨피그맵(ConfigMap) 등 특정 쿠버네티스 리소스가 생성될 수 있는 최대 개수를 제한할 수 있습니다.

예시: 대규모 기업의 단일 쿠버네티스 클러스터를 여러 개발팀이 공유할 때, 네임스페이스를 팀별로 분리하여 운영합니다. 이때 '개발1팀'의 네임스페이스에는 리소스쿼터를 적용하여 최대 CPU 사용량을 100 코어, 메모리를 200GB, 최대 파드 개수를 50개로 제한할 수 있습니다. 누군가 실수로 파드를 1,000개 생성하는 스크립트를 실행하더라도, 리소스쿼터 한도에 도달하면 쿠버네티스 API 서버가 추가 생성을 차단하여 타 팀의 서비스 운영을 보호합니다.