作者 | afotostock、Shutterstock
编辑 | 言征
出品 | 51CTO技术栈（微信号：blog51cto）
6 月 6 日是Kubernetes发布 10 周年纪念日。
值得回想一下 2014 年，当时 Kubernetes 是当时推出的众多管理容器的方法之一。当时已经存在像 Apache Mesos 这样的大型开源项目，而启动容器化的公司Docker则通过其 Docker Swarm 提供了一个很好的选择。各家公司也在研究像 AWS ECS 管理工具这样的方法，以及如何将它们用于特定的容器管理。
那么，为什么 Kubernetes 会胜出呢？我们最终会选择 Kubernetes 作为云原生应用的平台吗？还是说这其中存在一些障碍？
1.从无状态到有状态的工作负载
大家起初认识Kubernetes时，是作为一个容器管理和编排平台，它可以更轻松地管理微服务应用程序中的所有软件容器。Kubernetes 基于Google 的内部容器管理服务Borg，该服务可处理数千个实例，最终以开源形式发布，供其他人利用来运行容器。
首先，必须指出的是，Kubernetes 起步并不显眼。虽然一开始它被寄希望基于 Google 用于管理大量工作负载和流程的工具，但它事实上并没有准备好在其他组织中承担这一角色。它非常适合管理无状态应用程序容器，并协调如何创建、使用以及在不再需要时拆除这些容器。但它一开始只专注于应用程序组件。
这与构成应用程序基础架构的所有其他元素并不相符。虽然您的应用程序可能在云中运行并执行处理，但它也会创建必须随时间存储的数据。它必须与现有的数据源进行交互。它必须安全地运行，这样信息就不会泄露，攻击者也无法访问这些组件。这些元素在 Kubernetes 的初始发布中不受支持。事实上，在考虑这些工作负载之前，又花了两年时间才获得StatefulSets支持和 Kubernetes Operators 的发布。
图片
StatefulSets 提供了对稳定且唯一的网络标识符以及稳定且持久的存储的支持。它还可以执行更有序、更优雅的部署和扩展，以及更有序、更自动化的滚动更新。除此之外，Kubernetes Operators 的推出还允许开发人员隐藏将 Kubernetes 原语与其他应用程序一起使用的复杂性。如果没有这两项附加功能，在 Kubernetes 中运行有状态工作负载需要进行一些严肃的 Kubernetes 核心黑客攻击才能使其正常工作。
除此之外，社区也在努力让有状态工作负载在 Kubernetes 上有效运行。虽然围绕运行 MySQL 和 PostgreSQL 等数据库的讨论始于 Reddit 和 Stack Overflow，但需要更正式的合作才能将其从好主意转变为真实且可持续的项目。像Kubernetes 上的数据社区这样的组织齐心协力为这种合作提供了正确的框架，使公司和个人更容易做出贡献。
图片
这项工作至关重要，因为一开始在 Kubernetes 上运行数据库时有很多阻力。对于熟悉设计应用程序的12 个因素方法的人来说，后端服务应被视为附加资源。当时，这对于想要在容器中运行但又必须管理与托管在不同环境中的数据库或存储系统的交互的开发人员来说是个问题。理想的方法（也是我们现在拥有的）是数据库应该以与应用程序组件完全相同的方式在集群中运行，因为这使得从一个点控制和管理整个服务的基础架构变得更加容易。
2.开源的作用
Kubernetes 成功的主要原因之一是它是开源的。Kubernetes 被捐赠给云原生计算基金会，以便它能够得到更广泛的组织而不是一家控制供应商的支持。这有助于分散贡献方面的负担并提高接受度。当用户考虑如何在云计算平台上下注时，选择一个不依赖于特定云提供商并且可以在其中任何一个上独立运行容器的平台被视为更明智的选择。
图片
这需要一个愿意支持 Kubernetes 项目的社区，并且他们必须为它的成功而投资。为了建立这个社区，Kubernetes 必须是开源的，正如 Kubernetes 联合创始人 Brendan Burns在 Dev Interrupted播客中解释的那样。如果不开源，开发人员贡献或选择 Kubernetes 作为容器管理工具的动力就会小得多。
随着时间的推移，Kubernetes 已从众多容器编排工具之一发展成为云原生应用程序的平台。它使开发人员能够在任何云平台或自己的数据中心环境中构建和运行他们的应用程序，然后将该工作负载转移到他们未来想要使用的任何平台上。作为其中的一部分，Kubernetes 已从专注于应用程序组件发展到支持云中的所有内容。
Kubernetes 并不完美。例如，Kubernetes 仍需要在自动扩展和管理数据和存储等资源方面做更多工作，以便公司能够更有效地控制成本。但这项工作正在多家公司和社区的支持下进行，因此未来每个人都可以受益。
