☸️ 쿠버네티스(Kubernetes), 생각보다 어렵지 않다
왜 지금 쿠버네티스인가
최근 회사에서 기존 서버 환경을 컨테이너로 전환하는 프로젝트를 진행하면서, 쿠버네티스에 대한 궁금증이 생겼습니다. 컨테이너는 이미 Docker로 충분히 익숙한데, 왜 굳이 쿠버네티스라는 복잡한 도구가 필요한지 의문이 들더라고요.
답부터 말하면, 단일 컨테이너와 수십 개의 컨테이너를 관리하는 것은 완전히 다른 문제입니다. 쿠버네티스는 바로 이 '규모의 문제'를 해결하기 위해 만들어진 도구입니다.
통계를 보면 현재 조직의 77%가 컨테이너 사용을 확대하고 있고, 쿠버네티스는 사실상 컨테이너 오케스트레이션의 표준이 되었습니다. 2026년 현재, 클라우드 네이티브 환경에서 쿠버네티스 없는 인프라를 상상하기 어려울 정도죠.
쿠버네티스가 정확히 뭘까
쿠버네티스(Kubernetes, 줄여서 K8s)는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈소스 플랫폼입니다. 그리스어로 '조타수' 또는 '선장'을 뜻하는데, 배를 안전하게 목적지로 이끄는 역할을 한다는 의미입니다.
구글이 2014년에 오픈소스로 공개했고, 내부에서 수십억 개의 컨테이너를 관리했던 Borg 시스템의 경험을 바탕으로 만들어졌습니다.
쿠버네티스의 핵심 역할:
- 컨테이너 자동 배포 및 스케줄링
- 애플리케이션 상태 모니터링 및 자동 복구
- 트래픽에 따른 자동 확장/축소
- 서비스 간 네트워킹 및 로드 밸런싱
- 설정 및 보안 정보 관리
음식 배달 서비스로 비유하면, 쿠버네티스는 주문량에 따라 배달원을 자동으로 늘리고 줄이며, 배달원이 아프면 즉시 대체 인력을 투입하고, 가장 효율적인 경로로 음식을 배달하게 하는 똑똑한 관리 시스템이라고 할 수 있습니다.
인프라의 진화 과정
쿠버네티스를 이해하려면 인프라가 어떻게 발전해왔는지 알아야 합니다.
| 시대 | 특징 | 장점 | 단점 |
|---|---|---|---|
| 물리 서버 | 서버 1대에 앱 1개 | 안정성, 성능 | 자원 낭비, 확장성 제한 |
| 가상화 | 서버 1대에 VM 여러 개 | 자원 효율성 증대 | 무거운 OS, 느린 시작 |
| 컨테이너 | 가벼운 애플리케이션 패키징 | 빠른 시작, 이식성 | 대규모 관리 복잡성 |
| 쿠버네티스 | 컨테이너 오케스트레이션 | 자동화, 확장성, 안정성 | 초기 학습 곡선 |
각 단계는 이전 단계의 한계를 해결하면서 발전했습니다. 컨테이너가 패키징 문제를 해결했다면, 쿠버네티스는 대규모 컨테이너 관리 문제를 해결한 것이죠.
쿠버네티스 아키텍처의 핵심
쿠버네티스 클러스터는 크게 두 부분으로 나뉩니다.
Control Plane (제어 평면)
클러스터의 "두뇌" 역할을 하는 부분입니다:
- API Server: 모든 요청의 진입점
- etcd: 클러스터의 모든 데이터를 저장하는 데이터베이스
- Scheduler: Pod를 어느 노드에 배치할지 결정
- Controller Manager: 원하는 상태를 유지하도록 지속적으로 감시
Worker Node (워커 노드)
실제 애플리케이션이 실행되는 곳입니다:
- kubelet: 컨테이너 실행을 담당하는 에이전트
- kube-proxy: 네트워킹 처리
- Container Runtime: 실제 컨테이너를 실행 (주로 containerd)
Pod: 쿠버네티스의 최소 단위
Pod는 쿠버네티스에서 가장 중요한 개념입니다. 컨테이너를 직접 배포하는 대신, 컨테이너를 Pod로 감싸서 배포합니다.
Pod의 특징:
- 보통 1개의 컨테이너를 포함 (가장 일반적)
- 같은 Pod 내 컨테이너들은 네트워크와 스토리지를 공유
- 고유한 IP 주소를 가짐
- 일시적 존재 (언제든 삭제/재생성 가능)
왜 컨테이너 대신 Pod를 사용할까요? 밀접하게 연관된 컨테이너들을 함께 관리하기 위해서입니다. 예를 들어, 웹 애플리케이션과 로그 수집기가 항상 함께 있어야 한다면 같은 Pod에 배치할 수 있습니다.
핵심 구성 요소들
Deployment: 애플리케이션 관리자
가장 많이 사용하는 워크로드 타입입니다. 무상태(stateless) 애플리케이션을 관리할 때 사용하며, 자동으로 Pod를 생성하고 관리합니다.
Service: 네트워크 접근
Pod는 일시적이라 IP가 계속 바뀝니다. Service는 안정적인 네트워크 접근점을 제공합니다.
- ClusterIP: 클러스터 내부에서만 접근
- NodePort: 노드의 특정 포트로 외부 접근
- LoadBalancer: 클라우드의 로드밸런서 사용
ConfigMap과 Secret
애플리케이션 설정을 코드와 분리해서 관리합니다:
- ConfigMap: 일반적인 설정값
- Secret: 비밀번호, API 키 등 민감한 정보
Persistent Volume
컨테이너는 기본적으로 무상태이지만, 데이터베이스처럼 상태를 유지해야 하는 경우 PV(Persistent Volume)를 사용합니다.
kubectl: 쿠버네티스와 대화하는 방법
kubectl은 쿠버네티스 클러스터를 관리하는 명령줄 도구입니다. 자주 사용하는 명령어들을 정리해보면:
# 리소스 조회
kubectl get pods
kubectl get services
kubectl get deployments
# 자세한 정보 확인
kubectl describe pod my-pod
kubectl logs my-pod
# 리소스 생성/수정
kubectl apply -f app.yaml
kubectl create deployment nginx --image=nginx
# 스케일링
kubectl scale deployment my-app --replicas=5
# 디버깅
kubectl exec -it my-pod -- bash
확장의 비밀
쿠버네티스에서 확장할 때 중요한 원칙이 있습니다: Pod 내부에 컨테이너를 추가하는 게 아니라, Pod 자체를 여러 개 만든다는 것입니다.
예를 들어 트래픽이 증가했을 때:
- ❌ 1개 Pod에 컨테이너 3개 추가
- ✅ 3개 Pod 생성 (각각 1개 컨테이너)
이를 **수평 확장(Horizontal Scaling)**이라고 하며, 이것이 쿠버네티스가 높은 확장성을 제공하는 핵심입니다.
HPA(Horizontal Pod Autoscaler)를 사용하면 CPU 사용률이나 메모리 사용률에 따라 자동으로 Pod 수를 조절할 수도 있습니다.
실무에서의 쿠버네티스
2026년 현재 쿠버네티스는 다음과 같은 영역에서 핵심적으로 사용되고 있습니다:
- 마이크로서비스 아키텍처: 서비스 간 통신, 배포, 관리
- CI/CD 파이프라인: GitOps와 결합한 자동화 배포
- 클라우드 네이티브 애플리케이션: 클라우드의 장점을 최대한 활용
- 하이브리드/멀티 클라우드: 여러 클라우드 환경 통합 관리
특히 ChatGPT 같은 AI 서비스들도 내부적으로 쿠버네티스를 사용해서 대규모 트래픽을 처리하고 있죠.
시작하는 방법
로컬에서 쿠버네티스를 경험해보고 싶다면:
- Minikube: 로컬 환경에서 쿠버네티스 클러스터 실행
- K3s: 경량화된 쿠버네티스 배포판
- Docker Desktop: 내장된 쿠버네티스 기능 활용
클라우드에서는 관리형 서비스를 사용하는 것이 일반적입니다:
- AWS EKS
- Google GKE
- Azure AKS
- Naver Cloud Platform NKS
쿠버네티스는 처음에는 복잡해 보이지만, 핵심 개념들을 차근차근 이해하다 보면 생각보다 체계적이고 논리적인 시스템이라는 것을 알 수 있습니다. 무엇보다 한 번 제대로 익혀두면 현대적인 인프라 환경에서 큰 힘이 되는 기술이죠.