1. 단일 Docker 호스트의 한계와 오케스트레이터의 필요성
처음 홈랩을 구축할 때는 각 노드에 Docker Compose를 개별 실행하는 방식이 간편해 보입니다. 그러나 노드가 12대로 늘어나고 실행 컨테이너가 60개를 넘어서면 다음과 같은 치명적 운영 문제에 직면합니다:
- 컨테이너 장애 발생 시 수동 재시작 필요 (자가 치유 불가).
- 노드 증설 시 트래픽 인그레스 라우팅의 수동 설정 복잡성.
- 시크릿 및 환경변수의 분산 관리로 인한 보안 위험.
이에 따라 홈랩 환경에서 가장 현실적인 두 가지 오케스트레이션 대안인 Docker Swarm과 K3s(경량 Kubernetes)를 실전에 배치하고 철저히 비교 분석했습니다.
2. K3s vs Docker Swarm 심층 비교 분석
| 비교 항목 | Docker Swarm | K3s (경량 Kubernetes) |
|---|---|---|
| 마스터 노드 RAM 소비 | 약 120MB (초경량) | 약 800MB ~ 1.2GB |
| 설정 복잡도 | docker swarm init 1줄로 완료 | 매니페스트, CRD, Ingress 설정 필요 |
| 스토리지 연동 (CSI) | NFS/GlusterFS 볼륨 플러그인 의존 | Rook-Ceph, Longhorn 완벽 지원 |
| 생태계 & AI 확장성 | 기본적인 웹 서비스 위주 | KEDA(오토스케일), GPU 오퍼레이터 완벽 |
3. 최종 선택: 하이브리드 아키텍처 전략
단순한 흑백 논리 대신, 워크로드의 특성에 따라 다음과 같이 역할을 분담했습니다:
- K3s 클러스터 (6개 노드): Qdrant 벡터 DB, Ollama AI 추론 엔진, 멀티에이전트 코어 등 CSI 볼륨 연동과 자율 오토스케일링이 필수적인 고난도 워크로드 담당.
- Docker Swarm (6개 노드): Nginx 리버스 프록시, Redis 캐시, PWA 정적 호스팅 등 경량성과 초저지연이 중요한 엣지 워크로드 담당.
4. 무중단 롤링 업데이트 실측 검증
새로운 버전의 블로그 정적 컨테이너를 배포할 때 update-config: order: start-first를 지정하여, 신규 컨테이너가 100% 헬스체크를 통과한 후에만 구버전을 제거하도록 구성했습니다. wrk 벤치마크 툴로 초당 2,000건의 트래픽을 주입하며 배포를 진행한 결과, 0건의 연결 유실(0 Failures)로 완전한 무중단 서비스를 실증했습니다.