Kubernetes架构非常适合有一定服务规模的组织，但它对其他人来说可能过于复杂。

开源容器编排平台Kubernetes已经成为任何在生产环境中部署容器化应用程序的人事实上的解决方案。这有很多原因，包括Kubernetes提供了高度的可靠性、自动化和可伸缩性。尽管如此，我有时认为Kubernetes的架构被过分夸大了。尽管现在已经6岁多了，它还是有各种各样的缺点。其中一些是Kubernetes本身固有的，而另一些则是围绕平台发展起来的生态系统的产物。

在您加入Kubernetes的行列之前，请考虑以下关于开源容器编排平台的问题。

Kubernetes是为有一定网络规模的公司设计的。

首先，Kubernetes体系结构是为那些需要管理非常大规模的应用程序环境的公司而构建的。

如果您是谷歌(它的Borg orchestrator为后来的开源Kubernetes项目奠定了基础)，那么Kubernetes是一个伟大的工具。如果你是Netflix、Facebook、亚马逊(Amazon)或其他拥有数十个数据中心、数百个应用程序和服务的网络规模公司，这也是正确的。

但是，如果您是一个拥有一个数据中心和十几个应用程序需要部署的较小的组织，那么Kubernetes体系结构可以说是多余的。这就像用推土机为后院草地翻土一样。除非大规模地使用它，否则配置和管理它所需要的努力是不值得的。

这并不是说Kubernetes永远不适合小规模的部署。我认为它正朝着那个方向发展。但是，现在每当我启动Kubernetes集群，在少数服务器上部署一两个应用程序时，我就确信使用更简单的解决方案会更好。

支离破碎的Kubernetes生态

Kubernetes架构的另一个问题是，有太多的Kubernetes发行版——以及与之相关的太多不同的工具、哲学和观点——Kubernetes生态系统已经高度断裂。

当然，在某种程度上，任何开源生态系统都会发生破裂。

例如，Red Hat Enterprise Linux与Ubuntu Linux有不同的包管理器、管理工具等。然而，Red Hat和Ubuntu的相似之处多于它们的不同之处。如果你是Red Hat的系统管理员，如果你想要迁移到Ubuntu，你不需要花六个月的时间来教自己新的工具。

我不认为Kubernetes也能这么说。如果你现在正在使用OpenShift，但想要切换到VMware Tanzu，你将面临一个非常陡峭的学习曲线。尽管这两个Kubernetes发行版使用相同的底层平台——Kubernetes，但它们所添加的方法和工具却截然不同。

基于云计算的Kubernetes服务也存在类似的分裂。谷歌Kubernetes引擎(GKE)的用户体验和管理工具套件与Amazon EKS等AWS云平台截然不同。

当然，这不是Kubernetes架构本身的错。这是不同供应商试图将Kubernetes产品区分开来的结果。但从Kubernetes用户的角度来看，这仍然是一个真正的问题。

Kubernetes的组件太多了

我们谈论Kubernetes时，好像它是一个单一的平台，但实际上它包含了超过6个不同的组件。这意味着，当你安装或更新Kubernetes时，你必须分别处理每个部分。而且大多数Kubernetes发行版都缺乏很好的自动化解决方案来做这些事情。

当然，Kubernetes确实是一个复杂的平台，它需要多个部分来工作。但是与其他复杂的平台相比，Kubernetes在将其各个部分集成到一个易于管理的整体方面做得特别差。典型的Linux发行版也由许多不同的软件组成。但是您可以以一种集中的、精简的方式安装和管理它们。Kubernetes的架构并非如此。

Kubernetes不会自动保证高可用性

使用Kubernetes的一个最常见的原因是，它神奇地以一种方式管理你的应用程序，以确保它们永远不会失败，即使你的部分基础设施失败。

Kubernetes体系结构确实能够智能、自动地决定在集群中将工作负载放置在何处。然而，Kubernetes并不是高可用性的灵丹妙药。例如，它在只有一个主节点的生产环境中正常运行，这将导致整个集群崩溃。(如果主服务器故障，整个集群将基本停止工作。)

Kubernetes也不能自动保证在集群中运行的不同工作负载之间合理分配资源。为此，您需要手动设置资源配额。

很难手动控制Kubernetes

尽管Kubernetes需要大量的手动干预来提供高可用性，但如果您真正想要手动控制的话，它会使手动控制变得相当困难。

可以肯定的是，有一些方法可以修改Kubernetes执行探针时间，以确定容器是否正确地执行，或者强制工作负载在集群中的特定服务器上运行。但是Kubernetes体系结构的设计初衷并不是让管理员手动进行这些更改。它假设您总是喜欢使用默认值。

这是有意义的，因为(如上所述)Kubernetes首先是为web规模的部署而创建的。如果您有数千台服务器和数百个工作负载，您不需要手动配置很多东西。但是，如果您是一个规模较小的企业，希望对集群内的工作负载结构有更多的控制，那么Kubernetes很难做到这一点。

Kubernetes监控和性能优化存在一些挑战

Kubernetes试图让您的工作负载保持正常运行(尽管如上所述，它做到这一点的能力取决于一些因素，比如您设置了多少个主机以及您如何结构化的进行资源分配)。

但是Kubernetes体系结构并不能帮助您监控工作负载或确保它们的性能达到最佳。当出现问题时，它不会向您发出警报，而且从集群中收集监控数据并不容易。Kubernetes发行版附带的大多数监视仪表板也没有提供对环境的深入可见性。有第三方工具可以给你提供可见性，但如果你想运行Kubernetes，这些是你必须建立、学习和管理的另一件事。

同样，Kubernetes也不擅长帮助您优化成本。如果集群中的服务器仅被使用了20%的容量，它不会通知您，这可能意味着您在过度供应的基础设施上浪费资源。在这里，第三方工具可以帮助您应对类似的挑战，但它们增加了更多的复杂性。

Kubernetes将一切都简化为代码

在Kubernetes中，完成任何任务都需要编写代码。通常，这些代码采用YAML文件的形式，然后必须应用于Kubernetes命令行。

许多人将Kubernetes体系结构的一切皆代码的需求视为一种特性，而不是一个bug。然而，当然我理解使用单一方法和工具(意味着YAML文件)管理整个平台的价值，但我确实希望Kubernetes能为需要它们的人们提供其他选项。

有时候，我不想编写一个很长的YAML文件(或者从GitHub中提取一个YAML文件，然后手动调整其中的随机部分以适应我的环境)来部署一个简单的工作负载。我真希望我可以按下一个按钮或运行一个简单的命令(我指的是kubectl命令不需要12个参数,其中许多配置了神秘的数据字符串必须复制粘贴)有没有办法在Kubernetes做一些简单的操作就可以完成这个过程。但就目前而言无法实现。

Kubernetes想要控制一切

我对Kubernetes的最后一个抱怨是，它的设计并不能很好地与其他类型的系统一起运行。它希望成为您用于部署和管理应用程序的唯一平台。

如果您的所有工作负载都是容器化的，并且可以由Kubernetes进行编排，那就太好了。但是，如果您的遗留应用程序不能作为容器运行呢?或者，如果希望在Kubernetes集群上运行部分工作负载，而在外部运行另一部分工作负载，又该怎么办?Kubernetes没有提供原生的功能来做这类事情。它的设计假设是每个人都想一直使用容器运行所有的内容。