docker swarm 是 docker 引擎内置的轻量编排工具，自1.12起集成，仅维护稳定性；kubernetes 已脱离 docker，通过 cri 对接 containerd 等运行时，成为独立云原生操作系统底座。
Docker Swarm 模式和 Kubernetes 在 Docker 版本演进中已走向明确分工：Swarm 是 Docker 引擎内置的轻量编排能力，而 Kubernetes 已完全脱离 Docker 生态，成为独立、通用的容器调度平台。
Swarm 模式始终是 Docker 的原生扩展
自 Docker 1.12（2016年）起，Swarm Mode 就作为 Docker Engine 的一部分直接集成，无需额外安装。后续版本（如 17.06、20.10、24.x）持续优化其服务发现、滚动更新和安全传输（TLS 自动签发），但始终维持“单命令启集群”“Docker CLI 直接管理”的设计哲学。它不追求功能完备性，而是强化与 docker run、docker service、docker stack 等命令的无缝协同——本质上，它是 Docker 工具链向多主机场景的自然延伸。
- 所有操作基于 docker 命令，例如
docker swarm init、docker service create - 不引入新 API 或客户端，复用已有 Docker daemon 和 CLI
- 配置文件（docker-compose.yml）可直接用于
docker stack deploy，兼容性高
Kubernetes 早已不再依赖 Docker 运行时
从 Docker 18.09 开始，Kubernetes 官方明确弃用 dockershim；到 Kubernetes v1.24（2022年），dockershim 被彻底移除。这意味着 Kubernetes 不再把 Docker 当作默认或首选运行时——它通过 CRI（Container Runtime Interface）对接 containerd、CRI-O 等符合标准的运行时。Docker 公司自身也在 2020 年后将重心转向桌面开发体验（Docker Desktop）和云服务（Docker Hub、Docker Scout），而非维护 Swarm 与 K8s 的竞争关系。
- Kubernetes 的部署、升级、扩缩容、网络策略等全部通过 kubectl 和 YAML 清单驱动
- Docker Desktop 内置的 Kubernetes 是为本地开发提供便利，并非 Docker 官方对生产级 K8s 的背书
- 生产环境中，K8s 集群通常由托管服务（EKS/AKS/GKE）或发行版（Rancher、OpenShift）交付，与 Docker 版本无关
定位差异在版本迭代中愈发清晰
Docker 的版本更新节奏（如 24.0 → 25.x）主要围绕镜像构建加速（BuildKit）、安全扫描（Trivy 集成）、开发者工作流（Dev Environments）展开，Swarm Mode 仅做稳定性维护，不再新增核心特性。反观 Kubernetes，其每季度大版本（v1.29 → v1.30）持续强化声明式控制、可观测性集成、边缘调度（KubeEdge）、AI 工作负载支持等，目标是成为云原生操作系统底座——它不关心你用不用 Docker 构建镜像，只关心镜像是否符合 OCI 标准、能否被 runtime 正确拉取运行。
- Swarm：适合用 Docker 快速搭起三节点测试环境、CI/CD 流水线中的临时服务、嵌入式或边缘小集群
- Kubernetes：面向需要多租户、细粒度权限、自动弹性、跨云一致性的中大型生产系统
- 二者不是“同一赛道的两个选手”，而是解决不同层次问题的工具：一个是容器工具链的横向延展，一个是基础设施抽象层的纵向深化
