隨著新功能和功能的增加，舊的API被棄用并最終移除。雖然這是Kubernetes發(fā)展的必要部分，但對于依賴該平臺運行應用程序的組織來說，這可能會帶來挑戰(zhàn)。

Kubernetes API作為與K8集群交互的接口。如果集群中仍在使用已棄用的API，可能會導致中斷不可用。

在這篇博客文章中，我們將探討被棄用的Kubernetes API是什么，它們?yōu)槭裁粗匾约叭绾斡行У毓芾硭鼈儭?/p>

我們還將介紹一些用于處理 Kubernetes 中廢棄 API 的可用工具，并提供管理廢棄 API 的最佳實踐。

在閱讀完本文之后，您將更好地了解如何處理Kubernetes集群升級，并對您的基礎設施充滿信心。

API生命周期

Kubernetes遵循alpha → beta → stable的成熟度進展，并且還有一些額外的版本控制，這樣資源可以在不需要進入下一個成熟度級別的情況下進行迭代。

一個alpha資源可以從v1alpha1開始，并且可以通過v1alpha2進行迭代，或者如果有破壞性的變化，可能會使用v2alpha1。一個beta API可能與alpha API具有相同的規(guī)范，但是成熟度和與用戶的約定將會有所不同。

• Alpha API是實驗性的。它們可能存在錯誤和不兼容的更改。它們不是默認啟用的，您應該謹慎使用。
• Beta API經過充分測試，并默認啟用。它們可以被依賴于未來的功能，但其實現(xiàn)可能會根據(jù)用戶反饋或可擴展性等約束而發(fā)生變化。
• 穩(wěn)定的API不會有“beta”或“alpha”名稱。它們用版本號表示（例如，v1），其實現(xiàn)不應該在不更改版本號的情況下進行破壞性更改。

我提到的生命周期如下所示：

• 如果一個API同時存在多個版本，Kubernetes API 可能會自動為您升級其中一些版本。然而，您仍應確保您擁有正確的資源方案，特別是因為隨著 alpha API 的成熟，方案可能會在不同版本之間發(fā)生變化。
• 如果一個API同時有多個版本可用，Kubernetes API可以為您悄悄地升級其中一些版本。然而，您仍應確保您擁有正確的資源方案，特別是因為隨著alpha API的成熟，方案可能會在不同版本之間發(fā)生變化。

您可以在這里查看k8s API概述，例如，部署屬于應用程序組，并具有v1版本。

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/

可以列出它們：

/apis/apps/v1/namespaces/{namespace}/deployments

淘汰和移除Kubernetes API

如果您正在運行過時的Kubernetes API版本，那么您的應用程序就面臨著可能導致大量停機時間的風險。即使升級不會導致停機，Kubernetes API的微小差異也可能導致煩惱和浪費精力去調查潛在問題。

在這個場景中，棄用意味著確定一個 API 組件最終會被移除。雖然它目前仍在運行，但計劃在即將發(fā)布的版本中被淘汰。Kubernetes 遵循明確定義的棄用政策，通知用戶哪些 API 將被移除或修改。

Kubernetes API作為與Kubernetes集群交互的接口，允許用戶查詢和操作各種Kubernetes對象，如pod、命名空間和部署。這些API可以通過諸如kubectl之類的工具、直接通過REST API，或者使用客戶端庫來訪問。隨著Kubernetes的發(fā)展，舊的API被標記為棄用，并最終被淘汰。這凸顯了用戶或維護者需要意識到棄用的Kubernetes API的重要性。

棄用的Kubernetes API 的關注點

在配置Kubernetes中的應用程序時，用戶需要在YAML清單或Helm圖表中的apiVersion字段中指定所使用的Kubernetes對象的API版本，這是一個關鍵的方面。這強調了用戶和維護人員需要及時了解已棄用的Kubernetes API版本及其在即將發(fā)布的版本中計劃移除的重要性。

在 Kubernetes 集群升級過程中，遇到廢棄的 API 可能會成為一個潛在問題，特別是如果升級后的版本不再支持這些 API。例如，如果您集群中的資源使用了過時的 API 版本，那么依賴該資源的應用程序可能因為新集群版本中廢棄的 API 而無法正常運行。這種情況可能導致顯著的停機時間，就像 Reddit 的全站宕機一樣。

