2016년에는 어떤 컨테이너 오케스트레이션 (Container Orchestration) 플랫폼이 승리할지 명확하지 않았습니다. Docker Swarm은 Docker CLI에 직접 내장되어 있다는 장점이 있었습니다. 이미 Docker를 실행 중이라면, Swarm 모드는 명령어 하나로 실행할 수 있었습니다. 그에 비해 Kubernetes는 설정이 더 복잡하고 학습 곡선 (Learning Curve)이 가팔랐으며, 대부분의 개발자가 매일 사용하는 도구가 아닌 Google의 내부 인프라에서 나온 것이었습니다.

5년이 지난 지금, 그 질문은 더 이상 질문이 아닙니다. Kubernetes는 "프로덕션 환경에서 컨테이너를 어떻게 실행할 것인가"에 대한 기본 답변이 되었고, Docker Swarm은 각주로 남게 되었습니다. 여전히 기능하며 유지보수되고는 있지만, 더 이상 업계의 관심이나 투자가 집중되는 곳은 아닙니다.

단순함이 패배했습니다. 그 이유는 다음과 같습니다.

1. Kubernetes는 생태계 (Ecosystem)를 구축했고, Swarm은 기능 (Feature)을 구축했습니다

Docker Swarm은 최소한의 설정으로 컨테이너를 오케스트레이션 (Orchestrate)하는 한 가지 일을 잘하도록 설계되었습니다. 그 집중력이 곧 한계가 되었습니다. Swarm은 고정된 기능 세트와 함께 출시되었으며, 이를 확장한다는 것은 Docker 자체의 로드맵과 릴리스 사이클 내에서 작업해야 함을 의미했습니다.

Kubernetes는 처음부터 다른 접근 방식을 취했습니다. 작고 안정적인 코어 (API server, scheduler, controller manager)를 중심으로 확장 모델 — Custom Resource Definitions (CRD), Operator 패턴, admission controllers — 을 배치하여, Kubernetes 자체가 기능을 추가하기를 기다리지 않고도 누구나 그 위에 무언가를 구축할 수 있게 했습니다. 이러한 결정 덕분에 Helm, Istio, Prometheus, cert-manager 및 수백 개의 다른 도구들이 Kubernetes 내부에 구축될 필요 없이 Kubernetes를 중심으로 성장할 수 있었습니다.

이것이 중요했던 이유: 기업들이 2018~2019년경 오케스트레이션 플랫폼을 평가할 시점에, 한 플랫폼은 로깅 (logging), 서비스 메시 (service mesh), 비밀 관리 (secrets management), 그리고 CI/CD 통합을 위한 성숙한 도구 생태계를 갖추고 있었던 반면, 다른 플랫폼은 사용자가 그 대부분을 직접 구축하기를 기대했습니다.

2. Kubernetes는 중립 지대가 되었고, Swarm은 Docker 제품으로 남았다

Docker Swarm의 운명은 Docker Inc.의 운명과 결부되어 있었습니다. 2019년 Docker 기업이 경영난에 봉착하여 엔터프라이즈 부문을 매각했을 때, Swarm의 미래 또한 불확실해졌습니다. 이는 기술이 작동을 멈췄기 때문이 아니라, 누가 이를 이끌고 있는지 아무도 확신할 수 없었기 때문입니다.
Kubernetes는 설계 단계부터 이미 그 문제를 피했습니다. Google은 2015년에 Kubernetes를 새로 설립된 Cloud Native Computing Foundation (CNCF)에 기부하였고, 이를 단일 기업의 제품 로드맵이 아닌 재단에 의해 관리되는 벤더 중립적 (vendor-neutral) 인프라로 탈바꿈시켰습니다. 이는 기업들에게 엄청나게 중요한 요소였습니다. AWS, Microsoft, Google 모두 동일한 오픈 표준 위에서 경쟁적인 관리형 Kubernetes 서비스 (EKS, AKS, GKE)를 구축할 수 있었고, 고객의 워크로드 (workloads)는 이 세 곳 모두에서 이식성 (portable)을 유지할 수 있었습니다.
이것이 중요했던 이유: 기업들은 인프라를 단일 벤더의 지속적인 존속 여부에 거는 것을 좋아하지 않습니다. Kubernetes는 어떤 단일 기업도 빼앗아가거나 중단할 수 없는 기술을 그들에게 제공했습니다.

3. Kubernetes는 자가 치유 (Self-Healing)와 스케일링 (Scaling)을 한 단계 더 발전시켰다

두 플랫폼 모두 실패한 컨테이너를 재시작하고 서비스의 규모를 확장(Scale up)하거나 축소(Scale down)할 수 있었습니다. 하지만 Kubernetes는 전체 아키텍처를 조절 루프 (Reconciliation loop)를 중심으로 구축했습니다. 즉, 사용자가 시스템의 원하는 상태 (Desired state)를 선언하면, 컨트롤러 (Controllers)가 포드 (Pod)를 재스케줄링하거나, 노드 (Node)를 교체하거나, 부하에 따라 복제본 수 (Replica counts)를 조정하는 등의 작업을 통해 실제 상태가 해당 선언과 일치하도록 지속적으로 작동합니다.
Swarm의 모델은 더 단순하고 명령형 (Imperative)이었습니다.

