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

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

도커(Docker)가 단일 컨테이너의 생성과 관리를 혁신했다면, 쿠버네티스(Kubernetes, 줄여서 k8s)는 수십, 수백 개의 컨테이너를 대규모로 배포, 확장, 관리하는 과정을 자동화해주는 '컨테이너 오케스트레이션(Container Orchestration)' 도구입니다. 구글(Google)에서 자신들의 방대한 컨테이너 인프라를 관리하기 위해 만든 내부 시스템(Borg)의 노하우를 바탕으로 오픈소스로 공개한 것이 그 시작입니다.

오케스트라의 지휘자가 수많은 악기가 조화로운 음악을 연주하도록 지휘하듯, 쿠버네티스는 수많은 컨테이너들이 안정적으로 서비스를 제공할 수 있도록 지휘하는 역할을 담당합니다.

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

초기 단계의 서비스나 작은 규모의 프로젝트에서는 몇 개의 도커 컨테이너를 수동으로 관리하는 것이 가능할지 모릅니다. 하지만 서비스 규모가 커지고 마이크로서비스 아키텍처(MSA)를 도입하게 되면 관리해야 할 컨테이너의 수는 기하급수적으로 늘어납니다.

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

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

쿠버네티스의 핵심 오브젝트(Objects)

쿠버네티스는 클러스터의 상태를 나타내기 위해 여러 가지 기본 오브젝트를 사용합니다. 이를 이해하는 것이 쿠버네티스 마스터의 첫걸음입니다.

1. 파드 (Pod)

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

2. 레플리카셋 (ReplicaSet)

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

3. 디플로이먼트 (Deployment)

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

4. 서비스 (Service)

파드는 수명 주기가 짧아 생성되고 소멸될 때마다 IP 주소가 계속 변경됩니다. 서비스는 이렇게 동적으로 변하는 파드들의 논리적 집합에 안정적인 고정 IP(ClusterIP)와 도메인 이름(DNS)을 부여하는 역할을 합니다. 서비스 타입에 따라 클러스터 내부에서만 통신할지, 외부로 서비스를 노출할지(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 등)를 활용합니다. 관리형 서비스를 사용하면 컨트롤 플레인의 관리를 클라우드 업체에 맡기고, 개발자는 워커 노드와 애플리케이션 배포에만 집중할 수 있어 운영 부담을 크게 줄일 수 있습니다.

요약

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