해당 포스팅은 시작하세요! 도커/쿠버네티스: 친절한 설명으로 쉽게 이해하는 컨테이너 관리 책을 참고로 작성되었습니다.
목차
 |
 |
CH3. 도커 스웜
3.1 도커 스웜을 사용하는 이유
1. 단일 호스트 도커의 한계
- 하나의 물리적 서버에서만 컨테이너 운영
- CPU, 메모리, 디스크 용량 제약 발생
- 확장성 문제 직면
- docker ps, create, run 등의 명령어는 단일 도커 엔진에서만 작동
2. 클러스터 방식의 해결책
- 자원 통합: 여러 서버의 자원을 하나의 풀(Pool)로 통합
- 수평적 확장: 8GB 메모리 서버 3대(24GB) + 8GB 추가 서버 = 32GB 가용 메모리
- 비용 효율성: 고성능 단일 서버보다 적정 성능의 다수 서버 활용이 경제적
3. 클러스터링 시 해결해야 할 과제
- 서비스 디스커버리(Service Discovery): 어떤 서버에 컨테이너를 할당할지 결정
- 스케줄링: 컨테이너 배치 최적화
- 로드밸런싱: 부하 분산 처리
- 고가용성(High Availability): 서비스 연속성 보장
4. 도커 스웜의 역할
- 위 문제들을 해결하는 도커 공식 클러스터링 솔루션
- 여러 도커 호스트를 단일 가상 도커 호스트로 통합
- 오픈소스로 무료 사용 가능
- 도커에 내장된 오케스트레이션 도구
도커 스웜 Docs
https://docs.docker.com/engine/swarm/
The Internal structure of Docker Swarm v1
Claude 3.7 분석 결과
도커 스웜을 Production 환경에 적용한 Case
Portainer
 |
 |
 |
 |
 |
 |
 |
 |