(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fig3bj13c4fzwp9507x2b.png)
Docker Swarm은 엔지니어링 예산이 한정적이었고, 한동안 자체 생존에 대한 실질적인 의문이 제기되기도 했던 기업인 Docker Inc.에 의해 주로 유지 관리되었습니다. 반면 Kubernetes는 Google의 초기 엔지니어링 투자를 받았으며, CNCF로 이동한 이후에는 Red Hat, Microsoft, AWS, IBM, 그리고 급격히 성장하는 독립 기여자(Independent Contributors)들의 기여를 받았습니다. 이들은 모두 플랫폼의 성공에 직접적인 이해관계가 있는 이들이었습니다.
이러한 규모의 차이는 모든 곳에서 나타났습니다: 릴리스 주기(Release cadence), 문서의 품질, 보안 대응 시간, 그리고 새벽 2시에 Stack Overflow 질문에 답해줄 수 있는 인력의 수까지 말입니다. 기술적 장점이 무엇이든 간에, 산업 전체가 유지 관리하는 기술은 고군분투하는 단일 기업이 유지 관리하는 기술보다 앞서 나가기 마련입니다.
이것이 중요했던 이유: 수년간의 인프라 투자를 평가하는 기업들은 기술이 오늘날 어떻게 작동하는가뿐만 아니라, 그 기술의 배후에 누가 있는지를 살펴봅니다. 그리고 Kubernetes는 "만약 이 회사가 사라지면 어떻게 되는가?"라는 질문에 대해 산업 전체가 내놓은 해답을 가지고 있었습니다.

5. Kubernetes는 엔터프라이즈 워크로드(Workload) 유형의 전체 범위를 지원했습니다

Swarm은 주로 하나의 워크로드 형태, 즉 자유롭게 재시작 및 로드 밸런싱이 가능한 무상태(stateless) 서비스를 중심으로 구축되었습니다. 이는 많은 실제 사용 사례를 포괄했지만, 엔터프라이즈 환경에서는 노드(node) 전체에서 실행되어야 하는 데이터베이스, 메시지 큐, 배치 작업(batch jobs), 데몬 프로세스(daemon processes) 등 매우 다른 요구사항을 가진 워크로드도 운영됩니다. 이들은 식별자(identity), 스토리지(storage), 스케줄링(scheduling) 측면에서 각기 다릅니다.

Kubernetes는 이러한 각각의 유형에 대한 네이티브 프리미티브를 제공했습니다: 무상태 서비스를 위한 Deployments, 안정적인 식별자와 스토리지가 필요한 워크로드를 위한 StatefulSets, 노드당 프로세스를 위한 DaemonSets, 배치 및 예약 작업을 위한 Jobs와 CronJobs입니다. 이 폭넓은 범위 덕분에 기업들은 '단순한 무상태 서비스' 형태에 맞지 않는 워크로드들을 위해 별도의 오케스트레이션 플랫폼을 필요로 하지 않았습니다. 실제로 중요하고 핵심적인 프로덕션 워크로드들이 바로 여기에 속해 있습니다.

이것이 왜 중요했는가: 기업들은 한 종류의 워크로드만 운영하지 않습니다. 모든 유형의 워크로드를 네이티브하게 처리할 수 있는 플랫폼은, 대부분을 잘 처리하지만 나머지를 위해 우회책(workarounds)이 필요한 플랫폼보다 훨씬 단순한 엔터프라이즈 아키텍처를 제공했습니다.

근본적인 패턴 (The Underlying Pattern)
Kubernetes의 장점 중 그 어떤 것도 사용하기가 더 쉽다는 점에 있었던 것은 아닙니다. 거의 모든 면에서, 특히 초기 몇 년 동안은 그렇지 않았습니다. Kubernetes가 승리한 이유는 확장 가능하도록 구축되었고, 단일 기업 이상의 통제를 받으며, 일회성 명령(one-time commands)보다는 지속적인 조정(continuous reconciliation)을 중심으로 설계되었으며, 산업 전체의 엔지니어링 노력을 지원받고, 실제 기업이 보유한 전체 범위의 워크로드(workloads)를 실행할 수 있는 능력을 갖추었기 때문입니다.
Docker Swarm은 첫날의 경험(day-one experience)에 최적화되었습니다. 반면 Kubernetes는 50명의 엔지니어, 6개의 팀, 그리고 프로젝트 시작 당시에는 아무도 예상하지 못했던 워크로드를 가진 상태로 3년이 지난 프로덕션 시스템(production system)의 모습에 최적화되었습니다. 엔터프라이즈 인프라에서는 바로 그러한 베팅이 승리하는 경향이 있습니다.

저자 소개
저는 기업과 전문가들이 기술을 탐색하고 실제 IT 과제를 해결할 수 있도록 돕는 데 집중하는 IT 컨설턴트, Alex Susanu입니다.
🌐 제 작업에 대해 더 알아보기: https://alexsusanu.com/