쿠버네티스

왜 배우는가: 쿠버네티스는 컨테이너 운영을 자동화하는 사실상의 표준 플랫폼이라 실무 인프라 설계와 클라우드 전환 과제에서 반복해 다뤄진다. 시험에서도 개념, 컴포넌트, HPA 같은 자동 확장 기능이 함께 출제되어 기본 정의와 구조를 정확히 익혀야 한다.

출제 이력: 제137회 4교시 3번, 제133회 1교시 12번

1. 한 줄 정의와 핵심 키워드

쿠버네티스는 컨테이너화된 애플리케이션의 배포·확장·운영을 선언된 상태대로 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

• 컨테이너 오케스트레이션
• 선언적 상태 관리(Desired State)
• 컨트롤 플레인
• Pod
• 자동 확장(Autoscaling)
• 자가 치유(Self-healing)
• 서비스 디스커버리

2. 개념 풀이

쉬운 말로 하면 쿠버네티스는 여러 대의 서버에 흩어진 컨테이너를 대신 관리해 주는 관리자다. 사람이 컨테이너를 하나씩 띄우고 죽은 것을 살리는 대신, "컨테이너를 몇 개 유지하라"는 목표만 선언하면 시스템이 그 상태를 맞춘다.

정식 정의는 다음과 같다. 쿠버네티스(Kubernetes, K8s)는 오픈소스 시스템이며, 컨테이너 애플리케이션의 배포, 확장, 관리를 자동화한다. 상표와 운영은 클라우드 네이티브 컴퓨팅 재단(CNCF)이 맡는다.

핵심 원리는 선언적(Declarative) API다. 사용자는 원하는 상태를 YAML 매니페스트로 기술하고, 컨트롤러가 현재 상태를 지속적으로 관찰하며 차이를 줄인다. 이 방식은 절차(A를 하고 B를 하라)를 정의하는 오케스트레이션과 다르다. 쿠버네티스는 독립적이고 조합 가능한 제어 루프로 구성되어, 중앙 집중 제어 없이도 현재 상태를 의도된 상태로 이끈다.

Pod는 쿠버네티스가 배포하는 가장 작은 단위다. 하나 이상의 컨테이너가 네트워크와 스토리지를 공유하며 함께 실행된다. 대부분의 경우 Pod 하나에 컨테이너 하나를 넣고, 같은 Pod를 여러 개 복제해 부하를 나눈다.

서비스 디스커버리는 Pod가 생성·삭제되며 IP가 바뀌어도 하나의 고정된 주소와 포트로 접근할 수 있게 하는 기능이다. Service 객체가 여러 Pod를 묶어 로드 밸런싱을 수행한다.

3. 등장 배경과 필요성

컨테이너 기술이 보편화되면서 수십에서 수천 개의 컨테이너를 수작업으로 관리하기 어려워졌다. 노드 장애 시 재기동, 트래픽 증감에 따른 증설, 배포 중 무중단 전환을 사람이 처리하면 운영 비용과 장애 위험이 커진다.

이 문제를 해결하기 위해 컨테이너 배치, 상태 점검, 복구, 확장을 자동화하는 플랫폼이 필요해졌다. 쿠버네티스는 이 역할을 맡아 워크로드를 여러 노드에 분산하고, 장애가 나면 Pod를 다른 노드에 다시 배치한다. 또한 온프레미스와 퍼블릭 클라우드에서 같은 방식으로 운영할 수 있어, 멀티·하이브리드 클라우드 환경에서 이식성을 확보하는 수단이 된다.

이 배경 때문에 쿠버네티스는 DevOps와 클라우드 네이티브 아키텍처의 기반 기술로 자리 잡았다. 실무에서는 CI/CD 파이프라인과 연계해 배포 자동화를 완성하는 용도로도 쓰인다.

4. 구성요소·원리·절차

쿠버네티스는 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 나뉜다. 컨트롤 플레인은 클러스터 전체의 의사결정과 상태 관리를 맡고, 워커 노드는 실제 컨테이너를 실행한다. 두 영역을 연결하는 중심은 API 서버다.