쿠버네티스(Kubernetes) 완벽 이해: 도커를 넘어선 컨테이너 오케스트레이션

쿠버네티스(Kubernetes, k8s)는 수십, 수백 개의 컨테이너를 여러 서버에 걸쳐 배포·확장·관리하는 일을 자동화하는 컨테이너 오케스트레이션 도구입니다. 도커가 애플리케이션 하나를 패키징한다면, 쿠버네티스는 선언한 상태대로 컨테이너 무리를 유지하며 재시작·재배치·확장을 알아서 처리합니다.

쿠버네티스(Kubernetes)란 무엇인가?

쿠버네티스는 '컨테이너 오케스트레이션(Container Orchestration)' 플랫폼입니다. 도커(Docker)가 단일 컨테이너의 생성과 관리를 혁신했다면, 쿠버네티스는 대규모 컨테이너의 배포, 확장, 관리를 자동화합니다. 구글(Google)이 방대한 컨테이너 인프라를 관리하려고 만든 내부 시스템(Borg)의 노하우를 바탕으로 오픈소스로 공개한 것이 시작입니다.

오케스트라 지휘자가 수많은 악기가 조화롭게 연주하도록 이끌듯, 쿠버네티스는 수많은 컨테이너가 안정적으로 서비스를 제공하도록 지휘합니다.

왜 쿠버네티스가 필요한가?

관리할 컨테이너가 사람 손으로 감당하기 어려울 만큼 많아지면 쿠버네티스가 필요해집니다. 초기 서비스나 작은 프로젝트에서는 도커 컨테이너 몇 개를 수동으로 관리할 수도 있습니다. 하지만 서비스 규모가 커지고 마이크로서비스 아키텍처(MSA)를 도입하면 컨테이너 수가 급격히 늘고, 다음과 같은 문제가 생깁니다.

• 특정 컨테이너가 죽었을 때 어떻게 자동으로 재시작할 것인가?
• 트래픽이 몰릴 때 컨테이너 수를 어떻게 자동으로 늘리고(Scale-out), 트래픽이 줄면 다시 줄일(Scale-in) 것인가?
• 여러 대의 서버(노드) 자원을 효율적으로 배분하여 컨테이너를 어떻게 배치할 것인가?
• 새로운 버전의 앱을 배포할 때 서비스 중단 없이(Zero-downtime) 어떻게 업데이트를 진행할 것인가?

쿠버네티스는 이런 문제를 선언적(Declarative)인 방법으로 해결합니다. "서버 3대에 웹 앱 컨테이너 5개를 항상 유지해줘"라고 선언만 하면, 쿠버네티스가 그 상태를 모니터링하며 일치하도록 끊임없이 제어합니다.

쿠버네티스의 핵심 오브젝트는 무엇인가요?

쿠버네티스는 클러스터 상태를 여러 기본 오브젝트로 표현하며, 이를 이해하는 것이 쿠버네티스를 익히는 첫걸음입니다.

1. 파드 (Pod)

파드는 쿠버네티스에서 배포할 수 있는 가장 작고 기본적인 실행 단위입니다. 파드는 하나 이상의 컨테이너를 포함할 수 있고, 같은 파드 안의 컨테이너는 스토리지 볼륨, 네트워크 IP 주소, 실행 옵션 등을 공유합니다. 일반적으로 파드 하나에 핵심 애플리케이션 컨테이너 하나를 두는 것이 권장되지만, 로깅 수집기나 프록시 같은 보조 컨테이너(Sidecar)를 함께 두기도 합니다.

2. 레플리카셋 (ReplicaSet)

레플리카셋은 지정된 개수(Replica)만큼의 파드가 항상 실행되도록 보장합니다. 파드가 문제로 종료되거나 노드에 장애가 나면 레플리카셋이 즉시 새 파드를 만들어 설정된 개수를 맞춥니다. 이를 통해 서비스의 높은 가용성(High Availability)을 확보할 수 있습니다.

3. 디플로이먼트 (Deployment)

디플로이먼트는 레플리카셋과 파드의 상태를 선언적으로 업데이트하게 해주는 상위 컨트롤러입니다. 실무에서는 파드나 레플리카셋을 직접 만들기보다 주로 디플로이먼트로 애플리케이션을 배포합니다. 무중단 롤링 업데이트(Rolling Update)나 이전 버전으로의 롤백(Rollback)을 손쉽게 수행할 수 있습니다.

4. 서비스 (Service)

서비스는 계속 바뀌는 파드 집합에 안정적인 고정 IP(ClusterIP)와 도메인 이름(DNS)을 부여합니다. 파드는 수명 주기가 짧아 생성·소멸될 때마다 IP 주소가 바뀌기 때문입니다. 서비스 타입에 따라 클러스터 내부에서만 통신할지, 외부로 노출할지(NodePort, LoadBalancer) 정할 수 있습니다.

5. 인그레스 (Ingress)

인그레스는 클러스터 외부에서 내부 서비스로 들어오는 HTTP/HTTPS 경로 라우팅을 관리하는 오브젝트입니다. 하나의 외부 IP로 여러 서비스에 트래픽을 분산하고, SSL/TLS 인증서 처리와 이름 기반 가상 호스팅을 지원해 효율적인 트래픽 관리가 가능합니다.

쿠버네티스 클러스터는 어떻게 구성되나요?

쿠버네티스 클러스터는 크게 두 가지 역할의 노드(서버)로 구성됩니다.

• 컨트롤 플레인 (Control Plane / Master Node): 클러스터 전체를 관리하고 제어하는 두뇌 역할을 합니다. API 서버, 클러스터 데이터를 저장하는 etcd 분산 저장소, 스케줄러(Scheduler), 컨트롤러 매니저(Controller Manager) 등으로 구성됩니다.
• 워커 노드 (Worker Node): 실제 애플리케이션 컨테이너(파드)가 실행되는 작업자 서버입니다. 각 워커 노드에는 컨트롤 플레인과 통신하는 Kubelet, 컨테이너 런타임(Docker, containerd 등), 네트워크 프록시인 Kube-proxy가 실행됩니다.

우리 팀도 쿠버네티스를 도입해야 할까요?

조직 규모와 서비스 성격에 따라 다릅니다. 쿠버네티스는 강력하지만 도입 비용과 러닝 커브가 매우 높아서, 무작정 도입하기보다 면밀히 따져 봐야 합니다.

쿠버네티스 클러스터를 직접 구축해 운영(On-premise)하려면 상당한 인프라 전문 지식이 필요합니다. 그래서 많은 기업이 클라우드 제공업체의 관리형(Managed) 쿠버네티스 서비스(AWS EKS, Google GKE, Azure AKS 등)를 활용합니다. 관리형 서비스를 쓰면 컨트롤 플레인 관리를 클라우드 업체에 맡기고 개발자는 워커 노드와 애플리케이션 배포에만 집중할 수 있어 운영 부담을 크게 줄일 수 있습니다.

요약

도커가 애플리케이션 패키징 문제를 해결했다면, 쿠버네티스는 대규모 환경의 배포와 운영 문제를 해결하는 클라우드 네이티브 시대의 표준 운영체제와 같습니다. 현대적인 백엔드 시스템이나 데이터 파이프라인을 구축하려 한다면 쿠버네티스 생태계에 대한 이해는 선택이 아닌 필수가 되어가고 있습니다.