Django是一個(gè)通用的Web框架，而Kubernetes則是一個(gè)容器編排器。顯然，不同的項(xiàng)目根本不應(yīng)該進(jìn)行比較。然而，在本系列文章中，我試圖揭開Kubernetes的神秘面紗，并展示它的API是一個(gè)非常普通的HTTP API，并且可以以相當(dāng)熟悉的方式進(jìn)行擴(kuò)展。

有很多方法可以用自定義功能擴(kuò)展Kubernetes，從編寫kubectl插件到實(shí)現(xiàn)調(diào)度器擴(kuò)展。詳細(xì)的擴(kuò)展點(diǎn)列表可以在官方文檔中找到，但如果有一個(gè)基于這種方法的排名，我敢打賭開發(fā)自定義控制器或操作符，如果你愿意的話，會(huì)勝出。

Kubernetes控制器背后的思想很簡(jiǎn)單，但很強(qiáng)大——你描述系統(tǒng)的理想狀態(tài)，將其持久化到Kubernetes，然后等待控制器完成它們的工作，使集群的實(shí)際狀態(tài)足夠接近理想狀態(tài)（或報(bào)告故障）。

然而，雖然控制器得到了很多媒體的關(guān)注，但在我看來(lái)，編寫自定義控制器大多數(shù)時(shí)候應(yīng)該被視為擴(kuò)展Kubernetes API更廣泛任務(wù)的一部分（可能是可選的）。但是要注意到這一點(diǎn)，需要對(duì)典型的工作流相當(dāng)?shù)氖煜ぁ?/p>

自定義控制器

雖然Kubernetes社區(qū)提供了一個(gè)更廣泛、更通用的控制器定義，但在與Kubernetes控制器打交道一年多后，我提出了以下解釋，涵蓋了迄今為止我見過(guò)的大多數(shù)自定義控制器：

• 控制器實(shí)際上是一個(gè)主動(dòng)協(xié)調(diào)過(guò)程（讀取：無(wú)限循環(huán)），它讀取所需的狀態(tài)并相應(yīng)地更新實(shí)際狀態(tài)。
• 然而，一個(gè)控制器通常被綁定到單一的Kubernetes資源類型。我們稱它為控制器的主要資源。
• 控制器偵聽系統(tǒng)事件：最重要的是，創(chuàng)建或修改主資源對(duì)象，但也改變其他（次要或擁有）資源、計(jì)時(shí)器事件，等等。
• 無(wú)論事件的性質(zhì)如何，總是可以將事件歸因于一個(gè)或多個(gè)主資源類型的對(duì)象。

事件發(fā)生后，控制器會(huì)從API中逐一讀取相應(yīng)的主要資源對(duì)象，檢查各對(duì)象的規(guī)范屬性（即所需狀態(tài)），應(yīng)用變更來(lái)讓系統(tǒng)更接近于所需狀態(tài)，再使用此狀態(tài)反過(guò)來(lái)更新各個(gè)對(duì)象。

控制器可以將任何資源類型作為其主要資源，包括pods、jobs或services等內(nèi)置資源。問(wèn)題是，大多數(shù)（如果不是所有的話）內(nèi)置資源已經(jīng)有相應(yīng)的內(nèi)置控制器。因此，定制控制器通常是為定制資源編寫的，以避免多個(gè)控制器更新共享對(duì)象的狀態(tài)。

從本質(zhì)上講，什么是資源？用Kubernetes自己的話說(shuō)：

資源是Kubernetes API中的一個(gè)端點(diǎn)，它存儲(chǔ)特定類型的API對(duì)象集合；例如，內(nèi)置的Pods資源包含一個(gè)Pod對(duì)象的集合。

因此，如果資源僅僅是Kubernetes API端點(diǎn)，那么為資源編寫控制器只是一種將請(qǐng)求處理程序綁定到API端點(diǎn)的奇特方式！

每當(dāng)有對(duì)主要資源端點(diǎn)的創(chuàng)建或修改請(qǐng)求時(shí)，（特別是）控制器的邏輯就會(huì)被觸發(fā)。觸發(fā)控制循環(huán)迭代的主資源類型的實(shí)例作為請(qǐng)求參數(shù)（對(duì)象的規(guī)格字段）和響應(yīng)狀態(tài)（對(duì)象的狀態(tài)字段）的數(shù)據(jù)傳輸對(duì)象。

基于控制器的處理程序與更傳統(tǒng)的請(qǐng)求處理程序之間的主要區(qū)別在于處理與實(shí)際的API請(qǐng)求是異步發(fā)生的。創(chuàng)建或修改Kubernetes對(duì)象的API請(qǐng)求（如POST、PUT、PATCH）只是為控制器調(diào)度工作（通過(guò)記錄意圖），而獲取對(duì)象的API請(qǐng)求（GET、WATCH）用于返回處理狀態(tài)。

自定義資源

如果向Kubernetes API添加請(qǐng)求處理程序是通過(guò)編寫控制器進(jìn)行的，那么如何添加新的API端點(diǎn)呢？

在回答這個(gè)問(wèn)題之前，重要的是要理解Kubernetes API中有兩種類型的端點(diǎn)：

