擴展 Kubernetes

變更 Kubernetes 叢集行為的不同方式。

Kubernetes 具有高度的可配置性與可擴充性。因此，幾乎不需要對 Kubernetes 專案程式碼進行分支 (fork) 或提交修補程式 (patch)。

本指南說明了自訂 Kubernetes 叢集的選項。它旨在幫助希望了解如何根據工作環境需求來調整 Kubernetes 叢集的叢集運營人員。對於未來的平台開發人員或 Kubernetes 專案貢獻者來說，這也是一份了解現有擴充點、擴充模式及其權衡與限制的實用簡介。

自訂方法大致可分為：配置，僅涉及變更命令列參數、本機設定檔或 API 資源；以及擴充，涉及執行額外的程式、額外的網路服務，或兩者兼具。本文件主要討論擴充。

配置

設定檔與命令參數在線上文件的參考章節中有詳細記載，且每個二進位檔案都有對應的頁面。

在代管的 Kubernetes 服務或具有受管安裝的發行版中，命令參數與設定檔可能無法變更。即使可以變更，通常也僅限叢集運營人員操作。此外，它們在未來的 Kubernetes 版本中可能會發生變化，且設定這些參數可能需要重新啟動處理程序。因此，僅在沒有其他選擇時，才建議使用這些方法。

內建的政策 API，例如 ResourceQuota、NetworkPolicy 與基於角色的存取控制 (RBAC)，是 Kubernetes 的內建 API，提供了宣告式的政策設定。這些 API 通常即使在代管服務與受管安裝中也能使用。內建政策 API 遵循與 Pod 等其他 Kubernetes 資源相同的慣例。當您使用穩定版本的政策 API 時，就像其他 Kubernetes API 一樣，您將受惠於明確的支援政策。基於這些原因，在適合的情況下，建議優先使用政策 API，而非設定檔與命令參數。

擴充 (Extensions)

擴充是與 Kubernetes 深度整合並進行延伸的軟體組件。它們能使 Kubernetes 適應並支援新型態的資源與硬體。

許多叢集管理員使用代管或特定發行版的 Kubernetes 執行個體，這些叢集通常已預先安裝了擴充功能。因此，大多數 Kubernetes 使用者不需要安裝擴充功能，僅極少數使用者需要自行開發。

擴充模式 (Extension patterns)

Kubernetes 的設計允許透過編寫客戶端程式來進行自動化。任何能讀取或寫入 Kubernetes API 的程式都能提供有用的自動化功能。自動化可以在叢集內或叢集外執行。遵循本文件中的指南，您可以編寫高可用性且穩固的自動化程式。自動化功能通常適用於任何 Kubernetes 叢集，包括代管叢集與受管安裝。

編寫能與 Kubernetes 良好協作的客戶端程式，有一種特定的模式稱為控制器模式。控制器通常會讀取物件的 .spec，執行相關操作，然後更新物件的 .status。

控制器是 Kubernetes API 的客戶端。當 Kubernetes 作為客戶端呼叫遠端服務時，Kubernetes 稱之為網頁鉤子 (webhook)。遠端服務則稱為網頁鉤子後端 (webhook backend)。與自訂控制器一樣，網頁鉤子會增加一個故障點。

注意

在 Kubernetes 之外，「webhook」通常是指一種非同步通知機制，webhook 呼叫僅作為單向通知發送給另一個系統或組件。在 Kubernetes 生態系統中，即使是同步的 HTTP 呼叫也經常被描述為「網頁鉤子」。

在網頁鉤子模型中，Kubernetes 會向遠端服務發出網路請求。而在另一種二進位外掛模型中，Kubernetes 會直接執行一個二進位檔案（程式）。Kubelet 使用二進位外掛（例如 CSI 儲存外掛 與 CNI 網路外掛），kubectl 亦有使用（請參閱使用外掛擴充 kubectl）。

擴充點 (Extension points)

此圖表顯示了 Kubernetes 叢集中的擴充點以及存取它的客戶端。

Symbolic representation of seven numbered extension points for Kubernetes

Kubernetes 擴充點