一個具體的案例是在Kubernetes版本v1.22中移除了Ingress資源的APIVersion extensions/v1beta1。在您的配置中嘗試使用已移除的API版本將導致錯誤消息。

Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Ingress" in version "extensions/v1beta1"

K8s APIs的使用方式

要在您的配置中指定特定的API版本，請參考下面的示例，該示例摘自Kubernetes文檔：

apiVersion: apps/v1     <------ API Version of the kubernetes objectapiVersion: apps/v1     <------ API Version of the kubernetes object
   kind: Deployment
  metadata:
    name: nginx

您可以通過官方文檔或使用kubectl命令行工具的api-versions命令來查看所有支持的API組及其版本。

kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1

識別棄用的API所面臨的挑戰(zhàn)

識別集群中利用已棄用API的資源可能會相當具有挑戰(zhàn)性。此外，Kubernetes遵循嚴格的API版本控制協(xié)議，導致在多個發(fā)布版本中多次棄用v1beta1和v2beta1的API。

他們的政策規(guī)定，Beta API 版本在棄用后必須至少獲得 9 個月或 3 個發(fā)布版本（以較長者為準）的支持，之后可能會被移除。

在一些情況下，如果被棄用的API仍然被工作負載、工具或其他與集群接口的組件所積極使用，可能會導致中斷發(fā)生。

因此，用戶和管理員必須對其集群進行徹底評估，以確定任何即將移除的正在使用的API，并隨后遷移受影響的組件，以利用適當?shù)男翧PI版本。

管理棄用的Kubernetes API 的工具

解決處理過時的Kubernetes API 問題，可以采用幾種工具：

工具1：FairwindsOps的Pluto — 自動化檢測和GitHub集成

FairwindsOps推出了Pluto，這是一個自動化解決方案，用于檢測代碼存儲庫和Helm發(fā)布中已棄用的Kubernetes API。通過無縫集成GitHub工作流程，Pluto確保持續(xù)監(jiān)控，及時識別已棄用的API，并進行積極的管理。

工具2：Kube No Trouble (kubent) by doitintl — 全面的集群范圍檢查

由doitintl開發(fā)，Kube No Trouble (kubent) 專注于對過時API的全面集群級檢查，重點關注部署以進行檢測。該工具需要存儲原始清單，提供了一個全面的解決方案，用于識別和解決Kubernetes集群中的過時API。

工具3：Helm MapkubeAPIs插件 — 基于圖表的API識別

The Helm MapkubeAPIs Plugin是一個有價值的工具，用于識別在集群上安裝的Helm charts中已棄用的API。該插件提供了一種有針對性的方法來管理API的棄用，確保在升級過程中兼容性和平穩(wěn)過渡。

工具 4：Plural CD — 多功能 API 管理

Plural CD，可全面管理已棄用的Kubernetes API。其多方面的能力有助于在Kubernetes升級期間實現(xiàn)更順暢的過渡，使其成為識別和有效處理已棄用API的重要組成部分。

這些工具共同幫助用戶主動識別和解決已棄用的API，最大限度地減少在Kubernetes升級過程中可能出現(xiàn)的問題。通過將這些工具無縫地整合到您的工作流程中，您可以確保平穩(wěn)過渡到更新的API版本，提高Kubernetes基礎架構的整體穩(wěn)定性和可靠性。

結論

Kubernetes API被設計為靈活且經常變化，這是其核心優(yōu)勢之一。

用戶必須知道他們的資源正在使用哪些組和版本，以確保與當前的Kubernetes API兼容。資源通常可以在沒有用戶操作的情況下被修改并存儲為更新的資源，從而實現(xiàn)逐步的模式更改，并增強對API升級的信心。

重要的是通過工具靜態(tài)驗證資源或使用轉換 Webhook 自動轉換資源，安全地將資源從一個版本遷移到另一個版本。早期添加測試將有助于增強長期使用 Kubernetes 的信心。