Kubernetes解疑：开源产品与开源项目区别在哪里？

在红帽产品与技术总裁Paul Cormier新撰写三部曲系列文章中的第一篇，我们强调了容器就是Linux。本篇探讨开源产品与开源项目之间的争论。

企业需要的是商业化开源产品，而不仅仅是开源项目。

业界纷纷支持和采用Kubernetes的趋势十分明显，几乎每周都有企业发布新的Kubernetes发行版或服务。在撰写本文时，仅仅CNCF Kubernetes一致性计划中就至少已经列出了37套符合规定的Kubernetes软件发行版，还有许多其他托管服务。

选择太多了。但是，这些供应商和机构大多只是在认证和提供Kubernetes，或者Kubernetes加一个或两个组件，用来添加一些扩展功能；它们都不是Kubernetes在其中发挥作用的整体解决方案或平台。就如同Linux基金会是Linux上游开发的管理机构一样，同时它也是更大范围操作系统平台的一部分；而CNCF就是Kubernetes的管理机构。上游开发阶段的一致性并不意味着可行的企业解决方案。

重要的是，我们需要记住，Kubernetes本身并没有做任何事情。正如Linux内核就其本身而言是一套核心组件而不是一套解决方案一样，Kubernetes也只是更大规模解决方案中的一个关键组成部分。对一套产品中的单一部分进行认证只有很有限的使用场合。构成一套商业产品或平台的所有部分都必须相互集成到一起，都必须能够得到支持、更新和协调，并提供安全修复程序。

这样的平台需要一个生命周期来运行企业的业务。它还需要经过认证才能完整地运行于特定硬件配置的特定环境之中，因为所有组件对于该解决方案的成功都至关重要，它们必须协同工作。软件和硬件供应商如果想要构建兼容的解决方案，他们还需要一个“理智点”（point of sanity）来测试、认证、销售和支持其解决方案。

这意味着，Kubernetes必须与产品或平台中所有其他部分（包括Linux容器发行版）相集成，才能形成一套解决方案，供最终客户在其上构建他们的关键任务应用并在以后的日子里依赖它。

例如，借助于红帽OpenShift容器平台，我们正在对基于Kubernetes的整个企业应用平台进行认证，而不仅仅是对作为该平台中一部分的某项技术进行认证。我们对于这种认证采取的支持态度是，所有这些部件将从第一天部署开始直到生命周期结束都一直在一起工作。

即使必须通过更新或安全补丁进行更改，或者该平台上的多个组件发生了更改（例如，在Linux发行版中，在Kubernetes中，以及在Kubernetes上运行的服务中），我们都将对周围的生态系统进行认证，其中包括多种基础设施，如裸机、OpenStack以及主要的公有云提供商。这意味着，我们将成为那家“一锤定音”的企业，因为我们能够支持这种集成的解决方案，而Kubernetes正是其中的一部分。

让我介绍一下这在现实世界中是如何展开的。假设需要在Kubernetes接口的某个Linux内核API中进行修复。我们已经认证，该修补程序将能够向后兼容该平台的其他部分，以便不会破坏关键的应用、服务或集成。或者，如果存在某个安全性漏洞，可能需要对这些API中的任何一个的两端进行更改，我们就需要保证，我们不仅在两端修复了该漏洞，而且它还能够向后兼容。

这正是我们过去15年来一直在做的工作，也是我们的企业用户在红帽企业Linux方面依赖我们处理的事情。

正是诸如红帽这样的公司将所有这些不同的开源开发项目结合在一起，把它们拧成一股绳来解决实际的业务问题。企业用户正在运行的平台由许多此类上游部分组成，并与许多管理机构相关联，但它们协同工作，形成一套面向关键任务企业应用的、受支持的集成产品。

