编者按： Kubernetes 主导了容器编排的讨论，但大多数小团队并不需要它。Michael Sun 评估了三种实用的替代方案，并提供了明确的选择标准，基于您的实际限制而非行业炒作。
Kubernetes 不是您的问题
每隔几个月，一家5人创业公司的开发者就会告诉我他们正在”迁移到 Kubernetes”。当我问为什么时，答案通常是”我们需要扩展”或”这是行业标准”的某种变体。当我问他们当前的流量时，几乎总是每天不到10,000个请求。
Kubernetes 是非凡的基础设施。它在真实的规模上解决了真实的问题。但是运行一个 K8s 集群——即使在 EKS 或 GKE 上的托管集群——也会引入大多数小团队无法承担的操作复杂性。您不是 Google。您可能没有专门的平台工程团队。而您的高级开发者花在调试 Helm 图表上的时间，是他们没有在构建您产品的时间。
好消息是：有一些出色的替代方案，它们能以一小部分操作负担为您提供所需的大部分功能。
Docker Compose：被低估的生产工具
Docker Compose 在生产环境中名声不佳，其中一些是应得的。但对于许多小团队来说，它是正确的答案——我这样说毫不尴尬。
Compose 的优势
Compose 通过一个 YAML 文件为您提供声明式的多容器部署，任何开发者都能在五分钟内阅读和理解。您通过 DNS 获得服务发现、卷管理、网络隔离和健康检查。对于一个典型的 Web 应用程序——API 服务器、数据库、缓存、后台工作器——一个 Compose 文件只需要 40-60 行配置。
部署过程很简单：推送您的代码，SSH 到服务器，运行 docker compose pull && docker compose up -d。添加一个小型 shell 脚本或 GitHub Actions 工作流，您就拥有了一个 CI/CD 管道。它是否复杂？不。它是否能为服务数千用户的团队可靠地工作？绝对可以。
Compose 的不足
Compose 在单个主机上运行。这是其根本限制。如果该主机宕机，您的应用程序也会宕机。您可以通过良好的备份策略和快速恢复程序来缓解这种情况，但仅凭 Compose 无法获得真正的高可用性。
扩展也是手动的。您可以运行 docker compose up --scale api=3，但您需要一个反向代理在前面进行负载均衡，并且仍然受限于单台机器的资源。当您的应用程序真正需要跨越多个主机时，Compose 就不再足够了。
最适合
1-5名开发人员组成的团队，运行具有简单扩展需求的应用程序。内部工具、内容网站、早期阶段的SaaS产品、流量可预测的API服务。如果您的基础设施可以放在一个配置良好的VPS上，那么Compose可能就是您所需要的全部。
Docker Swarm：被遗忘的中间地带
Docker Swarm是那个没人再谈论的选项，这很不幸，因为它在Compose和Kubernetes之间占据了一个真正有用的位置。
Swarm提供的功能
Swarm是Docker原生的集群管理工具。如果您已经了解Docker和Compose，那么您已经知道了Swarm约80%的内容。您使用docker swarm init初始化Swarm集群，添加更多节点，并使用与Compose文件几乎相同的堆栈文件来部署服务。您通过路由网格获得内置的负载均衡、服务发现、滚动更新，以及在节点故障时自动重新调度。
相比Compose的主要优势是支持多主机且增加了最小的额外复杂性。一个三节点的Swarm集群能提供真正的高可用性。如果一个节点宕机，您的服务会自动重新分配到剩余节点上。您无需学习Docker已经教给您的任何新概念就能获得这些功能。
房间里的大象
Docker Swarm处于维护模式。Docker公司多年来没有在Swarm开发上进行重大投资。功能集已冻结。不会有新功能、新集成或重大改进。这并不意味着它已经坏了——对于它所做的事情来说它运行良好——但这意味着您正在构建一个没有未来增长的平台。
对于某些团队来说，这是可以接受的。Swarm做它能做的事情，它是稳定的，您的编排需求可能不会超出其能力范围。对于其他团队来说，生态系统的缺乏投资是一个交易破坏因素。
最适合的场景
需要多主机部署和高可用性但希望留在Docker生态系统的团队。适合需要2-5个主机和简单扩展的应用程序。如果您预计需要高级调度、自定义资源类型或大量第三方集成，则不太理想。
HashiCorp Nomad：严肃的替代选择
Nomad是我最常推荐给已经超出Compose能力范围但不想承担Kubernetes重量的小型团队的选项。它是一个真正的编排平台，从一开始就被设计得比Kubernetes更简单，同时又有足够强大的能力来处理生产工作负载。
Nomad为何脱颖而出
Nomad是一个单一的二进制文件。您下载它，编写一个配置文件，然后启动它。没有相当于Kubernetes中需要理解的数十个组件——没有etcd，没有kube-apiserver，没有kube-scheduler，没有kube-controller-manager。操作表面积显著减小。
尽管如此简单，Nomad 仍能处理多区域部署、滚动更新、金丝雀部署、通过 Consul 进行服务网格集成，以及通过 Vault 进行密钥管理。它可以运行 Docker 容器，也可以运行原始二进制文件、Java 应用程序，甚至是 Windows 服务。其调度模型灵活，作业规范语言易于阅读。
权衡取舍
Nomad 的社区和生态系统比 Kubernetes 小。你会发现更少的博客文章、更少的 Stack Overflow 答案和更少的第三方工具。学习资源不错，但不如 Kubernetes 丰富。如果你需要特定的集成——比如特定数据库的自定义操作器——它可能存在于 Kubernetes 中，但可能不存在于 Nomad 中。
HashiCorp 生态系统也鼓励你采用 Consul 进行服务发现和 Vault 进行密钥管理。这些都是优秀的工具，但它们增加了运营复杂性。你可以不使用它们来运行 Nomad，但会失去平台一些最吸引人的功能。
最适合场景
3-15 名开发者的团队，运行需要真正编排但希望保持运营可管理的多服务架构。对于已经使用其他 HashiCorp 工具的组织来说是绝佳选择。当你需要编排容器化和非容器化混合工作负载时，这是一个强有力的选择。
做出决定
以下是我向团队提供建议时使用的决策框架：
如果以下情况，从 Compose 开始：你的应用程序可以放在一台服务器上，你的团队规模小，且你的扩展需求是可预测的。不要添加不必要的复杂性。一个配置良好的 Docker Compose 服务器可以处理比大多数人想象中更多的流量。
如果以下情况，考虑 Swarm：你需要跨多个主机实现高可用性，但你的编排需求很简单。请注意，你选择的是一个稳定但停滞的平台。
如果以下情况，选择 Nomad：你需要真正的编排功能——多区域、金丝雀部署、混合工作负载——但希望保持运营负担合理。对于小团队来说，这是 Kubernetes 最好的”成熟”替代方案。
如果以下情况，实际使用 Kubernetes：你有专门的平台团队（或预算用于托管 K8s），你需要操作器和集成生态系统，或者你正在构建一个运营投入能够获得回报的规模。当 Kubernetes 是正确的工具时，使用它没有任何不妥。
关于托管服务的一点说明
我没有讨论的一个选择是完全跳过编排问题，而是使用 Railway、Render 或 Fly.io 等托管平台。对于许多小团队来说，这确实是正确的答案。你牺牲了一些控制和成本效率，以换取零运营负担。如果你的应用程序是标准的 Web 服务，并且预算允许，托管平台可能比任何自托管编排工具更适合你。
关键要点
- 在生产环境中使用 Docker Compose 是一个合理的选择，适用于单主机部署的小型团队。不要让行业压力推动你走向不必要的复杂性。
- Docker Swarm 提供多主机编排功能，学习曲线平缓，但其开发停滞意味着未来增长有限。
- Nomad 是最强的 K8s 替代方案，适合需要真正编排功能而不想承担运维重量的团队。其单二进制文件的简单性是一个真正的优势。
- 正确的工具取决于你的实际约束条件——团队规模、流量、可用性要求和运维能力——而不是行业所谓的”标准”。
- 托管平台值得考虑，作为许多小型团队用例的自托管编排的可行替代方案。