Docker로 컨테이너 하나를 띄우는 것까지는 쉽지만, 서비스가 커지면 컨테이너가 여러 개로 늘어나고 버전이 바뀌고 장애가 나고 트래픽이 출렁이면서 운영 난이도가 급격히 올라갑니다. 쿠버네티스(Kubernetes)는 이런 운영 문제를 “컨테이너를 어떤 서버에 어떻게 배치하고, 언제 늘리고, 장애가 나 어떻게 복구할지”까지 자동화해서 관리해주는 컨테이너 오케스트레이션 시스템입니다.
빠른 체크포인트
- 쿠버네티스는 컨테이너 배포와 운영을 자동화하는 시스템입니다.
- 서버 여러 대에 컨테이너를 분산 배치하고 상태를 계속 감시합니다.
- 장애가 나면 자동으로 다시 띄우고, 트래픽이 늘면 자동으로 늘릴 수 있습니다.
- 롤링 업데이트로 무중단에 가깝게 버전 교체가 가능합니다.
- 운영 관점에서 “원하는 상태(desired state)를 선언하면, 실제 상태를 맞춰주는” 구조로 움직입니다.
1. 쿠버네티스가 해결하는 문제
쿠버네티스는 단순히 컨테이너를 실행하는 도구가 아니라, 운영에서 반복되는 일을 표준화합니다. 예를 들어 컨테이너가 죽었을 때 재시작, 트래픽 증가 시 서버 추가 없이 수평 확장, 신규 버전 배포 시 점진적 교체, 서버 장애 시 다른 노드로 자동 재배치 같은 것들이 대표적입니다. 결국 목표는 사람이 매번 수동으로 조치하던 운영 작업을 시스템이 자동으로 처리하게 만드는 것입니다.
2. 핵심 개념 6가지
쿠버네티스 문서나 예제를 볼 때 가장 자주 등장하는 단어만 이해해도 전체 그림이 빠르게 잡힙니다.
2-1) 클러스터(Cluster), 노드(Node)
클러스터는 쿠버네티스가 컨테이너를 운영하는 전체 묶음이고, 노드는 컨테이너가 실제로 실행되는 서버(가상머신 포함)입니다. 여러 노드를 하나의 운영 단위로 묶어서 관리하는 것이 쿠버네티스의 기본 전제입니다.
2-2) 파드(Pod)
파드는 쿠버네티스에서 배포의 최소 단위입니다. 컨테이너 하나만 들어갈 수도 있고, 강하게 붙어 함께 움직여야 하는 컨테이너 여러 개가 들어갈 수도 있습니다. 운영 관점에서는 “컨테이너를 직접 다룬다”기보다 “파드를 다룬다”에 가깝습니다.
2-3) 디플로이먼트(Deployment)
디플로이먼트는 파드를 원하는 개수만큼 유지하고, 버전을 바꾸면 롤링 업데이트로 교체해주는 객체입니다. 운영에서 가장 많이 쓰이는 배포 단위라고 보면 됩니다.
2-4) 서비스(Service)
서비스는 파드가 늘었다 줄었다 하더라도 안정적으로 접근할 수 있는 고정된 접점(가상 IP/DNS)을 제공합니다. 파드는 IP가 자주 바뀌는데, 서비스가 그 변화를 감싸서 “항상 같은 이름으로 접근”하게 만들어줍니다.
2-5) 인그레스(Ingress)
인그레스는 외부 HTTP/HTTPS 트래픽을 클러스터 내부 서비스로 라우팅하는 관문입니다. 도메인 기반 라우팅, 경로 기반 라우팅, TLS 종료 같은 작업을 담당합니다. Nginx 리버스 프록시를 클러스터 방식으로 운영한다고 보면 이해가 빠릅니다.
2-6) 컨피그맵(ConfigMap)과 시크릿(Secret)
환경변수, 설정 파일 같은 운영 설정을 코드와 분리해서 관리합니다. Secret은 비밀번호나 토큰 같은 민감 정보를 저장하는 데 사용합니다.
3. 쿠버네티스의 동작 방식: 선언형(Desired State) 관리
쿠버네티스의 핵심 철학은 선언형입니다. “파드를 3개 유지해줘” 같은 원하는 상태를 선언하면, 쿠버네티스 컨트롤러가 실제 상태를 계속 감시하면서 맞춥니다. 파드가 하나 죽으면 다시 띄우고, 노드가 죽으면 다른 노드로 재배치하고, 지정한 개수보다 적으면 추가로 올립니다. 운영자 입장에서는 수동 조치가 줄고, 시스템이 자동으로 상태를 복구합니다.
4. Docker와 쿠버네티스의 관계
Docker는 컨테이너를 만들고 실행하는 도구이고, 쿠버네티스는 컨테이너를 대규모로 운영하기 위한 관리 시스템입니다. 쉽게 말하면 Docker는 “컨테이너를 띄우는 기술”이고, 쿠버네티스는 “컨테이너를 여러 서버에서 안정적으로 돌리기 위한 운영 플랫폼”입니다. 실무에서는 개발 환경은 Docker Compose로 시작하고, 운영 또는 스케일이 필요한 환경은 쿠버네티스로 넘어가는 흐름이 많습니다.
5. 언제 쿠버네티스를 쓰는 게 좋은가
쿠버네티스는 강력하지만 학습 비용과 운영 복잡도가 있습니다. 아래 조건이 많아질수록 도입 가치가 올라갑니다.
- 서비스가 여러 개(마이크로서비스)로 나뉘어 있고 배포가 잦다
- 트래픽 변동이 커서 자동 스케일이 필요하다
- 장애 복구와 무중단 배포가 중요하다
- 서버가 여러 대로 운영되고 있고 배치/스케줄링이 필요하다
- 설정/시크릿/네트워크 정책을 표준화해 관리하고 싶다
반대로 단일 서버, 단일 서비스, 배포가 드물고 트래픽 변동이 작은 환경이라면 Docker Compose가 더 효율적인 경우도 많습니다.
6. 간단 예시로 보는 느낌(Deployment + Service)
쿠버네티스에서 “3개 파드를 유지하고 서비스로 묶는다”는 감각은 이런 형태입니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
replicas: 3
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: myapp:1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: app-svc
spec:
selector:
app: app
ports:
- port: 80
targetPort: 8080정리
쿠버네티스는 컨테이너 운영의 표준 플랫폼에 가깝고, 배포, 스케일링, 장애 복구를 자동화해 운영 부담을 줄여주는 오케스트레이션 시스템입니다. Pod, Deployment, Service, Ingress 같은 핵심 개념만 잡아도 운영 구조가 빠르게 이해되고, Docker Compose에서 시작해 서비스 규모가 커질 때 자연스럽게 확장 가능한 선택지가 됩니다.