圖例

  1. 使用者通常使用 kubectl 與 Kubernetes API 互動。外掛可以自訂客戶端的行為。有通用的擴充功能可以應用於不同的客戶端，也有針對擴充 kubectl 的特定方式。

  2. API 伺服器負責處理所有請求。API 伺服器中的幾種擴充點允許對請求進行驗證、根據內容封鎖請求、編輯內容以及處理刪除操作。這些內容將在 API 存取擴充章節中說明。

  3. API 伺服器服務各種類型的資源。內建資源類型（例如 pods）由 Kubernetes 專案定義且不可更改。請閱讀 API 擴充以了解如何擴充 Kubernetes API。

  4. Kubernetes 排程器決定將 Pod 放置在哪些節點上。有幾種擴充排程的方法，將在排程擴充章節中說明。

  5. Kubernetes 的大部分行為是由稱為控制器的程式所實作，這些程式是 API 伺服器的客戶端。控制器通常與自訂資源結合使用。請閱讀結合新 API 與自動化以及變更內建資源以了解更多資訊。

  6. Kubelet 在伺服器（節點）上執行，並協助 Pod 在叢集網路上顯得像是具有專屬 IP 的虛擬伺服器。網路外掛允許不同的 Pod 網路實作。

  7. 您可以使用設備外掛來整合自訂硬體或其他特殊的節點本機設施，並使其可供叢集中執行的 Pod 使用。Kubelet 內建支援與設備外掛協作。

    Kubelet 也會為 Pod 及其容器掛載與卸載儲存卷。您可以使用儲存外掛來增加對新型態儲存與其他儲存卷類型的支援。

擴充點選擇流程圖

如果您不確定該從哪裡開始，此流程圖可以提供協助。請注意，某些解決方案可能涉及多種擴充類型。

Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no.

選擇擴充方法的流程圖指南

客戶端擴充 (Client extensions)

kubectl 的外掛是獨立的二進位檔案，用於新增或取代特定子指令的行為。kubectl 工具也可以與憑證外掛整合。這些擴充僅影響個別使用者的本機環境，因此無法強制執行站點範圍的政策。

如果您想擴充 kubectl 工具，請閱讀使用外掛擴充 kubectl。

API 擴充 (API extensions)

自訂資源定義 (Custom resource definitions)

如果您想定義新的控制器、應用程式配置物件或其他宣告式 API，並使用 kubectl 等 Kubernetes 工具來管理它們，請考慮在 Kubernetes 中新增一個自訂資源。

關於自訂資源的更多資訊，請參閱自訂資源概念指南。

API 聚合層 (API aggregation layer)

您可以使用 Kubernetes 的 API 聚合層將 Kubernetes API 與額外服務整合，例如用於指標的服務。

結合新 API 與自動化 (Combining new APIs with automation)

自訂資源 API 與控制迴圈的組合稱為控制器模式。如果您的控制器替代了人工運營人員根據預期狀態部署基礎設施，那麼該控制器可能也遵循了 Operator 模式。Operator 模式用於管理特定的應用程式；通常是那些維護狀態且需要妥善管理的應用程式。

您也可以建立自己的自訂 API 與控制迴圈來管理其他資源，例如儲存，或定義政策（例如存取控制限制）。

變更內建資源 (Changing built-in resources)

當您透過新增自訂資源來擴充 Kubernetes API 時，新增的資源總會歸入新的 API 群組中。您無法取代或變更現有的 API 群組。新增 API 並不能直接讓您影響現有 API（例如 Pod）的行為，但 API 存取擴充則可以。

API 存取擴充 (API access extensions)

當請求到達 Kubernetes API 伺服器時，它會先經過驗證 (authentication)，接著是授權 (authorization)，然後進入各種准入控制 (admission control)步驟（有些請求實際上未經過驗證並受到特殊處理）。有關此流程的詳細資訊，請參閱控制對 Kubernetes API 的存取。

Kubernetes 驗證/授權流程中的每個步驟都提供了擴充點。

驗證 (Authentication)

驗證會將所有請求中的標頭或憑證對映到發出請求的客戶端使用者名稱。

