混合版本代理
Kubernetes v1.28 [alpha]
(預設啟用:false)Kubernetes 1.34 包含一個 Alpha 功能,它允許 API 伺服器 將資源請求代理到其他_對等_ API 伺服器。當單個叢集中執行多個不同版本 Kubernetes 的 API 伺服器時(例如,在新版本 Kubernetes 的長期滾動升級期間),此功能非常有用。
這使得叢集管理員能夠透過在升級期間將資源請求定向到正確的 kube-apiserver,從而配置更安全地升級的高可用叢集。這種代理可以防止使用者看到因升級過程引起的意外的 404 Not Found 錯誤。
此機制稱為_混合版本代理_。
啟用混合版本代理
確保在啟動 API 伺服器 時啟用了 UnknownVersionInteroperabilityProxy
功能門。
kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# required command line arguments for this feature
--peer-ca-file=<path to kube-apiserver CA cert>
--proxy-client-cert-file=<path to aggregator proxy cert>,
--proxy-client-key-file=<path to aggregator proxy key>,
--requestheader-client-ca-file=<path to aggregator CA cert>,
# requestheader-allowed-names can be set to blank to allow any Common Name
--requestheader-allowed-names=<valid Common Names to verify proxy client cert against>,
# optional flags for this feature
--peer-advertise-ip=`IP of this kube-apiserver that should be used by peers to proxy requests`
--peer-advertise-port=`port of this kube-apiserver that should be used by peers to proxy requests`
# …and other flags as usual
API 伺服器之間的代理傳輸和身份驗證
源 kube-apiserver 重用現有的 API 伺服器客戶端身份驗證標誌
--proxy-client-cert-file
和--proxy-client-key-file
來提供其身份,該身份將由其對等方(目標 kube-apiserver)驗證。目標 API 伺服器根據您使用--requestheader-client-ca-file
命令列引數指定的配置來驗證對等連線。為了驗證目標伺服器的服務證書,您必須透過向**源** API 伺服器指定
--peer-ca-file
命令列引數來配置證書頒發機構包。
對等 API 伺服器連線配置
要設定對等方將用於代理請求的 kube-apiserver 的網路位置,請使用 --peer-advertise-ip
和 --peer-advertise-port
命令列引數來 kube-apiserver 或在 API 伺服器配置檔案中指定這些欄位。如果未指定這些標誌,對等方將使用 --advertise-address
或 --bind-address
命令列引數的值。如果這些也未設定,則使用主機的預設介面。
混合版本代理
當您啟用混合版本代理時,聚合層 會載入一個特殊過濾器,該過濾器執行以下操作:
- 當資源請求到達一個無法提供該 API 的 API 伺服器時(可能是因為該 API 伺服器的版本早於該 API 的引入,或者該 API 在該 API 伺服器上已關閉),該 API 伺服器會嘗試將請求傳送到可以提供所請求 API 的對等 API 伺服器。它透過識別本地伺服器無法識別的 API 組/版本/資源來做到這一點,並嘗試將這些請求代理到能夠處理該請求的對等 API 伺服器。
- 如果對等 API 伺服器未能響應,則_源_ API 伺服器將響應 503 (“Service Unavailable”) 錯誤。
它如何工作
當 API 伺服器收到資源請求時,它首先檢查哪些 API 伺服器可以提供所請求的資源。此檢查是使用內部 StorageVersion
API 進行的。
如果接收請求的 API 伺服器知道該資源(例如,
GET /api/v1/pods/some-pod
),則該請求將在本地處理。如果找不到所請求資源的內部
StorageVersion
物件(例如,GET /my-api/v1/my-resource
),並且配置的 APIService 指定代理到擴充套件 API 伺服器,則該代理會按照擴充套件 API 的常規流程進行。如果找到所請求資源的有效內部
StorageVersion
物件(例如,GET /batch/v1/jobs
),並且嘗試處理請求的 API 伺服器(_處理 API 伺服器_)停用了batch
API,那麼_處理 API 伺服器_將使用從獲取的StorageVersion
物件中的資訊,獲取提供相關 API 組/版本/資源(在此例中為api/v1/batch
)的對等 API 伺服器。然後,_處理 API 伺服器_將請求代理到其中一個知道所請求資源的匹配對等 kube-apiserver。如果該 API 組/版本/資源沒有已知的對等方,則處理 API 伺服器將請求傳遞給其自己的處理程式鏈,該處理程式鏈最終應返回 404 ("Not Found") 響應。
如果處理 API 伺服器已識別並選擇了對等 API 伺服器,但該對等伺服器未能響應(由於網路連線問題,或請求被接收與控制器將對等伺服器資訊註冊到控制平面之間的資料競爭等原因),則處理 API 伺服器將響應 503 ("Service Unavailable") 錯誤。