3.2 스웜 클래식과 도커 스웜모드
Classic Swarm
https://github.com/docker-archive/classicswarm
Docker Swarm "Classic" 독립형: 이 프로젝트를 말합니다. Docker를 위한 네이티브 클러스터링 시스템으로, API 프록시 시스템을 사용하여 여러 Docker 호스트 풀을 단일 가상 호스트로 전환합니다. Docker Swarm 개요를 참조하세요. 2014년에 시작된 Docker의 첫 번째 컨테이너 오케스트레이션 프로젝트였습니다.
Swarmkit: Docker Engine 1.12 이상에서 제공하는 클러스터 관리 및 오케스트레이션 기능입니다. Swarmkit이 활성화되면 이를 "swarm mode에서 실행 중인 Docker Engine"이라고 부릅니다. 기능 목록은 Swarm 모드 개요를 참조하세요. 이 프로젝트는 마이크로서비스 아키텍처에 중점을 두고 있습니다. 서비스 조정(reconciliation), 로드 밸런싱, 서비스 디스커버리, 내장된 인증서 순환(certificate rotation) 등을 지원합니다.
Swarm mode
https://docs.docker.com/engine/swarm/
https://severalnines.com/blog/introduction-docker-swarm-mode-and-multi-host-networking/
도커 스웜이 쿠버네티스에 밀린 기술적 원인 분석
1. 아키텍처 설계 차이
구분 도커 스웜 쿠버네티스
| 설계 철학 | 단순성과 통합성 중심 | 확장성과 강력한 선언적 모델 중심 |
| 아키텍처 복잡성 | 단순하고 경량화된 구조 | 다중 컴포넌트 기반의 복잡한 분산 시스템 |
| 내부 구성요소 | Manager, Worker 노드 구조 | Control Plane(API Server, Scheduler, Controller Manager, etcd 등)과 Worker 노드 구조 |
핵심 차이점
도커 스웜은 Docker Engine에 내장된 형태로 기존 Docker 사용자에게 친숙한 환경을 제공했지만, 쿠버네티스는 처음부터 Google의 Borg 시스템 경험을 바탕으로 엔터프라이즈급 대규모 분산 시스템 관리를 위해 설계되었습니다. 쿠버네티스의 분리된 컴포넌트 기반 아키텍처는 더 높은 확장성과 유연성을 제공합니다.
2. 리소스 추상화 및 관리 기능
구분 도커 스웜 쿠버네티스
| 기본 배포 단위 | Service (Task) | Pod, Deployment, StatefulSet, DaemonSet 등 다양한 워크로드 타입 |
| 상태 관리 | 제한적 상태 관리 | StatefulSet을 통한 강력한 상태 애플리케이션 지원 |
| 자원 제약 설정 | 기본적인 CPU/메모리 제한 | ResourceQuota, LimitRange 등 세밀한 자원 관리 |
| 자동 확장 | 수동 스케일링 중심 | HPA, VPA, Cluster Autoscaler 등 다양한 자동 확장 메커니즘 |
| 사용자 정의 확장 | 제한적 확장성 | CRD(Custom Resource Definition)와 Operator 패턴을 통한 무한 확장 |
핵심 차이점
쿠버네티스는 더 다양하고 세밀한 리소스 추상화를 제공하여 복잡한 배포 시나리오를 효과적으로 관리할 수 있습니다. 특히 StatefulSet과 같은 고급 워크로드 타입과 CRD를 통한 확장성은 쿠버네티스의 큰 기술적 우위점입니다.
3. 스케줄링 메커니즘
구분 도커 스웜 쿠버네티스
| 스케줄링 알고리즘 | 단순한 분산 알고리즘 (spread, binpack, random) | 복잡한 다단계 스케줄링(filtering, scoring) 알고리즘 |
| 노드 선택 | 제한적인 제약조건 | Node Selector, NodeAffinity, Pod Affinity/Anti-Affinity |
| 리소스 인식 | 기본적인 리소스 인식 | 세밀한 리소스 요청 및 제한 기반 스케줄링 |
| 테인트/톨러레이션 | 미지원 | 지원 (특정 노드 회피 또는 강제 배치) |
핵심 차이점
쿠버네티스의 스케줄러는 훨씬 더 정교하며, 다양한 제약조건과 선호도를 고려한 복잡한 배치 결정을 내릴 수 있습니다. 이는 특히 이종 노드로 구성된 대규모 클러스터에서 큰 이점을 제공합니다.
4. 네트워킹 모델
구분 도커 스웜 쿠버네티스
| 네트워크 모델 | 내장 오버레이 네트워크 | CNI(Container Network Interface) 플러그인 기반 |
| 네트워크 정책 | 기본적인 네트워크 격리 | 세밀한 네트워크 정책 지원 (NetworkPolicy) |
| 서비스 디스커버리 | DNS 기반 서비스 디스커버리 | Service, Endpoint, CoreDNS 기반 다양한 서비스 디스커버리 |
| 로드 밸런싱 | 내장 L4 로드밸런싱 | 다양한 서비스 타입(ClusterIP, NodePort, LoadBalancer) 및 Ingress 지원 |
핵심 차이점
쿠버네티스는 CNI를 통해 Calico, Cilium, Flannel 등 다양한 네트워킹 솔루션을 선택할 수 있는 유연성을 제공하며, 네트워크 정책을 통해 마이크로서비스 간 통신을 세밀하게 제어할 수 있습니다. 또한 Ingress 리소스를 통한 L7 라우팅은 쿠버네티스의 큰 장점입니다.
5. 보안 기능
구분 도커 스웜 쿠버네티스
| 인증/인가 | 기본 TLS 기반 인증 | RBAC, OIDC, 서비스 계정 등 다양한 인증/인가 메커니즘 |
| 시크릿 관리 | Docker Secret (기본 기능) | Secret 리소스 및 외부 시스템(Vault 등)과 통합 |
| 보안 컨텍스트 | 제한적 보안 설정 | PodSecurityContext, SecurityContext, PodSecurityStandards |
| 감사 | 제한적 감사 로깅 | 상세한 감사 로깅 및 정책 |
핵심 차이점
쿠버네티스는 대규모 다중 테넌트 환경을 고려한 엔터프라이즈급 보안 기능을 제공합니다. 특히 RBAC를 통한 세밀한 권한 제어는 대규모 조직에서 중요한 요소입니다.
6. 생태계 및 확장성
구분 도커 스웜 쿠버네티스
| 생태계 크기 | 제한적 생태계 | CNCF 산하 거대 생태계 |
| 도구 통합 | 주로 Docker 도구와 통합 | 수백 개의 도구와 통합 (Prometheus, Istio, Helm 등) |
| 확장 메커니즘 | 제한적 플러그인 시스템 | CRD, Admission Controller, Aggregated API 등 다양한 확장점 |
| 커뮤니티 활동 | 감소 추세 | 매우 활발한 개발 및 커뮤니티 |
핵심 차이점
쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 대표 프로젝트로서 매우 활발한 생태계를 구축했습니다. Helm 차트, Operator, 서비스 메시(Istio), 모니터링(Prometheus) 등 수많은 보완 프로젝트는 쿠버네티스의 가치를 크게 높였습니다.
7. 클라우드 네이티브 환경 적합성
구분 도커 스웜 쿠버네티스
| 클라우드 통합 | 제한적 클라우드 통합 | 주요 클라우드 제공업체의 관리형 서비스(EKS, AKS, GKE) |
| 멀티/하이브리드 클라우드 | 제한적 지원 | 강력한 멀티클라우드, 하이브리드 클라우드 지원 |
| 인프라 추상화 | 기본적 추상화 | 강력한 클라우드 리소스 추상화 (CSI, CCM 등) |
핵심 차이점
쿠버네티스는 클라우드 제공업체의 서비스와 긴밀하게 통합되어 있으며, CSI(Container Storage Interface), Cloud Controller Manager 등을 통해 다양한 인프라를 일관되게 추상화합니다. 이는 멀티클라우드 환경에서 큰 이점을 제공합니다.
8. 기술적 결론: 도커 스웜이 쿠버네티스에 밀린 핵심 이유
- 아키텍처 설계 한계:
- 도커 스웜의 단순함은 장점이자 한계였습니다. 처음부터 대규모 분산 시스템을 위해 설계된 쿠버네티스와 달리, 확장 가능한 아키텍처로 설계되지 않았습니다.
- 기능적 격차:
- 쿠버네티스는 상태 관리, 자동 확장, 고급 스케줄링 등에서 도커 스웜보다 훨씬 풍부한 기능을 제공했습니다.
- 특히 StatefulSet, CRD와 같은 고급 기능은 복잡한 애플리케이션 배포에 중요한 차별점이었습니다.
- 생태계 역학:
- CNCF의 지원을 받는 쿠버네티스는 Google, Red Hat, Microsoft 등 주요 기업들의 투자를 받아 압도적인 생태계를 구축했습니다.
- Docker Inc.가 자체적으로 쿠버네티스를 지원하기 시작하면서 스웜에 대한 투자가 감소했습니다.
- 산업 표준화:
- 기업들이 쿠버네티스를 표준으로 채택하면서 자연스럽게 기술 인력, 도구, 지원이 쿠버네티스 중심으로 재편되었습니다.
- 이로 인해 자기강화 선순환이 발생하여 쿠버네티스의 우위가 더욱 공고해졌습니다.
- 엔터프라이즈 요구사항 충족:
- 쿠버네티스는 대기업의 복잡한 요구사항(RBAC, 감사, 다양한 환경 지원 등)을 더 잘 충족했습니다.
- 특히 멀티클라우드, 하이브리드 클라우드 환경에서의 일관성은 큰 경쟁 우위였습니다.
결론
도커 스웜은 단순성과 사용 편의성 측면에서 여전히 가치가 있지만, 엔터프라이즈급 컨테이너 오케스트레이션 플랫폼으로서는 쿠버네티스의 풍부한 기능, 확장성, 생태계를 따라잡지 못했습니다. 특히 클라우드 네이티브 환경으로의 산업 전환과 CNCF를 중심으로 한 강력한 생태계 구축은 쿠버네티스가 사실상의 표준(de facto standard)으로 자리잡게 한 결정적 요인이었습니다.