正如我们在20世纪90年代初期开始在各种各样Linux发行版选择中所看到的那样，选择平台不仅仅是为了满足当今开发人员和基础架构团队的需求。它还涉及到了解这些团队的需求在很长时期内如何随同他们构建、集成和维护应用而变化。简而言之，选择一个平台是一个非常漫长的博弈过程，这也是CIO的关键决策。

如果企业用户正在选择某个平台来运行其企业的业务，他们应该选择一款基于开源的产品，而不是一套开源项目。虽然两者都建立在相同的社区原则和开源创新基础之上，但产品与项目在它们各自长期提供稳定、安全、经济高效且可支持的解决方案方面存在很大差异。特别是在考虑如何在混合云环境中使用Kubernetes和容器时，更是如此，而这种环境正迅速成为每个企业的现实。

基于此，现在让我们来探讨一下开源项目与基于开源开发的商业产品之间的差异。

社区驱动的开源项目，例如Linux内核和上游Kubernetes，必然会由于强劲、活跃的开发者及用户社区而茁壮成长。他们是项目创新背后的力量，能够通过快速进化、更短的代码生命周期以及愿意承受失败，并乐于“打破一切”来看看到底什么东西能够发挥作用，而帮助解决社区提出的问题。

基于上游社区项目构建的版本通常是开源发布版（通常称为下游），例如Fedora、CentOS、Wildfly和Project OKD（以前称为OpenShift Origin）。这些项目通常汇集了多种开源技术，并为进一步基于社区的开发和创新提供了有针对性的基础，同时确保在此阶段可能开发的所有创新都可以追溯到上游树。这种技术为下一阶段的开发提供了动力，而这下一阶段的开发往往是企业级产品的基础。在Linux领域，Fedora是其变成红帽企业版 Linux之前的最后一个开发阶段。

红帽企业版Linux是基于开源的商业化产品的一个例子，它具有我们上面所讨论的所有商业属性。像这样的产品遵循与它们所基于的社区和/或分发项目相同的上游功能特征，但这是按照规范做的。这些产品强调与企业IT相关的长期博弈，通过OEM和ISV认证来专注于长期维护，例如强化、后移（backporting）、API/ABI兼容性、安全响应、技术支持以及特定生态系统关系等。

就企业产品而言，我们根据用户的意见提供了对配置、部署选项以及功能的选择，同时也允许用户注入其他不会破坏核心产品完整性或可支持性的组件。

如果ISV和IHV供应商正在寻找基于Linux的容器平台来支持和驱动兼容性，那么，从这些ISV和IHV供应商的角度来看，他们没有能力测试包含该平台中各种组件30多个版本的矩阵，例如Kubernetes、Linux容器等。这甚至无法应付这样的事实：这些版本通常会每6到12个月就会更改一次，而且基础代码的兼容性通常在75-99％之间，具体取决于所采用的组件/版本，以及针对该平台的任何部分所实施的缺陷修复程序。每当这些组件中的任何一个发生这些微小变化之一时，至少需要再次执行测试矩阵。

ISV和IHV希望获得稳定的产品，由受信任的软件供应商为支撑，具备某个项目来提供支持、挖掘大规模市场机会以销售其解决方案，并开展持续的业务协作。

就像在选择Linux发行版过程中面对的问题一样，选择商业化的、开源的企业版Linux容器和Kubernetes解决方案也是构建现代数字化转型企业过程中的关键因素，这样的企业非常重视混合云。这一选择为开发商、运营商和客户提供了更大的信心，使他们确信：专业化的供应商将能够维护和发展其平台选择，以满足未来几年不断变化的需求，即使面对波动不定的技术及业务环境。

当您的团队最终决定企业IT基础架构的未来发展方向时，请关注具有以下特征的长期博弈解决方案：与社区保持一致，提供完整的环境，最重要的是，把满足业务需求作为其优先事项。

在本系列文章的第三部分，我将探讨目前Kubernetes的实际格局，并讨论为什么商业支持的Linux操作系统仍然是企业普及过程中的关键部分。