引言容器编排本质上是将多个容器作为一个整体进行部署、扩缩、更新和监控的技术集合。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_URLmysql://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/21达成一致才能提交状态变更最多可承受(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模块。每个服务被分配一个虚拟IPVIP作为统一入口隐藏后端容器的实际分布。无论请求落到集群中哪个节点都能被正确路由到后端容器。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 定位与架构KubernetesK8s是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 自动扩缩容HPAHorizontal 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共识主从式etcdRaft节点类型单节点Manager/WorkerMaster/Node调度范围单机跨节点集群跨节点集群服务发现无内置DNSVIPCoreDNSService负载均衡无Ingress路由网格IPVSkube-proxy滚动更新无原生支持原生支持Deployment自动扩缩无手动docker service scaleHPA自动学习曲线极低低高4.2 性能与规模Compose无集群能力适合单机Swarm100节点内性能优于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依然是最务实的选择。