作为开源容器编排器，Kubernetes已经成为组织部署容器化应用程序的实际解决方案。这其中有一些充分的理由，其中包括Kubernetes提供高度的可靠性、自动化、可扩展性的事实。尽管如此，有此行业人士还是认为Kubernetes架构过于复杂。虽然已经有6年以上的应用历史，但它还是有许多缺点。其中一些缺点是Kubernetes本身所固有的，而另一些缺点则是围绕该平台成长起来的生态系统的产物。

在部署Kubernetes之前，企业需要考虑以下开源容器编排器的一些问题。

首先，Kubernetes架构始终是为需要管理超大规模应用程序环境的组织而构建的。对于谷歌公司来说(Borg编排者构成了成为开源Kubernetes项目的基础)，Kubernetes是一个很好的工具。而对于拥有数十个数据中心以及数千个分布在其中的应用程序和服务的Netflix、Facebook、AWS等其他大规模的公司来说，也是如此。

但是如果是一个规模较小的组织，并且只有一个可能只部署十几个应用程序的数据中心，那么Kubernetes架构无疑规模过于庞大，这可能就像驾驶推土机为后院花园翻土一样大材小用。除非是大规模使用，否则配置和管理它需要解决大量的问题。

Kubernetes架构的另一个问题是，Kubernetes有很多发行版，以及大量与其相关的不同的工具、理念和观点。

当然，在某种程度上，任何开源生态系统中都会发生分裂。例如，RedHat Linux与Ubuntu Linux具有不同的软件包管理器、管理工具等。但是，RedHat和Ubuntu的相似之处远大于区别。对于使用Red Hat系统的管理员来说，如果要迁移到Ubuntu，则不需要花费六个月的时间自学新工具。

行业专家并不认为Kubernetes也是如此。如果现在正在使用OpenShift，但又想切换到VMware Tanzu，则其学习过程将非常艰巨。尽管这两个Kubernetes发行版都使用相同的基础平台Kubernetes，但是它们添加的方法和工具却截然不同。

基于云计算的Kubernetes服务也有类似的分裂。Google Kubernetes Engine(GKE)与Amazon EKS(相当于AWS云)等平台相比，具有截然不同的用户体验和管理工具套件。

当然，这并不是Kubernetes架构本身的错，而是不同供应商尝试使其Kubernetes产品实现差异化的结果。但是从Kubernetes用户的角度来看，这仍然是一个现实问题。

人们将Kubernetes当作一个平台，但实际上它由6个以上的不同组件组成。这意味着当安装或更新Kubernetes时，必须分别处理每个组件。而且大多数Kubernetes发行版都缺乏执行这些操作的自动化解决方案。

当然，Kubernetes是一个复杂的平台，它需要多个部分组合才能工作。但是与其他复杂平台相比，Kubernetes在将其各个部分集成到一个易于管理的整体方面做得特别糟糕。典型Linux发行版也包含许多不同的软件。但是用户能够以集中、简化的方式安装和管理它们。Kubernetes架构并非如此。

使用Kubernetes的最常被提及的原因之一是，它以一种神奇的方式管理应用程序，保证它们永远不会失败，即使部分基础设施出现故障。

确实，Kubernetes架构可以做出明智的自动决策，以决定将工作负载放置在集群中的位置。但是，Kubernetes并不是实现高可用性的灵丹妙药。例如，它将在只有一个主节点的生产环境中运行，这是关闭整个集群的方法(如果主要服务器出现故障，则整个集群将基本上停止运行)。

Kubernetes也不能自动保证在集群中运行的不同工作负载之间正确分配资源。要进行设置，用户需要人工设置资源配额。

尽管Kubernetes需要大量的人工干预才能提供高可用性，但是如果确实要这样做，它会使人工控制变得相当困难。

可以肯定的是，有一些方法可以修改Kubernetes执行的探测时间，以确定容器是否正常运行，或者强制工作负载在集群中的特定服务器上运行。但是，Kubernetes架构的设计并不期望管理员会进行这些人工更改。

如上所述，Kubernetes首先是针对Web规模的部署，这是有道理的。如果用户有数千台服务器和数百个工作负载，将不会人工配置许多东西。但是如果是一家规模较小的公司，并且想要更好地控制集群中工作负载的结构方式，那么采用Kubernetes很难做到这一点。

Kubernetes试图在保持工作负载正常运行方面做得很好(尽管如上所述，其能力取决于诸如用户设置的管理者数量以及如何组织资源分配等因素)。

但是Kubernetes架构并不能帮助用户监视工作负载或确保它们表现最佳。它不会在出现问题时向用户发出警报，而且从集群中收集监视数据也不太容易。Kubernetes发行版随附的大多数监视仪表板也无法提供对环境的深入可见性。采用第三方工具可以使用户获得可见性，但是如果要运行Kubernetes，则必须设置、学习和管理这些工具。

同样，Kubernetes也不擅长帮助用户优化成本。它不会通知用户集群中的服务器是否仅以20%的容量使用，这可能意味着用户在过度配置的基础设施方面浪费了资金。同样，第三方工具可以帮助用户应对诸如此类的挑战，但它们会增加复杂性。

在Kubernetes中，完成几乎所有任务都需要用户编写代码。通常情况下，其代码采用YAML文件的形式，然后必须在Kubernetes行上应用它们。

许多人会把Kubernetes架构的所有代码要求作为功能而不是错误。然而，虽然使用单一方法和工具(即YAML文件)可以管理整个平台，但确实希望Kubernetes能为需要它们的人提供其他选择。

有时候，用户不想编写一个很长的YAML文件(或从GitHub中提取一个文件，然后人工调整其中的随机部分以适合其环境)来部署简单的工作负载。用户希望按下一个按钮或运行一个简单的(这指的是不需要十几个参数的kubectl命令，其中许多参数都配置有必须复制和粘贴的数据串)。需要在Kubernetes中做一些简单的事情。但是这种情况很少发生。

Kubernetes的最后一个问题是，它的设计并不能很好地与其他类型的系统配合。它希望成为用户用来部署和管理应用程序的唯一平台。

如果用户的所有工作负载都是容器化的，并且可以由Kubernetes进行协调，这是一个很好的结果。但是，如果用户拥有无法作为容器运行的原有应用程序怎么办?或者，如果想在Kubernetes集群上运行一部分工作负载，而又有一部分在外部运行呢?Kubernetes不提供执行这些操作的原生功能。其设计的前提是希望一直在容器中运行所有内容。

Kubernetes其实是编排大型容器化应用程序的强大工具。 Kubernetes有很多适合的用例。

但是Kubernetes架构也有一些缺点。总体而言，如果用户要管理原有的工作负载或部署规模不足以证明Kubernetes带来的所有复杂性，那么就不是一个很好的解决方案。为了证明它的全部价值，Kubernetes应该解决这些问题，以便它可以完全匹配其在IT生态系统某些领域中享有的声誉。

原文来自：

本文地址：//gulass.cn/kubernetes-questions.html编辑：圆蛋，审核员：清蒸github

Linux命令大全：

Linux系统大全：

红帽认证RHCE考试心得：