Docker容器编排三驾马车：Compose、Swarm与Kubernetes深度剖析

引言

容器编排，本质上是将多个容器作为一个整体进行部署、扩缩、更新和监控的技术集合。Docker生态中，从单机到集群、从简单到复杂，形成了三个层次分明的编排工具：Docker Compose（单机多容器编排）、Docker Swarm（集群原生编排）和Kubernetes（大规模生产级编排）。三者并非简单的版本迭代关系，而是对应不同规模、不同复杂度的应用场景——理解它们的架构差异与设计哲学，是做出正确技术选型的前提。

一、Docker Compose：单机编排的声明式模型

1.1 定位与核心概念

Compose是Docker官方推出的开源编排工具，前身是Fig项目。其核心定位是“定义和运行多容器Docker应用”，解决的是单机环境下多个容器相互配合完成任务的场景。

Compose有两个核心抽象：

  • 服务（Service）：一个应用的容器，可以包含若干运行相同镜像的容器实例

  • 项目（Project）：由一组关联服务组成的完整业务单元，在compose.yaml中定义

1.2 工作原理

Compose用Python编写，通过调用Docker Engine提供的API来管理容器。用户通过YAML配置文件（默认compose.yaml或compose.yml）声明所有服务的配置，然后通过docker compose up一条命令完成全部容器的创建与启动。

Compose文件支持多个文件的合并与覆盖，简单属性和映射按优先级覆盖，列表则通过追加合并。这种设计使环境配置可以在开发、测试、生产等不同场景间灵活切换。

1.3 声明式服务定义

以下是Compose文件的核心语法结构：

version: "3.9" services: web: image: nginx:1.25-alpine ports: ["80:80"] volumes: ["./html:/usr/share/nginx/html:ro"] depends_on: [api] deploy: resources: limits: {cpus: "0.5", memory: 256M} api: build: ./api environment: - DB_URL=mysql://root:${MYSQL_ROOT_PASSWORD}@db/demo healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s deploy: replicas: 2 update_config: {order: start-first} db: image: mysql:8.4 volumes: ["db-data:/var/lib/mysql"] environment: - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} volumes: db-data:

关键要点：

  • depends_on定义服务启动顺序

  • healthcheck定义健康检查探针

  • deploy.replicas支持本地模拟多实例

  • 通过.env文件管理敏感配置

  • profiles支持场景化启停

1.4 局限性

Compose的编排能力仅限于单台Docker宿主机。它不具备跨节点调度能力，没有内置的服务发现与负载均衡，也不支持滚动更新、自动扩缩容等生产级特性。因此，Compose的典型场景是本地开发、测试环境和小规模单机部署。

二、Docker Swarm：内置集群编排的轻量方案

2.1 定位与架构

Docker Swarm是Docker官方内置的跨节点容器编排工具。注意，当前版本的Docker Engine已原生包含Swarm模式（Swarm Mode），与早期独立维护的Docker Classic Swarm不同。

Swarm采用去中心化架构，集群节点分为两类：

  • Manager节点：包含调度器、路由、服务发现等功能，负责接收客户端请求并调度任务

  • Worker节点：接受Manager调度，执行容器的创建、扩容和销毁等具体操作

Manager节点通过Raft共识算法实现高可用。Raft要求多数节点（N/2+1）达成一致才能提交状态变更，最多可承受(N-1)/2次故障。在5个Manager的集群中，即使3个节点不可用，系统虽无法处理新调度请求，但现有任务仍保持运行。

Swarm采用主从式多管理节点HA：多个Manager中仅有一个处于活动状态（Leader），其余为备用节点。备用Manager接收到Swarm命令时会转发给Leader。

2.2 声明式服务模型

Swarm同样采用声明式服务模型——用户定义期望状态（如“运行10个Nginx副本”），Manager持续监控集群状态并协调实际状态与期望状态之间的差异。例如，若托管2个副本的Worker宕机，Manager会自动在可用节点上创建2个新副本。

服务部署支持两种模式：

  • 副本模式（Replicated）：指定副本数量，Manager调度到各节点

  • 全局模式（Global）：每个节点运行一个副本

2.3 服务发现与负载均衡

Swarm内置完整的服务发现与负载均衡机制：

服务发现：Manager为每个服务分配唯一的DNS名称，Swarm内置DNS服务器可查询集群中运行的每个容器。

负载均衡：Swarm通过Ingress路由网格实现跨节点请求分发，底层基于Linux内核的IPVS模块。每个服务被分配一个虚拟IP（VIP）作为统一入口，隐藏后端容器的实际分布。无论请求落到集群中哪个节点，都能被正确路由到后端容器。

2.4 滚动更新与回滚

Swarm支持零宕机滚动更新。更新时按设定批次逐步替换旧任务，新任务须通过健康检查后才继续后续更新。可通过deploy.update_config配置更新行为——如每次更新2个副本、等待10秒、失败自动回滚。更新失败时可自动或手动回退到前一版本。

2.5 安全与网络

Swarm默认启用TLS双向认证和加密，保护节点间通信安全。内置Overlay网络实现跨主机容器通信。

2.6 局限与现状

Swarm的优势是与Docker生态无缝集成、学习曲线低、部署轻量。性能方面，在100节点集群中容器启动延迟比K8s低23%，但大规模集群（>500节点）时调度吞吐量下降40%。

截至2025年，大多数大型组织已从Docker Swarm转向Kubernetes。Swarm自2019年起由Mirantis接手维护，社区活跃度趋稳。它仍适合中小规模生产环境、CI/CD流水线和快速原型开发。

