最新消息:在TwitterMastodon取得專案更新

cert-manager 功能閘道

從 v1 版本開始,cert-manager 被認為是穩定的。我們的目標是在進行 API 變更時遵循 Kubernetes API 相容性原則,請參閱API 相容性,以避免破壞使用者現有的 cert-manager 安裝。這表示身為開發人員,我們在變更現有行為方面受到一些限制,例如重新命名或移除 API 元素,或變更其行為。

尚未穩定的新功能1仍然可以新增,但需要放在功能閘道後面。

啟用/停用功能閘道

可以使用 CLI 標籤或設定檔啟用或停用功能閘道,更多資訊請參閱設定元件

功能閘道 API 欄位

功能閘道 API 欄位是使用 cert-manager 的 --feature-gates 標籤實作的,適用於 webhookcainjectorcontroller

功能閘道 API 欄位對使用者始終可見(即執行 kubectl explain <some-resource> 時),但只有在 webhook 和控制器都透過功能標籤明確啟用相關功能時才有效。

如果使用者嘗試套用資源,其中功能閘道欄位設定為非空值,但該功能閘道未啟用,則該資源將被 webhook 驗證拒絕。此機制與 Kubernetes 用於實作功能閘道 API 欄位的機制不同,在 Kubernetes 中,如果功能閘道停用,該欄位將被簡單地設定為空值。我們選擇改用 webhook 驗證,以便更容易讓嘗試使用功能閘道欄位但忘記啟用該功能閘道的使用者進行偵錯。

實作方式

  • 實作新的欄位,並記錄它是功能閘道的,為了使用它,需要啟用控制器和 webhook 的功能閘道
  • 為該欄位新增一個 webhook 功能閘道
  • 更新相關資源種類的 webhook 驗證檢查,以確保如果設定了功能閘道欄位,但 webhook 功能閘道未啟用,則拒絕該資源
  • 為該欄位新增一個 控制器功能閘道
  • 確保任何使用該功能的控制迴圈都會檢查該功能閘道是否已實際啟用。(這是為了涵蓋邊緣案例,例如如果 webhook 執行的是 cert-manager 的某個版本,其中該功能處於 GA 狀態,而控制器執行的是較舊的版本,其中該功能仍處於實驗狀態)
  • 確保將該功能閘道添加到 CI 和本地測試的 cert-manager 安裝腳本中,位於 makebash 腳本中
  • 預設 cert-manger e2e CI 測試會啟用所有元件的所有功能閘道。還有一個額外的可選 e2e 測試會在停用所有功能閘道的情況下執行。您可以使用 /test pull-cert-manager-e2e-feature-gates-disabled 為您的 PR 觸發該測試,以驗證啟用和未啟用新功能閘道時是否都如預期般運作。

潛在問題

  • 部署 cert-manager 的人必須記得設定兩個 cert-manager 功能閘道,一個是 webhook,一個是控制器的,這樣該功能才能運作。忘記設定其中一個可能會導致非預期的行為

  • 當停用先前啟用的 API 功能時,使用者必須記得從其清單中移除 alpha 欄位。若未這樣做可能會導致非預期的行為,例如忘記從 Certificate 資源中移除功能閘道欄位可能會導致稍後 cert-manager 的控制器嘗試更新 Certificate 規格時,因該功能閘道欄位已設定而被 webhook 拒絕更新,導致續訂失敗。

參考資料

註腳

  1. 例如,未來可能會根據使用者回饋而變更的功能