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

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

在這篇博客文章中，我們將探討被棄用的Kubernetes API是什么，它們?yōu)槭裁粗匾?，以及如何有效地管理它們?/p>

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

在閱讀完本文之后，您將更好地了解如何處理Kubernetes集群升級(jí)，并對(duì)您的基礎(chǔ)設(shè)施充滿信心。

API生命周期

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

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

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

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

• 如果一個(gè)API同時(shí)存在多個(gè)版本，Kubernetes API 可能會(huì)自動(dòng)為您升級(jí)其中一些版本。然而，您仍應(yīng)確保您擁有正確的資源方案，特別是因?yàn)殡S著 alpha API 的成熟，方案可能會(huì)在不同版本之間發(fā)生變化。
• 如果一個(gè)API同時(shí)有多個(gè)版本可用，Kubernetes API可以為您悄悄地升級(jí)其中一些版本。然而，您仍應(yīng)確保您擁有正確的資源方案，特別是因?yàn)殡S著alpha API的成熟，方案可能會(huì)在不同版本之間發(fā)生變化。

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

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

可以列出它們：

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

淘汰和移除Kubernetes API

如果您正在運(yùn)行過(guò)時(shí)的Kubernetes API版本，那么您的應(yīng)用程序就面臨著可能導(dǎo)致大量停機(jī)時(shí)間的風(fēng)險(xiǎn)。即使升級(jí)不會(huì)導(dǎo)致停機(jī)，Kubernetes API的微小差異也可能導(dǎo)致煩惱和浪費(fèi)精力去調(diào)查潛在問(wèn)題。

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

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

棄用的Kubernetes API 的關(guān)注點(diǎn)

在配置Kubernetes中的應(yīng)用程序時(shí)，用戶需要在YAML清單或Helm圖表中的apiVersion字段中指定所使用的Kubernetes對(duì)象的API版本，這是一個(gè)關(guān)鍵的方面。這強(qiáng)調(diào)了用戶和維護(hù)人員需要及時(shí)了解已棄用的Kubernetes API版本及其在即將發(fā)布的版本中計(jì)劃移除的重要性。

在 Kubernetes 集群升級(jí)過(guò)程中，遇到廢棄的 API 可能會(huì)成為一個(gè)潛在問(wèn)題，特別是如果升級(jí)后的版本不再支持這些 API。例如，如果您集群中的資源使用了過(guò)時(shí)的 API 版本，那么依賴該資源的應(yīng)用程序可能因?yàn)樾录喊姹局袕U棄的 API 而無(wú)法正常運(yùn)行。這種情況可能導(dǎo)致顯著的停機(jī)時(shí)間，就像 Reddit 的全站宕機(jī)一樣。

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

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版本，請(qǐng)參考下面的示例，該示例摘自Kubernetes文檔：

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

您可以通過(guò)官方文檔或使用kubectl命令行工具的api-versions命令來(lái)查看所有支持的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

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

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

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

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

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

管理?xiàng)売玫腒ubernetes API 的工具

解決處理過(guò)時(shí)的Kubernetes API 問(wèn)題，可以采用幾種工具：

工具1：FairwindsOps的Pluto — 自動(dòng)化檢測(cè)和GitHub集成

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

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

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

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

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

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

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

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

結(jié)論

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

用戶必須知道他們的資源正在使用哪些組和版本，以確保與當(dāng)前的Kubernetes API兼容。資源通?？梢栽跊](méi)有用戶操作的情況下被修改并存儲(chǔ)為更新的資源，從而實(shí)現(xiàn)逐步的模式更改，并增強(qiáng)對(duì)API升級(jí)的信心。

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