三、Kubernetes：容器编排的事实标准

3.1 定位与架构

Kubernetes（K8s）是Google开源、现由CNCF维护的容器编排系统，已从简单调度系统演变为功能强大的云原生操作系统。

Kubernetes架构遵循“控制循环”理念——持续监控系统状态并与期望状态比对，自动执行调整。

控制平面（Control Plane）：

组件功能
API Server唯一与etcd交互的组件，提供RESTful接口，负责认证、授权和验证
Controller Manager运行Deployment、ReplicaSet、Namespace等控制器，将当前状态调整为期望状态
Scheduler为新Pod选择最优节点，考虑资源需求、策略约束、亲和性等
etcd分布式键值存储，保存集群全部状态，使用Raft保证一致性

数据平面（Data Plane）：

组件功能
kubelet节点主代理，与API Server通信，管理Pod生命周期，执行健康检查
kube-proxy维护节点网络规则，实现Service抽象和负载均衡
容器运行时containerd或CRI-O，负责拉取镜像、运行容器

3.2 Pod：最小调度单元

Pod是Kubernetes的最小调度单元，包含一个或多个紧密耦合的容器，共享网络命名空间、存储卷和其他资源。每个Pod有唯一IP，容器间通过localhost直接通信。

Pod的设计解决了“辅助容器”场景——如Sidecar代理、日志收集器可与主容器同生命周期运行，共享网络和存储。

3.3 控制器模式

控制器是Kubernetes自动化管理的核心机制——通过API Server监视资源状态，检测到实际状态与期望状态不符时触发调和（Reconciliation）过程。

核心控制器：

控制器功能适用场景
ReplicaSet确保指定数量Pod副本运行无状态应用
Deployment管理ReplicaSet的声明式更新与回滚无状态应用的滚动更新
StatefulSet有序部署、稳定网络ID、持久存储数据库、消息队列等有状态中间件
DaemonSet所有（或部分）节点运行一个Pod副本日志收集、节点监控
Job/CronJob一次性或定时任务批处理、定时作业

3.4 服务发现与负载均衡

Kubernetes的服务发现基于Service和DNS两核心组件。

Service为Pod提供稳定的网络入口，通过标签选择器关联后端Pod，分配ClusterIP并创建DNS记录。Pod启动时向API Server注册IP和端口。

DNS解析由CoreDNS负责。Service创建后，CoreDNS自动生成DNS记录，格式为<service-name>.<namespace>.svc.cluster.local。集群内Pod通过服务名即可访问其他服务。

kube-proxy维护节点网络规则，将发往Service的流量负载均衡到后端Pod。支持iptables、IPVS等多种代理模式。

3.5 自动扩缩容

HPA（Horizontal Pod Autoscaler）周期性检查Pod的度量数据（CPU、内存或自定义指标），计算所需副本数并调整Deployment的replicas字段。HPA配合Metrics Server实现基于CPU/内存的弹性伸缩，配合Prometheus可实现自定义指标伸缩。

3.6 声明式API与自愈能力

Kubernetes通过声明式API实现编排——用户只需描述期望状态，系统自动收敛至目标状态。这与命令式系统（用户需指定每个操作步骤）形成鲜明对比。

声明式设计的核心价值在于自愈能力：节点故障时，控制器自动在健康节点重建Pod；容器崩溃时，kubelet自动重启；滚动更新失败时，自动回滚。

四、横向对比与选型指南

4.1 架构对比

维度Docker ComposeDocker SwarmKubernetes
架构模式单机，调用Docker API去中心化主从，Raft共识主从式，etcd+Raft
节点类型单节点Manager/WorkerMaster/Node
调度范围单机跨节点集群跨节点集群
服务发现无内置DNS+VIPCoreDNS+Service
负载均衡无Ingress路由网格（IPVS）kube-proxy
滚动更新无原生支持原生支持（Deployment）
自动扩缩无手动docker service scaleHPA自动
学习曲线极低低高

4.2 性能与规模

  • Compose：无集群能力，适合单机

  • Swarm：100节点内性能优于K8s（启动延迟低23%），500节点以上调度吞吐量下降40%

  • Kubernetes：经受过万级节点生产验证，是唯一的大规模集群方案

4.3 选型建议

场景驱动选型：

场景推荐工具理由
本地开发、单机测试Compose配置简单、启动快速
中小规模生产（<50实例）Swarm原生集成、零学习成本
大规模生产（>100实例）Kubernetes生态完善、功能全面
有状态服务（数据库等）KubernetesStatefulSet提供稳定标识与持久存储
混合云/多集群Kubernetes跨云原生支持

演进路径：项目初期可先用Compose（单机），服务增多后切到Swarm（多节点、故障自动恢复），规模再扩大时迁移至Kubernetes。三者并非互斥——实际生产中可构建“Kubernetes为主、Swarm为辅”的混合架构。

结语

Compose、Swarm与Kubernetes构成了容器编排从单机到集群、从简单到复杂的完整光谱。Compose解决的是“如何定义多容器应用”，Swarm解决的是“如何在集群中运行多容器应用”，Kubernetes解决的则是“如何在超大规模集群中自动化管理应用”。

理解三者的设计哲学与架构差异，不是为了在它们之间做非此即彼的选择，而是为了在正确的时间、正确的规模下，使用正确的工具。对于绝大多数生产级项目而言，Kubernetes已是事实标准；但对于开发环境和中小规模场景，Compose和Swarm依然是最务实的选择。