Kubernetes为什么如此复杂

为什么Kubernetes这么复杂？

与其他系统相比，Kubernetes确实更大、更复杂。我相信很多人在使用它的过程中都试图理解它为什么用户也是如此，并写下了他的理解。

Kubernetes是一个集群操作系统。

Kubernetes更像是一个通用的集群操作系统核心。传统操作系统的工作是暴露计算机及其所有相关硬件的接口，使应用程序能够访问这些接口。我们不知道具体细节，但这些接口有相应的设计目标。

资源共享-将物理计算机的资源细分为多个程序，使其在一定程度上相互隔离；

可移植性-在一定程度上抽象底层硬件的准确细节，使同一程序可以在不同的硬件上运行，无需修改或稍加修改；

通用性-当新硬件插入计算机时，这些硬件可以逐步纳入抽象和接口。最好不要大大改变任何接口或破坏任何不使用硬件的现有软件。

完整性-与通用性有关，操作系统可以调解所有对硬件的访问：软件应该很少或不可能完全绕过操作系统的核心。该软件可以使用操作系统的核心来建立与硬件的直接连接，从而使未来。

交互直接发生（如建立内存映射命令管），但最初的分配和配置仍在操作系统的监督下。

性能-与“直接编写一个特殊用途的软件，直接在硬件上运行，对硬件有独家的直接访问权”相比，我希望有这样一个可接受的小性能成本。在某些情况下，通过提供I/O调度器或缓存层等优化，在实践中实现性能高于此系统。

操作系统的核心通常围绕上述目标进行设计，然后编写用户空间库，将低级、通用、高性能的接口包装成更容易使用的抽象概念。操作系统开发人员往往更关心如何使应用程序运行得更快，而不是在我的系统中使用更少的时代码。

Kubernetes与上述设计理念非常相似。它的目标是抽象整个数据中心或云。这一观点有助于理解Kubernetes。它指出了为什么Kubernetes非常灵活。Kubernetes希望拥有普遍性和更强大的功能。它可以在任何类型的硬件或虚拟机实例中部署任何类型的应用程序。没有必要离开Kubernetes界面。无论它是否真的能实现这一目标，这种设计都是非常有意义的。

从上述角度解释的设计选择是Kubernetes的可插入性和可配置性。一般来说，没有奢侈的性能成本，我们不能为每个人做出适用的选择。在现代云环境中，应用程序的类型和部署的硬件类型非常不同，特别是当需要在不同位置快速部署时。这意味着，如果一个系统想适用于所有人，它需要强大的快速配置性能。这确实会建立一个强大的系统，但缺点是它会变得非常复杂。

许多用户认为Kubernetes本质上是一个“Heroku”，即作为一个部署应用程序的平台，它抽象了大多数传统的底层操作系统和分布式系统的细节。Kubernetes认为，他解决的问题更接近“CloudFormation”。从这个意义上说，它希望足以定义整个基础设施。它还试图通过底层云提供商或硬件来实现这一点。

Kubernetes中的一切都是一个控制循环。

想象一个非常必要的“集群操作系统”。正如上面所述，它暴露了“分配五个CPU的计算量”或“创建一个新的虚拟网络”等基本元素。这些基本元素反过来支持系统内部抽象配置变化或调用EC2API（或其他基本云提供商）。

然而，Kubernetes并非如此。相反，Kubernetes的核心设计决定了所有配置都是声明的，并通过作为控制循环的“操作员”来实现。他们不断将预期配置与实际状态进行比较，修改实际状态，与预期状态一致。

这是一个非常谨慎和充分的设计选择。一般来说，没有设计成控制循环的系统将不可避免地偏离预期配置。因此，有人需要编写控制循环并通过内部化进行控制。Kubernetes希望使大多数核心控制环路只写一次，并由领域专家撰写，以便更容易构建一个可靠的系统。这也是一个系统的自然选择，因为它的本质是分布式的，并且是为构建分布式系统而设计的。分布式系统的决定性是消除一些可能的故障，这要求超过一定规模的系统在不考虑局部故障的情况下，能够自行修复和收敛到正确的状态。

然而，这种设计也带来了系统的复杂性和一定概率的混乱。举两个具体的例子。

第一：错误延迟，在Kubernetes中创建一个对象（如pod），这只是在配置和存储中创建一个对象，断言该对象的预期存在。如果系统在实际分配中不能满足要求，但用户在创建时看不到系统的实际情况，因为资源限制（集群容量）镜像不存在），但用户在创建时看不到系统的实际情况。事实上，只有当开发人员想要修改创建对象时，系统才会产生错误的提示。

这种情况使得一切都更难调试和推理，因为你不能用“创造成功”作为“结果对象存在”的速记。这也意味着与失败相关的日志信息或调试输出信息不会出现在创建对象的过程中。一个完整的代码和强大的控制器将解释正在发生的事情，或以其他方式注释有问题的对象；但对于较差的控制器，日志垃圾只能在控制器的日志中找到。有些变化可能涉及多个控制器，有时独立，有时联合，难以跟踪故障代码。

声明控制循环模式提供了一个隐含的承诺：用户不需要担心如何从状态A到状态B，只需将状态B写入配置数据库，然后等待。当其代码运行良好时，它自然会从状态A进入状态B。这是一个很大的简化。

但有时会出错，即使状态B本身可以实现，也不能或需要等待很长时间才能实现。这是一个罕见的例子，控制器的作者可能会忘记实现它。Kubernetes中的核心内置基元经过了大量的测试和使用，以保持正常工作。但当用户开始添加第三方资源，如管理TLS证书、云负载平衡器、托管数据库或外部DNS名称来运行系统时，程序会偏离轨道，无法清楚地知道路径是如何测试的。这种故障模式和延迟错误一样微妙。很难区分被接受和变化永远不会被接受之间的区别。