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

Kubernetes 1.22 中的 API 和特性移除：你需要知道什麼

作者：Krishna Kilari (Amazon Web Services), Tim Bannister (The Scale Factory) |

隨著 Kubernetes API 的發展，API 會定期重組或升級。當 API 演進時，它們替換的舊 API 會被棄用，並最終被移除。請參閱Kubernetes API 移除以瞭解更多關於 Kubernetes 移除 API 的策略。

我們想確保您瞭解一些即將進行的移除。這些是您可以在當前支援的 Kubernetes 版本中使用的 Beta API，並且它們已經被棄用。所有這些移除的原因是它們已被更新的穩定（“GA”）API 取代。

Kubernetes 1.22（計劃於 2021 年 8 月釋出）將移除許多已棄用的 API。更新：Kubernetes 1.22：邁向新高峰包含 v1.22 釋出的詳細資訊。

Kubernetes v1.22 的 API 移除

v1.22 版本將停止提供我們下面立即列出的 API 版本。這些都是 Beta API，之前已被棄用，取而代之的是更新、更穩定的 API 版本。

  • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration API 的 Beta 版本（admissionregistration.k8s.io/v1beta1 API 版本）
  • Beta CustomResourceDefinition API（apiextensions.k8s.io/v1beta1）
  • Beta APIService API（apiregistration.k8s.io/v1beta1）
  • Beta TokenReview API（authentication.k8s.io/v1beta1）
  • SubjectAccessReview、LocalSubjectAccessReview、SelfSubjectAccessReview 的 Beta API 版本（來自 authorization.k8s.io/v1beta1 的 API 版本）
  • Beta CertificateSigningRequest API（certificates.k8s.io/v1beta1）
  • Beta Lease API（coordination.k8s.io/v1beta1）
  • 所有 Beta Ingress API（extensions/v1beta1 和 networking.k8s.io/v1beta1 API 版本）

Kubernetes 文件涵蓋了這些v1.22 的 API 移除，並解釋了每個 API 在 Beta 和穩定版本之間如何變化。

如何應對

我們將逐一介紹受這些移除影響的資源，並解釋您需要採取的步驟。

Ingress
遷移到使用 networking.k8s.io/v1 Ingress API，該 API 自 v1.19 起可用。
相關的 API IngressClass 旨在補充 Ingress 概念，允許您在單個叢集中配置多種 Ingress。如果您目前使用的是已棄用的 kubernetes.io/ingress.class 註解，請計劃改用 .spec.ingressClassName 欄位。
在執行 Kubernetes v1.19 或更高版本的任何叢集上，您可以使用 v1 API 檢索或更新現有 Ingress 物件，即使它們是使用舊版 API 建立的。

將 Ingress 轉換為 v1 API 時，您應該審查該 Ingress 中的每條規則。舊版 Ingress 使用傳統的 ImplementationSpecific 路徑型別。 вместо ImplementationSpecific，請將路徑匹配切換為 Prefix 或 Exact。切換到這些替代路徑型別的好處之一是，它使在不同 Ingress 類之間遷移變得更容易。

ⓘ 除了升級您自己作為客戶端對 Ingress API 的使用之外，還要確保您使用的每個 Ingress 控制器都與 v1 Ingress API 相容。閱讀Ingress 前提條件以獲取有關 Ingress 和 Ingress 控制器的更多上下文。

ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration
遷移到使用 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 admissionregistration.k8s.io/v1 API 版本，該 API 自 v1.16 起可用。
您可以使用 v1 API 檢索或更新現有物件，即使它們是使用舊版 API 建立的。
CustomResourceDefinition
遷移到使用 CustomResourceDefinition apiextensions.k8s.io/v1 API，該 API 自 v1.16 起可用。
您可以使用 v1 API 檢索或更新現有物件，即使它們是使用舊版 API 建立的。如果您在叢集中定義了任何自定義資源，則在升級後這些資源仍將可用。

