Kubernetes vs Docker Swarm：容器编排怎么选？

对比

维度	Kubernetes	Docker Swarm
学习曲线	陡峭，概念多（Pod/Service/Ingress/ConfigMap 等），需要专门学习	平缓，Docker 用户可以快速上手，命令与 Docker CLI 一致
功能丰富度	极其丰富：自动扩缩容、滚动更新、服务网格、RBAC、CRD 扩展等	基础功能完善：服务发现、负载均衡、滚动更新，高级功能有限
扩展性	高度可扩展，支持数千节点，CRD/Operator 机制可自定义资源	适合中小规模，大规模集群管理能力有限
社区生态	庞大的生态系统，CNCF 项目，几乎所有云厂商支持	社区较小，Docker 公司维护，第三方工具较少
高可用	内置多 Master 高可用，etcd 集群，自动故障转移	支持多 Manager 节点，但故障恢复机制相对简单
部署复杂度	部署复杂，组件多（etcd/apiserver/scheduler/controller），建议用托管服务	Docker 内置，docker swarm init 一条命令初始化
网络模型	CNI 插件体系，可选 Calico/Flannel/Cilium 等，功能强大但配置复杂	内置 overlay 网络，开箱即用，配置简单
存储管理	CSI 标准，支持各种存储后端，PV/PVC 声明式管理	Docker Volume 驱动，功能相对基础

使用场景

什么时候用 Kubernetes

企业级生产环境，需要高可用和自动扩缩容
微服务架构，服务数量多且需要精细化管理
需要多云/混合云部署能力
团队有专职运维或使用云厂商托管 K8s（EKS/AKS/GKE）
需要丰富的生态工具（Helm/Istio/ArgoCD 等）

什么时候用 Docker Swarm

小团队快速起步，没有专职 K8s 运维
应用规模较小（几十个容器以内）
已有 Docker Compose 编排，想快速迁移到集群
开发测试环境，追求简单快速
不需要复杂的自动扩缩容和服务网格

示例

mergeExample

# Kubernetes 部署应用
kubectl create deployment web --image=nginx:1.25 --replicas=3
kubectl expose deployment web --port=80 --type=LoadBalancer
kubectl autoscale deployment web --min=3 --max=10 --cpu-percent=80

rebaseExample

# Docker Swarm 部署应用
docker swarm init
docker service create --name web --replicas 3 -p 80:80 nginx:1.25
docker service scale web=5

常见错误

小项目盲目上 K8s，运维成本远超收益

不用托管服务自建 K8s 集群，低估了运维复杂度

Swarm 项目规模增长后才发现功能不够，迁移成本高

忽视团队学习成本，K8s 需要持续投入学习

没有考虑云厂商锁定问题

建议

2024 年及以后，Kubernetes 已成为容器编排的事实标准。如果团队有能力或使用云厂商托管服务（EKS/AKS/GKE），优先选择 K8s。如果是小团队、小项目、快速验证阶段，Docker Swarm 或 Docker Compose 足够用，后续再考虑迁移到 K8s。