本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.28：更安全叢集升級的新（alpha）機制

作者：Richa Banker (Google) |

本部落格說明混合版本代理，這是 Kubernetes 1.28 中的一項新的 alpha 功能。混合版本代理讓資源的 HTTP 請求能夠由正確的 API 伺服器提供服務，適用於叢集中存在多個不同版本的 API 伺服器的情況。例如，這在叢集升級期間，或當您推出叢集控制平面的執行階段組態時非常有用。

這解決了什麼問題？

當叢集進行升級時，在該情境中以不同版本存在的 kube-apiservers 可以提供不同集合（群組、版本、資源）的內建資源。在此情境中提出的資源請求可能會由任何可用的 apiservers 提供服務，這可能會導致請求最終到達可能不知道所請求資源的 apiserver；因此，它會收到不正確的 404 找不到錯誤。此外，不正確地提供 404 錯誤可能會導致嚴重的後果，例如命名空間刪除被不正確地封鎖，或物件被錯誤地垃圾回收。

我們如何解決這個問題？

新功能「混合版本代理」為 kube-apiserver 提供將請求代理到知道所請求資源的對等 kube-apiserver 的能力，因此可以為請求提供服務。為此，已在 API 伺服器的聚合層中的處理程序鏈中新增了一個新的篩選器。

  1. 處理程序鏈中的新篩選器會檢查請求是否針對 apiserver 不知道的群組/版本/資源（使用現有的 StorageVersion API）。如果是，它會將請求代理到 ServerStorageVersion 物件中列出的其中一個 apiservers。如果已識別的對等 apiserver 無法回應（由於網路連線能力、請求被接收與控制器在 ServerStorageVersion 物件中註冊 apiserver 資源資訊之間的競爭等原因），則會提供錯誤 503（「服務不可用」）。
  2. 為了防止無限期地代理請求，一旦確定原始 API 伺服器無法處理請求，就會在原始請求中新增一個（v1.28 版本的新）HTTP 標頭 X-Kubernetes-APIServer-Rerouted: true。將其設定為 true 表示原始 API 伺服器無法處理請求，因此應進行代理。如果目標對等 API 伺服器看到此標頭，則永遠不會進一步代理請求。
  3. 若要設定對等節點將用於代理請求的 kube-apiserver 網路位置，將使用在 --advertise-address 中傳遞的值，或者（當 --advertise-address 未指定時）使用 --bind-address 旗標。對於網路組態不允許對等 kube-apiservers 使用這些旗標中指定的位址進行通訊的使用者，可以選擇傳遞正確的對等位址作為此功能中引入的 --peer-advertise-ip 和 --peer-advertise-port 旗標。

我該如何啟用此功能？

以下是啟用此功能所需的步驟

  • 下載最新的 Kubernetes 專案（版本 v1.28.0 或更新版本）
  • 在 kube-apiservers 上使用命令列旗標 --feature-gates=UnknownVersionInteroperabilityProxy=true 開啟功能閘道
  • 在 kube-apiservers 上使用旗標 --peer-ca-file 傳遞來源 kube-apiserver 將用於驗證目標 kube-apiserver 的伺服器憑證的 CA 憑證包。注意：這是此功能運作的必要旗標。此旗標沒有啟用的預設值。
  • 傳遞本地 kube-apiserver 的正確 IP 和連接埠，對等節點在代理請求時將使用這些 IP 和連接埠連線到此 kube-apiserver。在啟動時對 kube-apiservers 使用旗標 --peer-advertise-ip 和 peer-advertise-port。如果未設定，將使用傳遞給 --advertise-address 或 --bind-address 的值。如果這些也未設定，則將使用主機的預設介面。

缺少什麼？

目前，我們僅在確定要這樣做時才將資源請求代理到對等 kube-apiserver。接下來，我們需要解決如何在這種情況下處理探索請求。目前，我們計劃為 beta 版本提供以下功能

  • 跨所有 kube-apiservers 的合併探索
  • 對與對等 kube-apiservers 建立的網路連線使用出口撥號器

我如何能瞭解更多資訊？

我如何參與其中？

在 Slack 上與我們聯絡：#sig-api-machinery，或透過電郵列表。

非常感謝協助設計、實作和審查此功能的貢獻者：Daniel Smith、Han Kang、Joe Betz、Jordan Liggit、Antonio Ojea、David Eads 和 Ben Luddy！