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

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

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

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

自定義控制器

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

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

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

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

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

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

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

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

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

自定義資源

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

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

• 第一種類型是服務(wù)于Kubernetes對象集合（即持久的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ù)于用戶定義對象類型的新端點(diǎn)添加到API中呢？

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

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

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

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

回到請求處理……

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

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

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

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

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

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

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

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

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

總結(jié)

讓我們試著把所有東西都放在一張圖上。下面是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并沒有太大的不同。

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