如何拓展Kubernetes API

发布时间：2022-07-26 15:34 所属栏目：124 来源：互联网

导读：Django是一个通用的Web框架，而Kubernetes则是一个容器编排器。显然，不同的项目根本不应该进行比较。然而，在本系列文章中，我试图揭开Kubernetes的神秘面纱，并展示它的API是一个非常普通的HTTP API，并且可以以相当熟悉的方式进行扩展。虽然Kubernetes社

　　Django是一个通用的Web框架，而Kubernetes则是一个容器编排器。显然，不同的项目根本不应该进行比较。然而，在本系列文章中，我试图揭开Kubernetes的神秘面纱，并展示它的API是一个非常普通的HTTP API，并且可以以相当熟悉的方式进行扩展。

　　虽然Kubernetes社区提供了一个更广泛、更通用的控制器定义，但在与Kubernetes控制器打交道一年多后，我提出了以下解释，涵盖了迄今为止我见过的大多数自定义控制器：

　　控制器实际上是一个主动协调过程（读取：无限循环），它读取所需的状态并相应地更新实际状态。
　　然而，一个控制器通常被绑定到单一的Kubernetes资源类型。我们称它为控制器的主要资源。
　　控制器侦听系统事件：最重要的是，创建或修改主资源对象，但也改变其他（次要或拥有）资源、计时器事件，等等。
　　无论事件的性质如何，总是可以将事件归因于一个或多个主资源类型的对象。
　　事件发生后，控制器会从API中逐一读取相应的主要资源对象，检查各对象的规范属性（即所需状态），应用变更来让系统更接近于所需状态，再使用此状态反过来更新各个对象。

　　控制器可以将任何资源类型作为其主要资源，包括pods、jobs或services等内置资源。问题是，大多数（如果不是所有的话）内置资源已经有相应的内置控制器。因此，定制控制器通常是为定制资源编写的，以避免多个控制器更新共享对象的状态。

　　从本质上讲，什么是资源？用Kubernetes自己的话说：

　　资源是Kubernetes API中的一个端点，它存储特定类型的API对象集合；例如，内置的Pods资源包含一个Pod对象的集合。

　　因此，如果资源仅仅是Kubernetes API端点，那么为资源编写控制器只是一种将请求处理程序绑定到API端点的奇特方式！

　　每当有对主要资源端点的创建或修改请求时，（特别是）控制器的逻辑就会被触发。触发控制循环迭代的主资源类型的实例作为请求参数（对象的规格字段）和响应状态（对象的状态字段）的数据传输对象。

（编辑：ASP站长网）