• 第一種類型是服務(wù)于Kubernetes對(duì)象集合（即持久的Kubernetes實(shí)體）的端點(diǎn)，如Pods、ConfigMaps、Services等。絕大多數(shù)API端點(diǎn)都屬于這種類型。
• 第二種基本上是其他所有東西。像/metrics、/logs或/apis這樣的端點(diǎn)是其他類型端點(diǎn)的最突出的例子。這些端點(diǎn)要么被嵌入到Kubernetes API服務(wù)器中，要么使用API聚合層實(shí)現(xiàn)。

控制器通常使用第一種類型的端點(diǎn)。那么，如何將服務(wù)于用戶定義對(duì)象類型的新端點(diǎn)添加到API中呢？

• 首先，需要編寫CustomResourceDefinition（CRD）。CRD本身是一個(gè)描述新的自定義資源的對(duì)象。最重要的是，CRD應(yīng)該包含新資源類型的名稱和版本化對(duì)象模式（即字段）。
• 然后，需要將CRD提交給集群。將CRD應(yīng)用到集群會(huì)創(chuàng)建一個(gè)服務(wù)于自定義資源類型的新的Kubernetes API端點(diǎn)。就這么簡(jiǎn)單！

自定義資源類型的對(duì)象的外觀和行為很像內(nèi)置的Kubernetes對(duì)象，它們受益于常見的API特性（CRUD、字段驗(yàn)證、發(fā)現(xiàn)等），同時(shí)，它們具有解決自定義用例所需的屬性。

自定義資源本身可能很有用。通過(guò)注冊(cè)一個(gè)新的資源，你立即獲得（一些有限的）持久性，開箱即用的字段驗(yàn)證，RBAC，等等。然而，大多數(shù)情況下，自定義資源的創(chuàng)建伴隨著自定義控制器。

準(zhǔn)入鉤子（Webhooks）

回到請(qǐng)求處理……

Kubernetes控制器的超能力歸因于它們的異步特性，但這也是它們最大的局限性。對(duì)Kubernetes API的創(chuàng)建、修改或刪除對(duì)象的請(qǐng)求作為意圖的記錄工作——實(shí)際的處理邏輯被延遲到下一次控制循環(huán)迭代。但是如果需要同步請(qǐng)求處理呢？

這在Kubernetes也是可能的！但為此，你需要介入Kubernetes API服務(wù)器的資源請(qǐng)求處理。

當(dāng)請(qǐng)求到達(dá)API服務(wù)器時(shí)，在更改持久化到etcd（或類似的）之前，會(huì)經(jīng)過(guò)以下幾個(gè)階段：

• 身份驗(yàn)證和授權(quán)
• 準(zhǔn)入控制
• 對(duì)象模式驗(yàn)證
• 驗(yàn)證許可?

上面的大部分（或者全部？）階段都可以用自定義邏輯進(jìn)行擴(kuò)展！?

因此，配置一個(gè)許可webhook將使Kubernetes API服務(wù)器在實(shí)際持久化它之前，將資源實(shí)例（包裝在一個(gè)稱為AdmissionReview的信封中）發(fā)送到一個(gè)自定義HTTPS端點(diǎn)。

調(diào)用一個(gè)許可webhook端點(diǎn)會(huì)阻塞Kubernetes API服務(wù)器的請(qǐng)求處理。準(zhǔn)入webhook的實(shí)現(xiàn)可以執(zhí)行任意的驗(yàn)證邏輯，用非平凡的默認(rèn)值填充對(duì)象的屬性，對(duì)對(duì)象進(jìn)行標(biāo)簽或注釋，甚至修改其他Kubernetes資源或?qū)ν獠肯到y(tǒng)進(jìn)行更改！

一般來(lái)說(shuō)，應(yīng)該避免webhook處理程序中的副作用。在webhook中，不可能知道對(duì)象實(shí)際上是會(huì)被處理鏈持久化還是拒絕。如果對(duì)資源的操作被其中一個(gè)檢查拒絕，則需要以某種方式恢復(fù)前面步驟所做的任何更改。

因此，webhook是將同步請(qǐng)求處理程序綁定到Kubernetes API端點(diǎn)的一種簡(jiǎn)單方法。這就完成了Kubernetes API與任何其他傳統(tǒng)HTTP API在特性上的同一性。

總結(jié)

讓我們?cè)囍阉袞|西都放在一張圖上。下面是Kubernetes API擴(kuò)展工作流的描述：

希望大家現(xiàn)在已經(jīng)清楚，自定義控制器只是擴(kuò)展Kubernetes API這一更大任務(wù)的一部分。

我希望，在以上的解釋之后，你也注意到Kubernetes與我們都熟悉的老式技術(shù)沒有什么不同：

• Kubernetes自定義資源只是一種向API添加新的HTTP端點(diǎn)的方法。
• Kubernetes自定義控制器是一種將異步處理程序綁定到API端點(diǎn)的方法。
• Kubernetes Admission Webhooks是一種將同步處理程序綁定到相同API端點(diǎn)的方法。

所以，Kubernetes和Django并沒有太大的不同。

不過(guò)，認(rèn)真地說(shuō)，用熟悉的東西做類比通常能幫助我更快地理解新概念。但是，當(dāng)僅僅理解是不夠的，需要流利的表達(dá)時(shí)，練習(xí)通常會(huì)幫助我將概念內(nèi)化為真正的概念。然而，這是另一篇文章的主題。請(qǐng)繼續(xù)關(guān)注！