押注 Kubernetes，一个 Red Hat 的视角

两年前，红帽在 Kubernetes 上下了重注。我们押注了一个简单的想法：开源社区是构建应用编排未来的最佳场所，并且只有开源社区才能成功整合成功所需的多样化能力。作为一名红帽人，这个想法并非遥不可及——我们已经在许多社区成功应用过它，但也看到它失败过，尤其是在广泛的覆盖范围没有坚实基础支持的情况下。在 Kubernetes 1.0 发布一周年，也就是 Kubernetes 项目首次开源提交两年后，值得提出这个问题：

Kubernetes 是正确的选择吗？

软件的成功取决于其用户的成功——该软件是否为他们带来了新的机会或效率。在这方面，Kubernetes 超出了我们最疯狂的梦想。我们知道有数百个 Kubernetes 的实际生产部署，包括通过红帽支持多租户的 OpenShift 发行版在企业中部署，在 Google Container Engine (GKE) 上部署，由一些全球最大的软件公司运行的高度定制版本，以及通过教育、娱乐、初创企业和自制社区部署。这些部署者报告称，交付时间缩短，应用生命周期标准化，资源利用率提高，以及应用程序更具弹性和健壮性。这仅仅是来自客户或社区贡献者的报告——如果现在有成千上万的 Kubernetes 安装管理着成千上万个实际应用程序，我也不会感到惊讶。

我相信这种覆盖范围验证了 Kubernetes 的核心愿景：通过为分布式计算中的每个核心模式提供工具，构建一个适用于所有应用程序的平台。这些模式包括：

• 简单的复制型 Web 软件
• 分布式负载均衡和服务发现
• 在容器中运行不可变镜像
• 将相关软件并置到 Pod 中
• 简化网络附加存储的使用
• 灵活而强大的资源调度
• 在服务工作负载旁边运行批处理和计划任务
• 管理和维护集群软件，如数据库和消息队列

允许开发人员和运营商转移到更高一级的抽象，就像它们使谷歌和技术生态系统中的其他公司能够扩展到数据中心计算机及更远一样。从 Kubernetes 1.0 到 1.3，我们不断提高平台的强大性和灵活性，同时还改进了性能、可伸缩性、可靠性和可用性。Kubernetes 之上集成和工具的爆炸式增长进一步验证了核心架构决策的可组合性，暴露开放灵活的 API，以及有意识地限制核心平台并鼓励扩展。

今天，Kubernetes 拥有开源生态系统中最大、最活跃的社区之一，拥有近千名贡献者，是 GitHub 上任何单一仓库项目中人工生成提交率最高的项目之一，有超过一千个围绕 Kubernetes 的项目，以及同样活跃的 Stack Overflow 和 Slack 频道。红帽很荣幸能作为 Google 之后 Kubernetes 最大的贡献者之一，成为这个生态系统的一部分，每天都有更多的公司和个人加入我们。Kubernetes 的理念找到了肥沃的土壤，而你们，社区，提供了让它成长的热情和承诺。

那么，我们押对宝了吗？基于以上所有原因，以及数百个其他原因：是的。

下一步是什么？

尽管我们对 Kubernetes 的成功感到高兴，但现在还不是休息的时候！虽然我们希望在 Kubernetes 中构建更多功能和改进，但我认为普遍的共识是，我们希望专注于唯一重要的长期目标——围绕 Kubernetes 建立一个健康、成功和蓬勃发展的技术社区。正如约翰·F·肯尼迪可能说过的那样： 

> 不要问你的社区能为你做什么，而要问你能为你的社区做什么

在最近发布到 kubernetes-dev 列表的帖子中，Brian Grant 阐述了一系列出色的近期目标——这些目标有助于社区成长、完善我们的执行方式并实现未来的扩展。在每个 Kubernetes 特别兴趣小组中，我们都在努力建立可持续的团队，这些团队可以在公司和社区之间进行协作，我们正在积极努力确保每个 SIG 都能在项目的一个愿景下，跨越不同兴趣领域进行贡献、协调和交付。

我们特别感兴趣的是扩展的故事——Kubernetes 的核心如何成为数据中心操作系统的心脏，并支持更多应用程序管理模式在 Kubernetes 之上构建，而不仅仅是构建到其中。1.2 和 1.3 版本中围绕第三方 API、API 发现、灵活的调度器策略、外部授权和认证（超出 Kubernetes 内置的那些）所做的工作只是一个开始。当有人有需求时，我们希望他们能够轻松找到解决方案，我们也希望其他人能够轻松使用并贡献该解决方案。同样，验证想法的最佳方式是针对实际需求进行原型设计，并针对实际问题进行迭代，这应该简单自然。

在 Kubernetes 的两岁生日之际，我希望回顾一年来的完善、用户成功和社区参与。能为 Kubernetes 做出贡献是我的荣幸，感觉我们才刚刚开始。谢谢大家，希望大家能一起踏上这段旅程！

• ←上一篇
• 下一篇→