如果您正在使用外部 CustomResourceDefinitions，可以使用kubectl convert將現有清單轉換為使用更新的 API。由於 Beta 和穩定版 CustomResourceDefinitions 之間存在一些功能差異，我們建議您在升級後測試每個自定義資源，以確保它按預期工作。

APIService
遷移到使用 apiregistration.k8s.io/v1 APIService API，該 API 自 v1.10 起可用。
您可以使用 v1 API 檢索或更新現有物件，即使它們是使用舊版 API 建立的。如果您已經使用 APIService 物件進行了 API 聚合，則在升級後此聚合將繼續工作。
TokenReview
遷移到使用 authentication.k8s.io/v1 TokenReview API，該 API 自 v1.10 起可用。

除了透過 HTTP 提供此 API 之外，Kubernetes API 伺服器還使用相同的格式將 TokenReviews 傳送到 webhook。v1.22 版本預設繼續使用 v1beta1 API 將 TokenReviews 傳送到 webhook。請參閱展望未來，瞭解一些關於切換到穩定 API 的具體提示。

SubjectAccessReview、SelfSubjectAccessReview 和 LocalSubjectAccessReview
遷移到使用這些授權 API 的 authorization.k8s.io/v1 版本，該 API 自 v1.6 起可用。
CertificateSigningRequest
遷移到使用 certificates.k8s.io/v1 CertificateSigningRequest API，該 API 自 v1.19 起可用。
您可以使用 v1 API 檢索或更新現有物件，即使它們是使用舊版 API 建立的。升級後，現有已頒發證書的有效期將保持不變。
Lease
遷移到使用 coordination.k8s.io/v1 Lease API，該 API 自 v1.14 起可用。
您可以使用 v1 API 檢索或更新現有物件，即使它們是使用舊版 API 建立的。

kubectl convert

有一個 kubectl 外掛提供 kubectl convert 子命令。它是一個官方外掛，您可以作為 Kubernetes 的一部分下載。有關詳細資訊，請參閱下載 Kubernetes。

您可以使用 kubectl convert 更新清單檔案以使用不同的 API 版本。例如，如果您在原始碼控制中有一個使用 Beta Ingress API 的清單，您可以檢出該定義，並執行 kubectl convert -f <manifest> --output-version <group>/<version>。您可以使用 kubectl convert 命令自動轉換現有清單。

例如，要將舊的 Ingress 定義轉換為 networking.k8s.io/v1，您可以執行

kubectl convert -f ./legacy-ingress.yaml --output-version networking.k8s.io/v1

自動轉換使用與 Kubernetes 控制平面更新最初使用舊 API 版本建立的物件類似的技術。由於它是機械轉換，您可能需要手動更改清單以調整預設值等。

為升級進行演練

如果您管理叢集的 API 伺服器元件，您可以在升級到 Kubernetes v1.22 之前嘗試這些 API 移除。

為此，請將以下內容新增到 kube-apiserver 命令列引數中

--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k8s.io/v1beta1=false,certificates.k8s.io/v1beta1=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false

（作為副作用，這也會關閉 EndpointSlice 的 v1beta1 - 在測試時請注意這一點）。

一旦您將叢集中所有 kube-apiserver 切換為使用該設定，這些 Beta API 將被移除。您可以測試 API 客戶端（kubectl、部署工具、自定義控制器等）是否仍按預期工作，並且如果需要，您可以恢復而無需計劃更具破壞性的降級。

對軟體開發者的建議

也許您正在閱讀本文，因為您是與 Kubernetes 整合的外掛或其他元件的開發人員？

如果您開發 Ingress 控制器、Webhook 身份驗證器、API 聚合或任何依賴這些已棄用 API 的其他工具，您應該已經開始切換您的軟體。

