目前有不少公司基于 Kubernetes 封装了本人的商用 Kubernetes 发行版，丰厚了开发作态，也提供应开发者更多选择。

最近有人提出，选择发行版总体上需求更少的精神和专业知识，但由于种种理由，组织机构其实应该思索运用原生 Kubernetes。

为了协助大家了解，先引见一下文中的一个名词“Vanilla Kubernetes”，Vanilla Kubernetes 指纯真、原生的 Kubernetes，普通还有 Vanilla JavaScript / Vanilla Linux 等用法，指原生 JavaScript 或 Linux，而不是它们的方言版或发行版本。

作者：Christopher Tozzi

原文：《5 Reasons Not to Use Kubernetes Distributions》

Kubernetes 发行版能够无法像组织机构以为的那样，可以为他们节省时间和金钱。

部署 Kubernetes 有两种主要办法。一种是在数十种软件公司开发的 Kubernetes 发行版中选一个；另一种是经过 Kubernetes 官方源代码，自行安装 Vanilla Kubernetes，即原生 Kubernetes。

传统观念以为，很多时分，运用原生 Kubernetes 不是个好主意。大少数人会说，除非你是 Kubernertse 的开发人员、并想运用中心代码，否则最好运用发行版，发行版提供残缺的安装和部署效劳。这在过去能够是个很好的建议，但如今我们有了更充沛的理由运用原生 Kubernetes，而不是发行版。

什么是原生 Kubernetes？

原生 Kubernetes 指的是 Kubernetes 的原生未修正版本，提供源代码下载。

之所以称为原生版，是由于在软件界有一个长达几十年的传统，即打上“Vanilla”原生标签的软件被部署就任何运用顺序或平台上时，表示这是没有修正过的官方版本。相似于，我们还会听到“原生 Linux” ，这是指运用地道的、官方的 Linux 内核源代码构建 Linux 内核，而不像在 Linux 发行版本中，会修正 Linux 内核顺序。

与原生 Kubernetes 相对的是 Kubernetes 发行版，例如 Rancher，Red Hat OpenShift；或基于云的 Kubernetes 效劳，例如 Amazon EKS。这些发行版采用了中心的开源 Kubernets 代码，并将其集成到更普遍的平台中，而这些平台通常包含不属于 Kubernetes 本身的管理、监视和安全工具。这些平台中的很多还提供安装顺序，简化 Kubernetes 安装顺序。

当 Kubernetes 发行版没有意义时

Kubernetes 发行版一定是有优势的，这里只是想推翻一个传统观念：在95%的运用场景中，发行版 Kubernetes 比原生 Kubernetes 更适宜。

下面是5个原生版比发行版更适宜的缘由：

1. Kubernetes 不是 Linux，复杂水平相对较低

关于初学者来说，许多关于原生 Kubernetes 的争议是：它是一个复杂平台，从头末尾安装和构建太难了。

实践上，Linux 比 Kubernetes 复杂得多。要从头构建一个可用的，基于 Linux 的操作系统，必须构建和安装数十个，甚至数百个单个组件。

而 Kubernetes 包含大约十二个组件，其中有一些是可选的，你可以在每天的闲暇时间，一天安装一次。但关于 Linux 发行版中的一切适用顺序和运用顺序，状况并非如此。

还有选择 Linux 发行版的部分缘由是，发行版经过软件包管理器，更容易使软件保持最新形状。异样，Kubernetes 发行版相较原生版，一个优势也是更新更轻松，但由于 Kubernetes 中需求更新的组件少了很多，这个优势就没那么清楚了。

2. Kubernetes 发行版会锁定生态系统

假设运用 Kubernetes 发行版，会堕入该发行版周围的生态系统中。

虽然有时分运用 Kubernetes 发行版也可以在部署进程中运用第三方开源软件，而且大少数 Kubernetes 发行版的部分组件本身也是开源的。

但是，大少数状况下，发行版比原生版更容易招致对某些中心工具或是依赖项的依赖。例如，假设运用 OpenShift，则会遭到各种组件的约束。假设你运转基于 AWS EK 或 Azure AKS 的基于云的 Kubernetes 发行版，那么你将堕入该云提供商的生态系统之内。

假设安装了原生 Kubernetes，则将有更多自在选择要构建部署所需组件。

3. 运用 Kubernetes 发行版是有代价的

成本要素也值得思索。大少数 Kubernetes 发行版都是由商业公司开发的，要花钱才能大规模运转，虽然有些确实会为小型的部署提供收费套餐。

当然，原生 Kubernetes 也要付出一定的金钱成本。源代码能够是收费的，但是你的工程师需求花时间去管理维护。长期以来，这种说法不断被当成是运用发行版 Kubernetes 的理由。

但是，当谈到 Kubernetes 时，我不确定，原生 Kubernetes 的人力维护成本，能否一定高于发行版的人力成本。由于无论如何部署，即使是运用发行版，你也需求向工程师支付少量资金来维护和监视部署效果。

另外，鉴于上文提到的，Kubernetes 大约只要十二个组件，因此安装和设置并不会糜费团队太多时间。从这个意义上说，简化安装进程的发行版，并不会降低多少成本。

4. Kubernetes 发行版能够会死亡

Kubernetes 依然是一个十分年轻的平台。当今可用的大少数主流 Kubernetes 发行版仅存在了几年，一些发行版，如 OpenShift 最后甚至不是围绕 Kubernetes 所构建的平台。

一些 Kubernetes  发行版，如 Kontena Pharos 曾经失败了。诸如 Kublr 和 Rancher 之类的其他几家公司则由成立5-10年的创业公司维护。甚至大型企业，如 IBM 的发行版（指 Red Hat OpenShift）或 AWS 的发行版也能够在不知不觉中被杀死。

可以一定地说，开源 Kubernetes 项目将继续很长时间，而运用发型版则大约率会面临该版本消逝，或被迫迁移到新发行版的风险。

5. 原生 Kubernetes 变得更容易安装和维护

最后，Kubernetes 曾经走了很长一段路，用户友好度也在提升。

像大少数开源项目一样，Kubernetes 在初期十分粗糙，它犯过一长串的错误，没有完全文档化、集成常常只完成了一半的任务。因此，许多团队选择发行版来规避成绩。

但是明天，这些错误都已或多或少被修复了，Kubernetes 的文档在组织、导航和明晰度方面可谓模范。

结论

可以一定的是，有许多理由支撑组织机构选择发行版，发行版总体上需求更少的精神和专业知识。但发行版也有不足，如需求更高的成本、更少的灵敏性、以及长期可用性的保证。

在末尾安装 Kubernetes 发行版之前，请记住，Kubernetes 不是 Linux，记得思索给原生 Kubernetes 一个时机。

【编辑引荐】

iOS 14第二个开发者预览版发布：引入诸多细节调整

高效软件开发团队的 4 个好习气

No Code的世界绝无代码！GitHub CEO：编码的未来基本就没有编码

Linux 基金会发布白皮书：地下发布给全世界的开源技术不受 EAR 约束

开源代码也受美国出口控制？Linux基金会白皮书官宣来了

(责任编辑：admin)