Qwerty Kim

당신은 쿠버네티스가 필요하지 않다

#docker #kubernetes #infra

도커가 나타난지 10여년. 홈 서버를 2년 간 운영해오면서 내가 다다른 결론은 “지금은 쿠버네티스가 필요하지 않다” 라는 것이다.

서비스 개발의 요구사항들이 점차 다양해지면서 새로운 패턴과 아키텍처가 등장했다. 때문에 “아키텍처"를 주제로 대화를 나누다 보면 “쿠버네티스"가 단골 주제로 나오기까지 한다. 하지만 작은 규모의 서비스를 운영하는데 쿠버네티스를 구성하는 데에는 큰 이점이 따르지 않는다.

쿠버네티스를 운영하면서 가장 많은 시간을 쏟게 되는 부분은 서비스가 아니다. 바로 클러스터 그 자체에 시간을 많이 쏟게 된다.

인증서 갱신, 노드 업그레이드, RBAC 설정, 스토리지 클래스 관리, 모니터링 스택 유지 등… 서비스 몇 개를 운영하기 위해 지불하는 비용이 해결해야 할 진짜 문제의 비용을 넘어서기 시작한다.

결국 나는 Docker Compose로 돌아오게 되었다. 마치 바쁜 도시 생활을 벗어나 시골로 돌아온 것만 같았다.

Docker Compose로 충분할까

로그 수집 서비스 Logtide는 Docker Compose 하나로 매일 50만 건의 로그를 처리하면서 **가용성 99.8%**를 유지하고 있다.1

서버는 Hetzner CX33 (4vCPU, 8GB RAM, 160GB NVMe) 단 한 대.

항목수치
일일 로그 처리500,000건
피크 처리량50 logs/sec
P50 응답 지연45ms
P95 응답 지연120ms
배포 시간30초
장애 복구 시간2분
월 비용€12.50

같은 워크로드를 관리형 쿠버네티스 클러스터에 올릴 경우, 매달 $150~300가 청구될 것으로 예상하고 있다. 연간 비용으로 환산하면 $1,600~3,400 규모로, 작은 팀에게는 결코 적지 않은 금액임이 분명하다.

Logtide의 확장 계획은 여전히 Compose의 연장선이다.

규모구성비용
50만/일 (현재)서버 1대, Docker Compose~$14/월
500만/일서버 3대 (primary 1 + read replica 2), 수동 페일오버~$50/월
5,000만/일서버 10대+, K8s 또는 Swarm 검토 시점$500+/월

쿠버네티스가 정말 필요할까

쿠버네티스는 서비스가 특정 규모 이상으로 복잡해지지 않는 한, 시기상조일 수 있다.

K8s가 필요한 조건Compose로 충분한 경우
여러 서비스들의 오케스트레이션서비스가 몇 개 안 된다
예측 불가능한 트래픽에 자동 스케일링트래픽이 예측 가능하다
멀티 리전 / 멀티 클라우드 배포단일 리전으로 충분하다
여러 팀의 독립적 배포소규모 팀이 함께 운영한다

Docker Compose로 살아남기

Docker Compose가 쿠버네티스를 완벽하게 대체하기에는 부족함이 있는 것은 사실이다. 하지만 Compose로도 서비스를 운영하는 데에는 손색이 없다.

자동 재시작 정책

Compose의 restart 옵션은 쿠버네티스 Deployment의 재시작 정책을 대체할 수 있다.

1
2
3
4

services:
  nginx:
    image: nginx:1.29.6
    restart: unless-stopped

헬스체크

컨테이너가 실행 중이라고 해서 서비스가 정상이라는 의미는 아니다. healthcheck 옵션은 쿠버네티스의 liveness/readiness probe를 대체할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

services:
  postgres:
    image: postgres:17
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  nginx:
    image: nginx:1.29.6
    depends_on:
      db:
        condition: service_healthy

nginx는 postgres가 준비된 후에 실행된다.

리소스 제한

한 서비스가 자원을 과도하게 사용하여 다른 서비스가 정상적으로 동작하지 않을 수 있다. deploy.resources 옵션으로 쿠버네티스의 resources.limits 를 대체한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

services:
  nginx:
    image: nginx:1.29.6
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 256M
          cpus: "0.5"

무중단 배포

k8s의 롤링 업데이트를 대체할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#!/bin/bash

# 새 이미지 pull
docker compose pull backend

# 기존 컨테이너를 유지한 채 레플리카를 3개로 확장
docker compose up -d --scale backend=3 --no-recreate

# 새 컨테이너가 healthy 상태가 될 때까지 대기
sleep 10

# 기존 컨테이너 교체 후 2개로 축소
docker compose up -d --scale backend=2

# Nginx 설정 리로드 등의 후행 작업
docker compose exec nginx nginx -s reload

완벽한 Blue/Green 배포는 아니지만, 대부분의 서비스에는 이 정도면 충분하다.

시크릿 관리

Compose의 secrets는 호스트의 파일을 컨테이너 내부 /run/secrets/에 마운트하는 방식이다. 환경변수와 달리 docker inspect에 노출되지 않고, 컨테이너 안에서만 읽을 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

본질적으로 쿠버네티스의 secrets가 Compose보다 더 안전한 것은 아니다.

모니터링

모니터링도 어렵지 않게 붙일 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

services:
  prometheus:
    image: prom/prometheus:v3.10.0
    restart: unless-stopped
    volumes:
      - ./config/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./data/prometheus:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:12.3
    restart: unless-stopped
    volumes:
      - ./data/grafana:/var/lib/grafana
    ports:
      - "3000:3000"

백업

쿠버네티스에서 PersistentVolume 백업은 꽤 번거로운 작업이지만, Compose에서는 볼륨이 호스트 디렉토리에 바인드 되어 있으니, 백업 자체가 간편해진다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#!/bin/bash

# DB 덤프
docker compose exec db pg_dump -U postgres postgres | gzip > backup-$(date +%Y%m%d).sql.gz

# 파일 백업
rsync -az ./data/ remote:/backups/

# 30일 이상 된 백업 정리
find /backups -mtime +30 -delete

쿠버네티스가 필요한 순간

Docker Compose에도 한계는 있다.

  • 자동 스케일링 — 트래픽에 따라 인스턴스를 자동으로 늘리고 줄이는 건 안 된다.
  • 노드 페일오버 — 서버가 죽으면 서비스도 같이 죽는다. 다중 노드 HA는 Compose의 영역이 아니다.
  • 서비스 디스커버리 — 서비스가 수십 개로 늘어나면 Compose의 DNS 기반 네트워킹만으로는 부족하다.
  • 멀티 테넌시 — 여러 팀이 독립적으로 배포하고 격리가 필요하다면 쿠버네티스의 네임스페이스가 맞다.

다만 이런 요구사항이 실제로 생기는 시점은 대부분 생각보다 훨씬 늦다.

결론

기술 선택은 현재의 문제를 푸는 것이지, 미래의 문제를 대비하는 게 아니다. 남는 시간에 제품을 만들자. 인프라는 제품이 아니다.

  1. Kubernetes Is Overkill for 99% of Apps ↩︎