클라우드 환경에서 애플리케이션을 운영하다 보면 Docker, Container, Kubernetes라는 단어를 자주 만나게 됩니다. 특히 쿠버네티스(Kubernetes)는 대규모 서비스를 안정적으로 운영하기 위한 핵심 기술로 자리 잡았습니다. 그렇다면 쿠버네티스는 정확히 무엇이고, 왜 필요한 걸까요?
쿠버네티스 (Kubernetes)란?
쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 자동화하는 오픈소스 플랫폼입니다. 쉽게 말하면 수많은 컨테이너를 자동으로 관리해 주는 컨테이너 오케스트레이션(Container Orchestration) 시스템입니다.
Docker와 같은 기술을 사용하면 애플리케이션과 필요한 실행 환경을 하나의 컨테이너로 묶을 수 있습니다. 문제는 컨테이너가 많아질 때입니다. 컨테이너가 2~3개라면 사람이 직접 관리할 수도 있습니다. 하지만 서비스 규모가 커져 수십 개, 수백 개, 수천 개의 컨테이너가 운영된다면 이야기가 달라집니다.
예를 들어 이런 문제들이 발생합니다.
- 컨테이너 하나가 갑자기 종료되면 어떻게 할까?
- 사용자가 급증하면 서버를 어떻게 늘릴까?
- 여러 서버에 컨테이너를 어떻게 배치할까?
- 새로운 버전의 애플리케이션을 어떻게 안전하게 배포할까?
- 특정 서버가 장애를 일으키면 서비스를 어떻게 복구할까?
이러한 작업을 사람이 일일이 처리하는 것은 현실적으로 어렵습니다. 쿠버네티스는 이런 작업들을 자동화합니다.
Docker와 Kubernetes는 무엇이 다를까?
쿠버네티스를 처음 접하면 가장 많이 헷갈리는 부분이 바로 Docker와의 차이입니다. 두 기술은 경쟁 관계라기보다 역할이 다릅니다. Docker가 애플리케이션을 컨테이너라는 상자에 담는 기술이라면, Kubernetes는 수많은 컨테이너를 어디에 배치하고 어떻게 운영할지를 관리하는 시스템이라고 이해하면 쉽습니다.
예를 들어 택배 시스템으로 비유해 보겠습니다. Docker가 상품을 규격화된 택배 상자에 포장하는 역할이라면, 쿠버네티스는 수많은 택배 상자를 목적지에 맞게 분류하고 배치하고 문제가 발생했을 때 다시 처리하는 대형 물류센터의 자동화 시스템과 비슷합니다. 따라서 컨테이너 규모가 커질수록 쿠버네티스의 역할이 중요해집니다.
쿠버네티스의 기본 구조
쿠버네티스를 이해하려면 몇 가지 핵심 개념을 알아두는 것이 좋습니다.
Cluster
쿠버네티스가 관리하는 전체 환경을 클러스터(Cluster)라고 합니다. 클러스터는 크게 Control Plane과 Worker Node로 구성됩니다.
Control Plane
쿠버네티스 클러스터 전체를 관리하는 일종의 두뇌입니다. 어떤 애플리케이션을 어디에 배치할지 결정하고 클러스터의 현재 상태를 지속적으로 확인합니다.
Worker Node
실제 애플리케이션이 실행되는 서버입니다. 하나의 쿠버네티스 클러스터에는 여러 개의 Worker Node가 존재할 수 있습니다.
Pod
쿠버네티스에서 애플리케이션을 실행하는 가장 작은 배포 단위입니다. 일반적으로 하나 이상의 컨테이너가 Pod 안에서 실행됩니다. 구조를 간단히 표현하면 다음과 같습니다.
Kubernetes Cluster
→ Control Plane
→ Worker Node
→ Pod
→ Container
→ Pod
→ Container
즉,
Cluster → Node → Pod → Container
구조로 이해하면 됩니다.
쿠버네티스가 하는 핵심 역할
쿠버네티스가 강력한 이유는 단순히 컨테이너를 실행하는 것에 그치지 않기 때문입니다.
자동 배포
개발자가 원하는 애플리케이션 상태를 정의하면 쿠버네티스가 적절한 서버를 찾아 컨테이너를 배치합니다.
자동 복구(Self-healing)
실행 중인 Pod에 문제가 생기면 이를 감지하고 새로운 Pod를 실행할 수 있습니다. 서버 하나에 장애가 발생하더라도 다른 서버에서 애플리케이션을 다시 실행할 수 있습니다.
자동 확장(Scaling)
서비스 이용자가 증가하면 더 많은 Pod를 실행하도록 확장할 수 있습니다. 반대로 사용량이 감소하면 불필요한 리소스를 줄일 수도 있습니다.
로드 밸런싱
여러 개의 Pod가 실행되고 있다면 사용자의 요청을 적절하게 분산할 수 있습니다. 특정 Pod에 트래픽이 집중되는 것을 방지할 수 있는 것입니다.
롤링 업데이트
새로운 버전의 애플리케이션을 배포할 때 기존 서비스를 한 번에 종료하지 않고 점진적으로 새로운 버전으로 교체할 수 있습니다. 문제가 발생하면 이전 버전으로 되돌리는 전략도 사용할 수 있습니다.
Kubernetes Deployment란?
쿠버네티스에서 자주 사용하는 개념 중 하나가 Deployment입니다. Deployment는 애플리케이션의 원하는 상태를 정의하고 관리합니다. 예를 들어 개발자가 다음과 같이 요청했다고 생각해 보겠습니다.
“웹 애플리케이션 Pod를 항상 3개 실행해 줘.”
쿠버네티스는 현재 상태를 지속적으로 확인합니다. 정상적인 상태라면,
Pod A + Pod B + Pod C = 3개
가 실행됩니다.
그런데 Pod B가 장애로 종료되면 실행 중인 Pod는 2개가 됩니다. 쿠버네티스는 이를 감지하고 새로운 Pod D를 생성합니다.
결과적으로 다시,
Pod A + Pod C + Pod D = 3개
상태를 만들어 냅니다. 이처럼 ‘현재 상태’를 사용자가 정의한 ‘원하는 상태(Desired State)’에 맞추는 것이 쿠버네티스의 매우 중요한 운영 원리입니다.
Service는 왜 필요할까?
Pod는 상황에 따라 생성되고 삭제될 수 있습니다. 문제는 새로운 Pod가 만들어질 때 네트워크 주소도 달라질 수 있다는 점입니다. 이 문제를 해결하기 위해 사용하는 것이 Service입니다.
Service는 여러 Pod 앞에서 안정적인 접근 지점을 제공합니다. 사용자는 각각의 Pod 위치를 알 필요 없이 Service에 요청을 보내면 됩니다.
구조는 대략 다음과 같습니다.
User
↓
Service
↓
Pod A / Pod B / Pod C
Service가 여러 Pod로 트래픽을 전달합니다.
쿠버네티스의 가장 중요한 개념, Desired State
쿠버네티스를 이해할 때 반드시 알아야 할 개념이 있습니다. 바로 Desired State, 즉 원하는 상태입니다. 전통적인 서버 관리에서는 사람이 직접 명령을 내리는 경우가 많았습니다.
“서버 A에서 프로그램을 실행해.”
반면 쿠버네티스에서는 원하는 결과를 선언합니다.
“이 애플리케이션을 항상 5개 실행된 상태로 유지해.”
그러면 쿠버네티스가 현재 상태를 확인하면서 원하는 상태를 유지하도록 지속적으로 조정합니다. 이를 선언적 관리(Declarative Management)라고 합니다.
이러한 구조 덕분에 대규모 인프라를 자동화하기가 훨씬 쉬워집니다.
실제 서비스에서는 어떻게 사용될까?
예를 들어 온라인 쇼핑몰을 운영한다고 생각해 보겠습니다. 쇼핑몰 시스템에는 다음과 같은 여러 서비스가 존재할 수 있습니다.
- 로그인 서비스
- 상품 조회 서비스
- 장바구니 서비스
- 주문 서비스
- 결제 서비스
- 추천 서비스
각 서비스를 컨테이너로 구성하고 Kubernetes에서 운영할 수 있습니다. 평소에는 주문 서버가 3개만 실행되다가 대규모 할인 행사가 시작되어 사용자가 급증하면 주문 서비스의 Pod를 더 많이 실행할 수 있습니다. 트래픽이 감소하면 다시 Pod 수를 줄일 수도 있습니다.
즉,
트래픽 증가 → Pod 증가 → 트래픽 감소 → Pod 감소
와 같은 탄력적인 인프라 운영이 가능해집니다.
Kubernetes와 MSA의 관계
쿠버네티스는 MSA(Microservices Architecture)와 함께 자주 언급됩니다. 기존의 모놀리식 애플리케이션은 하나의 거대한 프로그램 안에 여러 기능이 들어가 있습니다. 반면 MSA는 애플리케이션을 작은 서비스 단위로 분리합니다. 예를 들어,
쇼핑몰
→ 회원 서비스
→ 상품 서비스
→ 주문 서비스
→ 결제 서비스
→ 배송 서비스
와 같이 나눌 수 있습니다.
서비스가 많아질수록 컨테이너 수도 증가하고 운영 복잡성도 높아집니다. 이때 Kubernetes를 사용하면 각각의 서비스를 독립적으로 배포하고 확장하고 복구하는 구조를 구축할 수 있습니다.
다만 MSA를 사용한다고 반드시 Kubernetes가 필요한 것은 아니며, Kubernetes를 사용한다고 반드시 MSA 구조여야 하는 것도 아닙니다.
Kubernetes의 장점
쿠버네티스를 도입하면 대규모 애플리케이션 운영에서 여러 장점을 얻을 수 있습니다.
자동화
배포, 확장, 복구 등의 작업을 자동화할 수 있습니다.
확장성
사용량에 따라 애플리케이션 규모를 탄력적으로 조정할 수 있습니다.
고가용성
일부 컨테이너나 서버에 장애가 발생하더라도 서비스를 지속할 수 있는 구조를 만들기 쉽습니다.
클라우드 활용성
AWS, Google Cloud, Microsoft Azure뿐 아니라 자체 데이터센터에서도 사용할 수 있습니다.
DevOps 및 CI/CD와의 결합
GitHub Actions, Jenkins, Argo CD 등의 도구와 결합하여 개발부터 배포까지 자동화된 파이프라인을 구축할 수 있습니다.
Kubernetes에도 단점은 있다
물론 모든 서비스에 쿠버네티스가 필요한 것은 아닙니다. 쿠버네티스는 강력한 만큼 구조가 복잡합니다. Pod, Deployment, Service, ConfigMap, Secret, Ingress, Namespace 등 알아야 할 개념이 많습니다.
또한 클러스터 운영을 위해 모니터링, 로그 관리, 보안, 네트워크, 스토리지 등에 대한 지식도 필요합니다. 따라서 작은 규모의 서비스에서는 Kubernetes를 도입하면서 얻는 장점보다 운영 복잡성과 비용이 더 커질 수도 있습니다. 쿠버네티스 자체가 목적이 되어서는 안 되는 이유입니다.
Kubernetes를 공부한다면 어떤 순서가 좋을까?
처음부터 Kubernetes의 모든 기능을 공부하려 하면 상당히 어렵게 느껴질 수 있습니다. 다음과 같은 흐름으로 접근하면 이해하기 쉽습니다.
Linux 기본 → Docker → Container → Kubernetes → Helm → CI/CD → Observability
특히 Kubernetes를 공부하기 전에 Docker와 컨테이너의 기본 원리를 이해해 두는 것이 좋습니다. 그다음 Pod, Deployment, Service를 중심으로 Kubernetes의 기본 구조를 이해하고, 이후 ConfigMap, Secret, Ingress, Persistent Volume 등의 개념으로 확장하는 방식이 효과적입니다.
마무리
쿠버네티스를 한 문장으로 정리하면 다음과 같습니다.
쿠버네티스(Kubernetes)는 수많은 컨테이너를 원하는 상태로 유지하면서 배포·확장·복구·네트워크 등을 자동으로 관리하는 컨테이너 오케스트레이션 플랫폼입니다.
Docker가 컨테이너 시대를 열었다면 Kubernetes는 대규모 컨테이너를 실제 서비스 환경에서 운영할 수 있도록 만들어 주는 핵심 플랫폼이라고 볼 수 있습니다. 특히 클라우드, DevOps, MSA, CI/CD를 공부한다면 Kubernetes는 자연스럽게 만나게 되는 기술입니다.
그리고 Kubernetes를 어느 정도 이해했다면 그다음 중요한 주제가 있습니다. 바로 Observability(옵저버빌리티)입니다. 수백 개의 Pod와 서비스가 움직이는 환경에서는 단순히 시스템이 ‘살아 있는지’ 확인하는 것만으로 부족하기 때문입니다.
Metrics + Logs + Traces
이 세 가지 데이터를 활용해 복잡한 Kubernetes 환경에서 ‘지금 시스템 내부에서 무슨 일이 벌어지고 있는가?’를 파악하는 것이 Kubernetes Observability의 핵심입니다.