您可以使用為升級進行演練中的提示來執行您自己的只使用新 API 的 Kubernetes 叢集，並確保您的程式碼正常工作。對於您的文件，請確保讀者瞭解他們在 Kubernetes v1.22 升級時應採取的任何步驟。

在可能的情況下，幫助您的使用者儘早採用新的 API——也許在測試環境中——這樣他們就可以向您提供有關任何問題的反饋。

Kubernetes v1.25 中還有一些更多的棄用，所以請計劃好也要涵蓋這些。

Kubernetes API 移除

以下是關於 Kubernetes 為什麼要移除某些 API 的一些背景資訊，以及關於 Kubernetes 中穩定API 的承諾。

Kubernetes 遵循其功能的棄用策略，包括 Kubernetes API。該策略允許替換 Kubernetes 中的穩定 (“GA”) API。重要的是，此策略意味著只有當同一 API 的較新穩定版本可用時，穩定 API 才會被棄用。

這種穩定性保證很重要：如果您正在使用穩定的 Kubernetes API，則永遠不會發布強制您切換到 Alpha 或 Beta 功能的新版本。

早期階段則不同。Alpha 功能正在測試中，可能不完整。幾乎總是，Alpha 功能預設是停用的。Kubernetes 版本可以並且確實會移除未成功的 Alpha 功能。

在 Alpha 之後是 Beta。這些功能通常預設啟用；如果測試成功，該功能可以升級到穩定版。如果失敗，可能需要重新設計。

去年，Kubernetes 正式採納了針對已達到 Beta 階段的 API 的策略

對於 Kubernetes REST API，當新功能的 API 達到 Beta 階段時，就會開始倒計時。這個 Beta 質量的 API 現在有三個版本……要不

  • 達到 GA，並棄用 Beta 版，或者
  • 推出新的 Beta 版（並棄用之前的 Beta 版）。

在那篇文章釋出時，三個 Kubernetes 版本大約相當於九個日曆月。同月晚些時候，Kubernetes 採用了每年釋出三個版本的新發布節奏，因此倒計時週期現在大約是十二個日曆月。

無論 API 移除是因為 Beta 功能升級到穩定版，還是因為該 API 未能成功，Kubernetes 都將繼續遵循其棄用策略移除 API，並確保遷移選項已記錄在案。

展望未來

如果您使用 webhook 身份驗證檢查，則有一個相關的設定。未來的 Kubernetes 版本將預設切換為使用 authentication.k8s.io/v1 API 將 TokenReview 物件傳送到 webhook。目前，預設是將 authentication.k8s.io/v1beta1 TokenReviews 傳送到 webhook，並且這仍然是 Kubernetes v1.22 的預設設定。但是，如果您願意，現在就可以切換到穩定 API：將 --authentication-token-webhook-version=v1 新增到 kube-apiserver 的命令列選項中，並檢查用於身份驗證的 webhook 是否仍按預期工作。

一旦您滿意它正常工作，您就可以在您的控制平面中保留 --authentication-token-webhook-version=v1 選項。

計劃於明年釋出的 v1.25 版本將停止提供幾個目前已經穩定一段時間的 Kubernetes API 的 Beta 版本。相同的 v1.25 版本將移除 PodSecurityPolicy，該策略已被棄用，並且不會升級到穩定版。有關更多資訊，請參閱PodSecurityPolicy 棄用：過去、現在和未來。

Kubernetes 1.25 計劃的官方API 移除列表是

  • Beta CronJob API（batch/v1beta1）
  • Beta EndpointSlice API（networking.k8s.io/v1beta1）
  • Beta PodDisruptionBudget API（policy/v1beta1）
  • Beta PodSecurityPolicy API（policy/v1beta1）

想了解更多嗎？

棄用會在 Kubernetes 釋出說明中宣佈。您可以在 1.19、1.20 和 1.21 的釋出說明中檢視待棄用功能的公告。

有關棄用和移除過程的資訊，請檢視官方的 Kubernetes 棄用策略文件。