Kubernetes란 무엇이고, 왜 필요한가
컨테이너 오케스트레이션의 핵심 개념
Kubernetes는 Google이 내부에서 쓰던 컨테이너 관리 시스템(Borg)을 오픈소스로 공개한 컨테이너 오케스트레이션 플랫폼이다. 쉽게 말하면, 컨테이너를 어디에 얼마나 띄울지, 장애가 나면 어떻게 복구할지를 자동으로 처리해주는 지휘자 역할이다.
Docker만으로도 컨테이너를 실행할 수 있지만, 실제 서비스 운영에서는 다음과 같은 문제가 생긴다.
- 서버 3대에 컨테이너 20개를 어떻게 분배하지?
- 컨테이너가 죽으면 누가 다시 띄워주지?
- 트래픽이 몰리면 자동으로 스케일 아웃이 되나?
- 무중단 배포는 어떻게 하지?
이 모든 걸 K8s가 해결해 준다.
Docker Compose와의 차이점
Docker Compose는 단일 머신에서 여러 컨테이너를 정의하는 도구다. 개발 환경에서는 충분하지만, 프로덕션 환경에서는 한계가 명확하다. Kubernetes는 여러 노드(서버)에 걸쳐 컨테이너를 배포하고, 자동 복구/스케일링/롤링 업데이트까지 지원한다.
핵심 구성 요소 한눈에 보기
- Pod: 컨테이너의 최소 실행 단위. 보통 1 Pod = 1 컨테이너
- Deployment: Pod의 개수, 업데이트 전략을 선언적으로 관리
- Service: Pod에 접근하기 위한 네트워크 엔드포인트
- Ingress: 외부 HTTP 트래픽을 내부 Service로 라우팅
- Namespace: 리소스를 논리적으로 분리하는 가상 클러스터
로컬 환경 셋업부터 첫 배포까지
로컬 클러스터 선택: Minikube vs Kind vs Docker Desktop
입문자가 가장 먼저 막히는 부분이 "클러스터를 어디서 만들지?"다.
- Minikube: 가장 무난한 선택. VM 또는 Docker 드라이버로 단일 노드 클러스터 생성. 애드온 시스템이 잘 되어 있어 대시보드, Ingress 등을 쉽게 활성화할 수 있다.
- Kind (Kubernetes in Docker): Docker 컨테이너 안에 클러스터를 만드는 방식. 가볍고 빠르지만 네트워크 설정이 조금 까다롭다.
- Docker Desktop 내장 K8s: 클릭 한 번으로 활성화 가능. 가장 간편하지만 커스터마이징 여지가 적다.
처음이라면 Minikube + Docker 드라이버 조합을 추천한다.
첫 번째 Deployment 작성하기
Kubernetes는 YAML 파일로 원하는 상태를 선언한다. apiVersion: apps/v1, kind: Deployment, spec.replicas: 3 같은 구조로 작성한 뒤 kubectl apply -f deployment.yaml로 적용하면 K8s가 알아서 3개의 Pod를 생성한다.
처음에는 YAML 구조가 복잡하게 느껴지지만, 핵심 패턴은 반복된다. apiVersion, kind, metadata, spec 이 4가지 필드만 기억하면 80%는 해결된다.
Service로 외부 접근 열기
Pod만 만들면 외부에서 접근할 수 없다. kind: Service에서 type: NodePort 또는 type: LoadBalancer를 지정해야 한다. 로컬 환경에서는 NodePort로 테스트하고, 클라우드에서는 LoadBalancer를 사용하는 게 일반적이다.
실전 배포 전략과 운영 노하우
롤링 업데이트와 롤백
Kubernetes의 가장 강력한 기능 중 하나가 무중단 배포다. Deployment의 이미지 태그를 변경하고 kubectl apply하면, 기존 Pod를 하나씩 교체하는 롤링 업데이트가 자동으로 진행된다. 문제가 발견되면 kubectl rollout undo deployment/[이름] 한 줄로 이전 버전으로 롤백할 수 있다.
리소스 제한과 HPA(Auto Scaling)
Pod에 CPU/메모리 제한을 걸지 않으면 하나의 Pod가 노드 자원을 독점할 수 있다. resources.requests와 resources.limits를 반드시 설정해야 한다. 트래픽 급증에 대비하려면 HPA(Horizontal Pod Autoscaler)를 설정한다. CPU 사용률이 70%를 넘으면 Pod를 자동으로 늘리고, 한가해지면 줄이는 식이다.
ConfigMap과 Secret으로 설정 분리
환경변수나 설정 파일을 컨테이너 이미지에 넣지 말아야 한다. ConfigMap은 일반 설정을, Secret은 비밀번호/API 키 같은 민감 정보를 분리 관리한다. 이미지를 다시 빌드하지 않고도 설정만 바꿀 수 있어서 운영이 훨씬 유연해진다.
장단점 비교표와 실전 팁
| 구분 | 장점 | 단점 |
|---|---|---|
| 확장성 | HPA로 자동 스케일링, 수천 Pod도 관리 가능 | 소규모 서비스에는 오버 엔지니어링일 수 있음 |
| 안정성 | 자동 복구(Self-healing), 롤링 업데이트, 즉시 롤백 | 클러스터 자체 장애 시 복구가 복잡함 |
| 학습 곡선 | 커뮤니티와 문서가 방대함, 표준화된 패턴 | 초기 개념 이해에 2~4주 정도 소요 |
| 비용 | 리소스 효율적 활용으로 장기적 비용 절감 | 관리형 K8s(EKS/GKE/AKS) 클러스터 자체 비용 발생 |
| 생태계 | Helm, ArgoCD, Prometheus 등 풍부한 도구 연동 | 도구가 너무 많아서 선택 피로도 발생 |
현장에서 검증된 실전 팁
Namespace를 적극 활용하라. dev/staging/prod 환경을 Namespace로 분리하면, 하나의 클러스터에서 여러 환경을 안전하게 운영할 수 있다.
Liveness/Readiness Probe를 반드시 설정하라. 이걸 안 넣으면 컨테이너가 행(hang) 상태에 빠져도 K8s가 모르고 트래픽을 계속 보낸다.
latest 태그 대신 구체적인 버전을 쓰라. nginx:latest 대신 nginx:1.25.3처럼 명시해야 배포의 재현성이 보장된다.
kubectl 별칭(alias)을 세팅하라. alias k=kubectl, alias kgp='kubectl get pods' 정도만 설정해도 일상 작업 속도가 2배는 빨라진다.
처음부터 Helm을 배우라. YAML 파일이 늘어나면 관리가 지옥이 된다. Helm 차트를 사용하면 템플릿화된 배포 패키지로 환경별 설정을 깔끔하게 관리할 수 있다.
마무리: 누구에게 Kubernetes를 추천하는가
- 마이크로서비스 아키텍처를 도입했거나 계획 중인 팀
- 트래픽 변동이 크고 자동 스케일링이 필요한 서비스
- 무중단 배포와 빠른 롤백이 필수인 프로덕션 환경
- Docker는 어느 정도 쓸 줄 알고, 다음 단계로 나아가고 싶은 백엔드/DevOps 엔지니어
- 클라우드 벤더 종속 없이 이식성 있는 인프라를 구축하고 싶은 조직
서비스가 단일 컨테이너로 충분하거나, 팀 규모가 1~2명이라면 Docker Compose나 클라우드의 컨테이너 서비스(AWS ECS, GCP Cloud Run)부터 시작하는 것도 현명한 선택이다. 도구는 상황에 맞게 쓰는 게 중요하다.
Kubernetes는 처음엔 진입 장벽이 높게 느껴지지만, 기본 개념(Pod, Deployment, Service, Ingress)을 순서대로 익히면 생각보다 빨리 적응할 수 있다. 이 글이 K8s 여정에 좋은 출발점이 되길 바란다.
