不使用Kubernetes发行版的5个理由分别是什么

不使用Kubernetes发行版的5个理由分别是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

成都做网站、网站制作的开发，更需要了解用户，从用户角度来建设网站，获得较好的用户体验。成都创新互联多年互联网经验，见的多，沟通容易、能帮助客户提出的运营建议。作为成都一家网络公司，打造的就是网站建设产品直销的概念。选择成都创新互联，不只是建站，我们把建站作为产品，不断的更新、完善，让每位来访用户感受到浩方产品的价值服务。

目前有不少公司基于 Kubernetes 封装了自己的商用 Kubernetes 发行版，丰富了开发生态，也提供给开发者更多选择。

最近有人提出，选择发行版总体上需要更少的精力和专业知识，但因为种种理由，组织机构其实应该考虑使用原生 Kubernetes。

为了帮助大家理解，先介绍一下文中的一个名词“Vanilla Kubernetes”，Vanilla Kubernetes 指纯净、原生的 Kubernetes，一般还有 Vanilla JavaScript / Vanilla Linux 等用法，指原生 JavaScript 或 Linux，而不是它们的方言版或发行版本。

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 一个机会。

看完上述内容，你们掌握不使用Kubernetes发行版的5个理由分别是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！