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

Kubernetes 1.28：一種新的（Alpha）機制，用於更安全的叢集升級

作者：Richa Banker (Google) |

這篇部落格介紹了 Kubernetes 1.28 中的一個新 Alpha 特性——**混合版本代理**（mixed version proxy）。混合版本代理使得在叢集中存在多個不同版本的 API 伺服器時，針對某個資源的 HTTP 請求能夠被正確的 API 伺服器處理。例如，這在叢集升級或滾動更新叢集控制平面的執行時配置時非常有用。

這解決了什麼問題？

當叢集進行升級時，該場景下不同版本的 kube-apiserver 可能會提供不同集合（組、版本、資源）的內建資源。在這種情況下發出的資源請求可能會被任何一個可用的 apiserver 處理，這可能導致請求最終被一個不瞭解所請求資源的 apiserver 處理；因此，請求會收到一個不正確的 404 not found 錯誤。此外，不正確地處理 404 錯誤可能會導致嚴重的後果，例如名稱空間刪除被錯誤地阻止或物件被錯誤地垃圾回收。

我們如何解決這個問題？

新的特性“混合版本代理”為 kube-apiserver 提供了將請求代理到能夠識別所請求資源並因此能夠處理該請求的對等 kube-apiserver 的能力。為此，在 API 伺服器的聚合層的處理鏈中增加了一個新的過濾器。

  1. 處理鏈中的新過濾器會檢查請求是否針對一個 apiserver 不知道的組/版本/資源（使用現有的 StorageVersion API）。如果是，它會將請求代理到 ServerStorageVersion 物件中列出的某個 apiserver。如果識別出的對等 apiserver 未能響應（由於網路連線、請求接收與控制器在 ServerStorageVersion 物件中註冊 apiserver-資源資訊之間的競爭等原因），則會返回 503（“Service Unavailable”）錯誤。
  2. 為了防止請求被無限期地代理，一旦確定原始 API 伺服器無法處理請求，就會向原始請求新增一個（v1.28 新增的）HTTP 頭 X-Kubernetes-APIServer-Rerouted: true。將其設定為 true 標誌著原始 API 伺服器無法處理該請求，因此應將其代理出去。如果目標對等 API 伺服器看到這個頭，它將永遠不會再進一步代理該請求。
  3. 為了設定一個 kube-apiserver 的網路位置，以便對等方用它來代理請求，系統會使用 --advertise-address 中傳入的值，或者（當 --advertise-address 未指定時）使用 --bind-address 標誌的值。對於某些網路配置不允許對等 kube-apiserver 之間使用這些標誌指定的地址進行通訊的使用者，可以選擇透過 --peer-advertise-ip 和 --peer-advertise-port 標誌傳入正確的對等地址，這些標誌是此特性中引入的。

我如何啟用這個特性？

以下是啟用此特性所需的步驟：

  • 下載最新的 Kubernetes 專案（版本為 v1.28.0 或更高）
  • 在 kube-apiserver 上使用命令列標誌 --feature-gates=UnknownVersionInteroperabilityProxy=true 開啟特性門控
  • 在 kube-apiserver 上使用標誌 --peer-ca-file 傳遞 CA 捆綁包，源 kube-apiserver 將使用它來驗證目標 kube-apiserver 的服務證書。注意：這是此特性工作的必需標誌。此標誌沒有預設值。
  • 在啟動時，向 kube-apiserver 傳入正確的本地 kube-apiserver 的 IP 和埠，對等方在代理請求時將使用這些資訊連線到此 kube-apiserver。使用 --peer-advertise-ip 和 peer-advertise-port 標誌。如果未設定，則使用傳遞給 --advertise-address 或 --bind-address 的值。如果這些也未設定，將使用主機的預設介面。

還缺少什麼？

目前，我們只在確定需要時將資源請求代理到對等的 kube-apiserver。接下來，我們需要解決如何處理發現（discovery）請求在這種場景下的問題。目前我們計劃為 Beta 版本實現以下功能：

  • 合併所有 kube-apiserver 的發現資訊
  • 使用 egress dialer 與對等 kube-apiserver 建立網路連線

我如何瞭解更多資訊？

我如何參與？

透過 Slack 上的 #sig-api-machinery 頻道或郵件列表與我們聯絡。

非常感謝為該特性的設計、實現和審查做出貢獻的人員：Daniel Smith, Han Kang, Joe Betz, Jordan Liggit, Antonio Ojea, David Eads 和 Ben Luddy！