6개월 전 docker swarm mode (1.12 부터 통합된 그거)로 올려놨던 서비스 몇개. 이제 k8s로 이전하는 중. 왜 바꿨는지 정리.
swarm 좋았던 점:
- docker compose 익숙하면 러닝커브 제로 수준.
docker stack deploy -c docker-compose.yml mystack - 기본 세팅이 빠름.
docker swarm init한 줄 - built-in routing mesh — 어느 노드로 요청 오든 해당 서비스 컨테이너로 라우팅
swarm 한계:
- ingress controller / 복잡한 라우팅 규칙 제한적
- configmap은 있는데 secret rotation 같은 운영 기능이 덜 무르익음
- helm 같은 패키지 매니저 생태계 없음. 직접 stack 파일 관리
- 커뮤니티 확장이 k8s 대비 훨씬 적음. 모니터링/로깅 도구 연동이 번거로움
- 대규모 클러스터 (수백 노드) 운영 사례가 많지 않음
k8s 쪽에서 지금 쓰는 것들:
- deployment / service / ingress
- configmap / secret
- helm chart (prometheus, grafana 등 기본 스택)
- nginx-ingress-controller
- cert-manager (let's encrypt 자동 발급)
마이그 진행방식: 서비스별로 helm chart 만들고, stage에서 동시에 swarm/k8s에 띄워놓고 비교 → k8s 쪽으로 DNS 스위치 → swarm 측 철수. 한번에 넘기지 않고 점진적으로.
빡셌던 건 ingress 쪽. swarm의 routing mesh처럼 암묵적 분배가 되는게 아니라 명시적 ingress 리소스 만들고 rule 정의 해야됨. 처음엔 귀찮은데 익숙해지면 강력함.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: api.example.com
http:
paths:
- path: /
backend:
serviceName: web
servicePort: 80
결론: 소규모 / 단순 케이스에서는 swarm이 여전히 간편하고 충분. 근데 조금만 요구사항 커져도 k8s로 가는게 장기적으로 덜 피곤. 커뮤니티 모멘텀이 k8s로 완전히 쏠린게 체감됨. 회사 표준도 k8s로 맞출 계획.