Kubernetes 支援多種內建驗證方法。如果這些方法無法滿足您的需求，它也可以放在驗證代理之後，並將 Authorization: 標頭中的權杖發送到遠端服務進行驗證（驗證網頁鉤子）。

授權

授權決定特定使用者是否可以讀取、寫入以及對 API 資源執行其他操作。它在整個資源層級運作——它不會根據任意物件欄位進行區分。

如果內建的授權選項無法滿足您的需求，授權網頁鉤子允許呼叫自訂程式碼來進行授權決策。

動態准入控制 (Dynamic admission control)

在請求獲得授權後，如果是寫入操作，它還會經歷准入控制步驟。除了內建步驟外，還有幾種擴充功能。

基礎設施擴充 (Infrastructure extensions)

設備外掛 (Device plugins)

設備外掛 (Device plugins) 允許節點透過設備外掛探索新的節點資源（除了 CPU 與記憶體等內建資源之外）。

儲存外掛 (Storage plugins)

容器儲存介面 (CSI) 外掛提供了一種透過支援新型態儲存卷來擴充 Kubernetes 的方法。這些儲存卷可以由持久化的外部儲存支援，或者提供臨時儲存，也可能使用檔案系統範例提供唯讀介面給資訊。

Kubernetes 也包含對 FlexVolume 外掛的支援，該外掛自 Kubernetes v1.23 起已被棄用（改以 CSI 為主）。

FlexVolume 外掛允許使用者掛載 Kubernetes 原生不支援的儲存卷類型。當您執行一個依賴 FlexVolume 儲存的 Pod 時，kubelet 會呼叫二進位外掛來掛載該儲存卷。已存檔的 FlexVolume 設計提案中有關於此方法的更多細節。

給儲存供應商的 Kubernetes 儲存卷外掛常見問題集包含了關於儲存外掛的一般資訊。

網路外掛 (Network plugins)

您的 Kubernetes 叢集需要一個網路外掛才能擁有可運作的 Pod 網路，並支援 Kubernetes 網路模型的其他層面。

網路外掛允許 Kubernetes 與不同的網路拓撲與技術協作。

Kubelet 映像檔憑證提供者外掛 (Kubelet image credential provider plugins)

功能狀態： Kubernetes v1.26 [穩定版]
Kubelet 映像檔憑證提供者是 kubelet 的外掛，用於動態擷取映像檔登錄 (registry) 的憑證。這些憑證會在從符合配置的容器映像檔登錄中拉取映像檔時使用。

外掛可以與外部服務通訊，或是使用本機檔案來取得憑證。如此一來，kubelet 無需為每個登錄保存靜態憑證，並可支援各種驗證方法與協定。

有關外掛配置的詳細資訊，請參閱配置 kubelet 映像檔憑證提供者。

排程擴充 (Scheduling extensions)

排程器是一種特殊的控制器，負責觀察 Pod 並將其指派給節點。可以完全替換預設排程器，同時繼續使用其他 Kubernetes 組件，或者同時執行多個排程器。

這是一個重大的工程，幾乎所有的 Kubernetes 使用者都不需要修改排程器。

您可以控制哪些排程外掛處於啟用狀態，或將一組外掛與不同的命名排程器設定檔 (scheduler profiles) 關聯。您也可以編寫自己的外掛，與 kube-scheduler 的一個或多個擴充點進行整合。

最後，內建的 kube-scheduler 組件支援一個網頁鉤子，允許遠端 HTTP 後端（排程器擴充）來篩選與/或對 kube-scheduler 為 Pod 選擇的節點進行優先順序排序。

注意

您只能透過排程器擴充網頁鉤子來影響節點篩選與節點優先順序排序；其他擴充點無法透過網頁鉤子整合。

接下來

  • 了解 kubectl 外掛
  • 進一步了解 自訂資源
  • 進一步了解 擴充 API 伺服器
  • 了解 動態准入控制
  • 了解 Operator 模式

    上次修改時間：太平洋標準時間 2026 年 4 月 14 日上午 1:15：fix(links): 更新 kubernetes/community 連結從 master 到 main (03c191bcc4)