2022 年 Kubernetes 的 4 种可替代方案

虽然 10 个组织中有近 9 个使用 Kubernetes，但如果在 2022 年寻找容器编排器，还有其他选择可以考虑。

以任何客观的衡量标准，Kubernetes[1] 很久以前就征服了容器编排市场。据 Red Hat 称[2]，截至 2021 年，Kubernetes 承载了 88% 的容器化工作负载。

然而，尽管 Kubernetes 广受欢迎，但它并不是唯一需要考虑的容器编排器。存在 Kubernetes 的替代品。有些是相对较旧的编排器，它们设法在 2010 年代中期的“编排器大战”中幸存下来，并保留了少量用户。其他人则是新晋的编排器，他们争相在编排和云原生计算方面比 Kubernetes 做得更好。

这里有四个编排器，尽管市场份额要小得多，仍然是 Kubernetes 的可行替代品。

背景：Kubernetes 和 Orchestrator 大战

在深入了解 Kubernetes 替代品列表之前，让我们简要总结一下 Kubernetes 是如何变得如此受欢迎的。

如果你在五六年前列出一个容器编排器列表，它会很长，Kubernetes 不一定会排在首位。当时，容器编排器众多，没有一个与其他方案有明显的区别。

Docker：这几乎不是第一个容器平台[3]，但却是第一个流行起来的平台，它使基于容器的计算成为主流，于 2014[4]年开始开发一种编排工具 Swarm 。同年，最初作为谷歌内部项目的[5] Kubernetes 被公开和开源。

Mesosphere（现为 D2iQ）也在开发一个容器编排器，它于 2016 年开源[6]。

Rancher（后来转向基于 Kubernetes 的平台并被SUSE 收购[7]）和 Kontena（现已解散）等初创公司也在构建编排器。

甚至流媒体音乐业务 Spotify 也创建了一个编排平台[8]。

那么，在 2010 年代中期，似乎每个人都在猜测哪些协调者最终会在这个高度动态和快速发展的市场中占上风。我们中的许多人认为会有多个赢家。

但那并没有发生。到 2018 年左右，很明显 Kubernetes 基本上赢得了编排器之战，成为事实上的容器编排器。原因[9]超出了本文的范围，但足以说明，对于当今的许多开发人员和 IT 工程师来说，很难记住曾经有 Kubernetes 的可行替代方案。

Kubernetes 的现代替代品

不仅如此，许多开发人员和 IT 工程师甚至可能没有意识到 Kubernetes 的替代品仍然存在。为了证明他们确实做到了，我们来看看其他四个在 2022 年仍在积极开发中的容器编排器。

Docker Swarm

Kubernetes 最著名的替代品可能是 Docker Swarm。

如上所述，Swarm 起源于 2014 年，是 Docker 自己开发的编排工具。但 Docker 在容器生态系统中的作用慢慢减弱，到 2020 年左右，人们普遍认为Swarm 已经死了[10]。

但实际上，并非如此。Mirantis 自 2019 年收购 Docker Enterprise 以来，一直在支持 Docker Swarm[11]。目前尚不清楚它是否会继续这样做；最初，Mirantis 承诺至少提供两年的支持，而那是大约两年前的事了。

至少目前，Swarm 仍在发挥作用，并且是 Kubernetes 的可行替代方案。

Nomad

如果您喜欢 Docker Swarm 但不喜欢 Swarm 的不稳定状态，请仔细查看HashiCorp Nomad[12]。与 Swarm 一样，Nomad 于 2015 年推出，是当时为数不多的容器编排器之一，面对 Kubernetes 的优势没有停止。

Nomad 与 Swarm 的相似之处还在于它比 Kubernetes 更轻量级和更简单，这可能是许多工程师的主要卖点。Nomad 是一个二进制文件，而不是六种不同的服务，它的编排支持并不仅限于容器。

Elastic Container Service (ECS)

与许多其他供应商一样，亚马逊曾经是编排器大战中的竞争者。它开发了一个专有的容器编排器，称为Elastic Container Service[13]或 ECS，作为在 AWS 云中启动容器的解决方案。

后来，亚马逊采用了 Kubernetes，这是其今天的主要容器服务 Elastic Kubernetes Service (EKS) 以及EKS Anywhere[14]等变体的基础。

然而，尽管近年来 EKS 一直是亚马逊对容器相关工具和服务的大部分投资的受益者，但该公司继续支持 ECS，并且没有暗示它将很快停止该服务。如果您想在没有 Kubernetes 的情况下运行容器并且对使用 AWS 云感到满意，那么 ECS 是一个明显的 Kubernetes 替代方案。

Onteon

Onteon[15] 是一个新兴的编排平台，致力于解决 Kubernetes 几乎忽略的一个问题：支持传统应用程序和现代容器化应用程序。

Onteon 通过管理和扩展所有类型的应用程序来做到这一点，无论它们是否基于微服务。通过这种方式，该平台旨在迎合无法或不会对其所有应用程序进行现代化改造但希望以现代方式编排所有应用程序的企业。

目前，Onteon 仍然是新的和模糊的。但这证明至少仍有一些开发人员认为从头开始构建新的编排器仍然有价值。

结论

Kubernetes 可能会主导容器编排市场。但是大约 12% 的组织在没有 Kubernetes 的情况下运行容器，很可能使用上述 Kubernetes 的替代方案之一：Swarm、Nomad、ECS 或 Onteon。

参考资料

[1]

Kubernetes: https://www.itprotoday.com/hybrid-cloud/pros-and-cons-kubernetes-based-hybrid-cloud

[2]

据 Red Hat 称: https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-2021-overview

[3]

几乎不是第一个容器平台: https://www.itprotoday.com/containers/history-container-technology-offers-lessons-future

[4]

于 2014: https://www.docker.com/blog/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/

[5]

作为谷歌内部项目的: https://blog.risingstack.com/the-history-of-kubernetes/

[6]

于 2016 年开源: https://d2iq.com/blog/hindman-mesos-dcos

[7]

SUSE 收购: https://www.suse.com/news/suse-completes-rancher-acquisition/

[8]

创建了一个编排平台: https://github.com/spotify/helios

[9]

原因: https://www.itprotoday.com/hybrid-cloud/4-reasons-why-kubernetes-so-popular

[10]

Swarm 已经死了: https://www.reddit.com/r/docker/comments/es1kxr/future_of_docker_swarm/

[11]

一直在支持 Docker Swarm: https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/

[12]

HashiCorp Nomad: https://www.nomadproject.io/

[13]

Elastic Container Service: https://aws.amazon.com/ecs/

[14]

EKS Anywhere: https://www.itprotoday.com/hybrid-cloud/who-does-or-doesn-t-need-eks-anywhere

[15]

Onteon: https://onteon.com/

原文：https://tinyurl.com/5kmwtj7b