1.Docker와 Kubernetes: 비슷한 듯 다른, 컨테이너 생태계 이야기
쿠버네티스(Kubernetes)와 도커(Docker)를 처음 접하면 가장 많이 하는 말 중 하나가 있습니다.
“쿠버네티스랑 도커랑 YAML 설정해서 실행하는 것이 비슷하네.”
겉보기에는 사실입니다. 두 기술 모두 YAML 파일로 애플리케이션을 정의하고 실행하기 때문이죠. 하지만 이 비슷함 뒤에는 중요한 차이가 숨어 있습니다. 이번 글에서는 Docker와 Kubernetes의 관계, 역사적 맥락, 그리고 왜 Kubernetes가 Docker를 대체하는 것처럼 보이는지를 흐름 있게 정리해 보겠습니다.
1. Docker란 무엇인가?
컨테이너 기술 자체를 제공하는 플랫폼
개발자가 애플리케이션과 필요한 의존성을 하나의 이미지로 패키징 → 어디서나 동일하게 실행 가능
로컬 PC, 테스트 서버, 운영 서버 어디든 docker run 한 줄이면 실행
Docker Compose 예시
version: '3'
services:
web:
image: nginx:latest
ports:
- "8080:80"
db:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD: example
✅docker-compose up을 실행하면 웹 서버와 DB가 한 번에 실행됩니다.
하지만 여기까지입니다. Docker는 여러 서버에 분산 배포, 자동 복구, 자동 스케일링 같은 기능은 제공하지 않습니다. 그래서 등장한 것이 오케스트레이션 도구입니다.
2. Kubernetes의 등장과 발전
Kubernetes는 구글이 내부 운영 경험을 바탕으로 만든 컨테이너 오케스트레이션 시스템입니다.
초창기(1.20 이전)에는 Kubernetes가 컨테이너 런타임으로 Docker를 직접 사용했습니다.
즉, Kubernetes가 Pod을 실행하면 내부적으로 Docker 엔진을 호출해 컨테이너를 띄웠습니다.하지만 Docker는 Kubernetes 표준인 CRI(Container Runtime Interface) 를 직접 지원하지 않았습니다. 이 때문에 Kubernetes는 중간 계층인 Dockershim을 둬야 했습니다.
결국 1.24 버전부터 Dockershim이 제거되면서, 현재는 containerd와 CRI-O 같은 런타임이 Kubernetes의 표준이 되었습니다.
✅ 요약: Kubernetes는 더 이상 Docker 위에서 동작하지 않는다.
3. Kubernetes YAML 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
✅ kubectl apply -f deployment.yml을 실행하면 Pod이 3개 생성되고, Kubernetes가 알아서 상태를 모니터링하고 필요 시 자동으로 재시작합니다.
Docker Compose와 YAML 구조가 비슷해 보이는 이유가 바로 여기에 있습니다. 둘 다 선언적 방식으로 컨테이너 실행을 정의하기 때문입니다.
4. Docker와 Kubernetes의 차이
✅Docker는 개발 환경에서 컨테이너를 쉽게 다루는 데 강점이 있고, Kubernetes는 운영 환경에서 컨테이너를 안정적으로 운영하는 데 강점을 가집니다.
5. Docker → Kubernetes 전환의 의미
많은 기업이 이렇게 말합니다.
“예전엔 Docker로 서버에 직접 배포했는데, 이제 Kubernetes로 운영한다.”
이 말은 곧:
Docker 단독 배포: docker run으로 컨테이너 실행, 장애 대응은 수동
Kubernetes 배포: kubectl apply로 선언적 배포, Kubernetes가 자동 복구/스케일링 담당
즉, 컨테이너 운영 수준이 한 단계 업그레이드된 것입니다.
6. Docker는 사라진 걸까?
전혀 아니다
Docker는 여전히 이미지 빌드 도구로 널리 쓰입니다.
docker build → docker push → Kubernetes가 이미지 받아 실행
또한 소규모 환경에서는 Docker Compose만으로도 충분히 운영 가능합니다.
✅ 다만 대규모 운영 환경에서는 Kubernetes가 사실상의 표준이 되었습니다.
7. 맺으며
다시 처음 질문으로 돌아가 봅시다.
“쿠버네티스랑 도커랑 YAML 설정해서 실행하는 것이 비슷하네.”
네, 맞습니다. 둘 다 YAML로 애플리케이션을 정의합니다.
하지만 Docker는 컨테이너를 만드는 도구, Kubernetes는 그 컨테이너들을 관리하고 조율하는 오케스트레이션 시스템이라는 점에서 본질적인 차이가 있습니다.
결국 Docker와 Kubernetes는 경쟁 관계가 아니라 보완 관계입니다.
개발 단계에서는 Docker로 이미지를 빌드하고,
운영 단계에서는 Kubernetes가 이를 안정적으로 배포·운영합니다.
그리고 이 흐름은 앞으로도 컨테이너 기반 클라우드 네이티브 환경에서 계속 이어질 것입니다.
2. Docker vs Kubernetes, 규모별 선택 기준
1. 개발 단계
개발자 PC나 테스트 서버에서는 Docker 단독으로 쓰는 경우가 많습니다.
→ docker run, docker-compose.yml 정도로 충분히 컨테이너 실행·테스트 가능.CI/CD 과정에서 이미지 빌드·배포 단위로 Docker는 계속 쓰입니다.
2. 운영 단계 – 소규모 서비스
중소규모/스타트업에서는 보통 Docker 단독 + Docker Compose 또는 단일 서버 배포로도 충분합니다.
→ 서버 1~2대에서 돌아가는 웹 서비스라면, 쿠버네티스의 복잡한 관리 기능까지는 과할 수 있음.
→ 유지 관리 인력이 많지 않은 경우엔 오히려 Docker만 쓰는 것이 단순하고 효율적.
3. 운영 단계 – 대규모/성장 단계
**Kubernetes(K8s)**는 서버 수십~수백 대, 마이크로서비스, 고가용성(HA), 자동 스케일링이 필요한 경우 강력합니다.
→ 서비스 트래픽이 커지고, 컨테이너 수가 많아지면 수동 관리 불가 → K8s 필요
→ 예: 네이버, 카카오, 쿠팡 같은 기업 환경
4. 현실적인 중소기업 사례
최근에는 **클라우드 매니지드 쿠버네티스 (EKS, GKE, AKS)**가 보편화되면서, 소기업에서도 쓰는 경우가 늘고 있습니다.
→ 직접 쿠버네티스 클러스터를 구축하지 않고, 클라우드에서 제공하는 관리형 서비스 활용
→ "작은 팀인데도 쿠버네티스를 쓴다"는 건 이런 클라우드 기반 K8s를 뜻하는 경우가 많음.
✅ 정리
작은 프로젝트/소기업 → Docker 단독(또는 Docker Compose)으로도 충분.
트래픽 증가/서비스 복잡 → Kubernetes로 전환하는 게 맞음.
즉, Docker와 Kubernetes는 대체 관계라기보다는 "규모/운영 환경에 따라 선택 or 병행"하는 관계라고 보는 게 정확합니다.
3. 쿠버네티스 운영 환경, 예전과 지금
✅과거: 직접 쿠버네티스 서버 구축
몇 년 전만 해도 쿠버네티스(Kubernetes) 클러스터를 직접 설치하고 관리해야 했습니다.
마스터 노드, 워커 노드, etcd, 네트워크 플러그인(CNI), 스토리지, 로드밸런서까지 직접 세팅
작은 팀이나 중소기업은 관리하기에 너무 복잡하고 부담스러움
✅ 현재: 클라우드 매니지드 쿠버네티스 서비스
지금은 클라우드 매니지드 쿠버네티스 서비스 덕분에 훨씬 단순해졌습니다.
AWS → EKS (Elastic Kubernetes Service)
GCP → GKE (Google Kubernetes Engine)
Azure → AKS (Azure Kubernetes Service)
네이버 클라우드 → NKS (Naver Kubernetes Service)
카카오 i 클라우드, NHN Cloud 등도 유사 서비스 제공
이런 서비스는 이미 쿠버네티스 클러스터(마스터 + 워커)를 클라우드에서 자동으로 제공해 줍니다.
사용자는 그냥 kubectl + YAML(manifest) 파일로 Pod, Deployment, Service 등을 정의해서 올리면 됩니다.
⚡️ 현재 운영 흐름
개발자 → Dockerfile 로 이미지 빌드
이미지 저장소 → Docker Hub, ECR, GCR 등 업로드
운영 환경(Kubernetes 클러스터) → deployment.yaml, service.yaml 작성
배포 → kubectl apply -f deployment.yaml
???? 그러면 클라우드 쿠버네티스가 알아서 Pod 생성, 스케일링, 장애 복구, 로드밸런싱까지 처리
✅ 정리
예전: 쿠버네티스 서버(클러스터)를 직접 구축해야 했음 → 진입장벽 높음
지금: 클라우드에서 쿠버네티스를 서비스 형태로 제공 → YAML만 작성하면 실행 가능
개발자 역할 변화:
예전 → 쿠버네티스 설치/운영에 집중
지금 → 쿠버네티스 위에서 앱을 배포/운영에 집중
4. docker-compose.yml → Kubernetes YAML 변환 예제
1) 기존 Docker Compose
db:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD: example
ports:
- "3306:3306"
web:
image: myapp:latest
ports:
- "8080:8080"
depends_on:
- db
2)변환된 Kubernetes 매니페스트
1. MySQL Deployment + Service
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD
value: "example"
ports:
- containerPort: 3306
---
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
targetPort: 3306
selector:
app: mysql
2. Web App Deployment + Service
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: myapp:latest
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: LoadBalancer
ports:
- port: 8080
targetPort: 8080
selector:
app: web
✅ 이렇게 하면 docker-compose up 대신, kubectl apply -f 로 동일한 애플리케이션을 쿠버네티스에서 실행할 수 있습니다.
5.Helm Chart란?
1) Helm Chart 개념
Helm은 쿠버네티스 패키지 매니저로, 복잡한 YAML 매니페스트를 하나의 패키지(Chart)로 관리할 수 있게 해줍니다.
마치 리눅스에서 apt, yum으로 패키지를 설치하는 것과 유사
여러 개의 Deployment, Service, ConfigMap, Secret 등을 하나의 Chart로 묶어 관리 가능
즉, helm install myapp ./mychart 명령어 한 번으로 수십 개의 리소스를 배포할 수 있습니다.
2) Helm Chart 사용 현황과 변화 추세
초창기 쿠버네티스 보급기: Helm Chart는 사실상 표준 배포 방식으로 자리잡음
현재: 여전히 널리 사용되지만, GitOps(ArgoCD, Flux)와 함께 사용하는 경우 증가
추세: Helm Chart는 배포 정의를 단순화하는 핵심 도구로 여전히 필수적 → 하지만 점점 GitOps 파이프라인 내 구성 요소로 흡수되는 방향
Helm Chart 배포 방식 예시
???? Chart 디렉토리 구조
mychart/
Chart.yaml # 차트 메타데이터
values.yaml # 기본값 설정
templates/ # 쿠버네티스 리소스 템플릿들
deployment.yaml
service.yaml
values.yaml 예시
image: repository: myapp tag: latest service: type: LoadBalancer port: 8080
templates/deployment.yaml (Helm 템플릿)
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-web
spec:
replicas: 1
selector:
matchLabels:
app: {{ .Release.Name }}-web
template:
metadata:
labels:
app: {{ .Release.Name }}-web
spec:
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: 8080
배포 명령어
helm install myapp ./mychart
위 명령으로 Deployment, Service 등이 한꺼번에 생성됨
✅ Helm의 장점
YAML 중복 제거 (values.yaml로 변수 관리)
환경별 배포(dev, staging, prod) 분리 용이
복잡한 매니페스트를 하나의 Chart로 패키징
커뮤니티에서 제공하는 수많은 Chart (예: NGINX, MySQL, Prometheus)
결론:
Helm Chart는 쿠버네티스 배포를 자동화·표준화하는 핵심 도구이며, 지금도 많이 사용됩니다. 다만 ArgoCD 같은 GitOps 툴과 함께 쓰이는 흐름이 점점 강해지고 있습니다.
6.일반 클라우드 서버와 Kubernetes 클러스터 운영 비용 차이
1. 일반 클라우드 서버 (VM/인스턴스 단독 운영)
구조: 하나 또는 소수의 VM에 Docker로 컨테이너 직접 실행
장점:
단순함 → 서버 1~2대만 운영 가능
초기 비용 낮음
관리 부담 적음 (클러스터, 오토스케일링 불필요)
단점:
서버 다운 시 서비스 전체 중단 가능
확장성 제한 (트래픽 증가 시 수동 증설)
비용 예시 (AWS 기준, 1개월 단가)
2. Kubernetes 클러스터 (관리형 서비스 기준)
구조: 클러스터(마스터 + 워커 노드) 위에서 여러 Pod 운영
장점:
무중단 배포, 자동 스케일링, 장애 복구 가능
여러 애플리케이션을 같은 클러스터에서 운영 가능
Helm/GitOps 등으로 배포 관리 표준화
단점:
초기 구성과 개념 학습 필요
워커 노드 비용 + 관리형 서비스 비용 발생
비용 예시 (AWS EKS 기준, 1개월 단가)
즉, 단순 VM 운영 대비 약 2~4배 정도 초기 비용 증가 가능
그러나 자동 확장, 무중단 배포, 관리 편의 등 가치는 비용 대비 크다
3. 소규모 업체 기준 전략
트래픽 적고 단순 서비스 → 일반 클라우드 서버 + Docker → 비용 최소화
무중단 배포 필요, 서비스 확장 계획 → Kubernetes 클러스터 → 초기 비용 증가, 운영 안정성 확보
최근 클라우드 관리형 K8s + Spot 인스턴스/자동 스케일링 활용 시 비용 효율화 가능
✅ 정리
비용: Kubernetes > 단일 VM 운영
가치: K8s는 확장성, 안정성, 배포 자동화 제공 → 장기적으로 운영 비용 대비 효율 ↑
소규모 업체도 서비스 성장과 무중단 배포를 고려하면 Kubernetes 도입 가능성 ↑
댓글 ( 0)
댓글 남기기