隨著新功能和功能的增加,舊的API被棄用并最終移除。雖然這是Kubernetes發展的必要部分,但對于依賴該平臺運行應用程序的組織來說,這可能會帶來挑戰。
Kubernetes API作為與K8集群交互的接口。如果集群中仍在使用已棄用的API,可能會導致中斷不可用。
在這篇博客文章中,我們將探討被棄用的Kubernetes API是什么,它們為什么重要,以及如何有效地管理它們。
我們還將介紹一些用于處理 Kubernetes 中廢棄 API 的可用工具,并提供管理廢棄 API 的最佳實踐。
在閱讀完本文之后,您將更好地了解如何處理Kubernetes集群升級,并對您的基礎設施充滿信心。
Kubernetes遵循alpha → beta → stable的成熟度進展,并且還有一些額外的版本控制,這樣資源可以在不需要進入下一個成熟度級別的情況下進行迭代。
一個alpha資源可以從v1alpha1開始,并且可以通過v1alpha2進行迭代,或者如果有破壞性的變化,可能會使用v2alpha1。一個beta API可能與alpha API具有相同的規范,但是成熟度和與用戶的約定將會有所不同。
我提到的生命周期如下所示:
您可以在這里查看k8s API概述,例如,部署屬于應用程序組,并具有v1版本。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/
可以列出它們:
/apis/apps/v1/namespaces/{namespace}/deployments
如果您正在運行過時的Kubernetes API版本,那么您的應用程序就面臨著可能導致大量停機時間的風險。即使升級不會導致停機,Kubernetes API的微小差異也可能導致煩惱和浪費精力去調查潛在問題。
在這個場景中,棄用意味著確定一個 API 組件最終會被移除。雖然它目前仍在運行,但計劃在即將發布的版本中被淘汰。Kubernetes 遵循明確定義的棄用政策,通知用戶哪些 API 將被移除或修改。
Kubernetes API作為與Kubernetes集群交互的接口,允許用戶查詢和操作各種Kubernetes對象,如pod、命名空間和部署。這些API可以通過諸如kubectl之類的工具、直接通過REST API,或者使用客戶端庫來訪問。隨著Kubernetes的發展,舊的API被標記為棄用,并最終被淘汰。這凸顯了用戶或維護者需要意識到棄用的Kubernetes API的重要性。
在配置Kubernetes中的應用程序時,用戶需要在YAML清單或Helm圖表中的apiVersion字段中指定所使用的Kubernetes對象的API版本,這是一個關鍵的方面。這強調了用戶和維護人員需要及時了解已棄用的Kubernetes API版本及其在即將發布的版本中計劃移除的重要性。
在 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"
要在您的配置中指定特定的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-versionsadmissionregistration.k8s.io/v1admissionregistration.k8s.io/v1beta1apiextensions.k8s.io/v1apiextensions.k8s.io/v1beta1apiregistration.k8s.io/v1apiregistration.k8s.io/v1beta1apps/v1
識別集群中利用已棄用API的資源可能會相當具有挑戰性。此外,Kubernetes遵循嚴格的API版本控制協議,導致在多個發布版本中多次棄用v1beta1和v2beta1的API。
他們的政策規定,Beta API 版本在棄用后必須至少獲得 9 個月或 3 個發布版本(以較長者為準)的支持,之后可能會被移除。
在一些情況下,如果被棄用的API仍然被工作負載、工具或其他與集群接口的組件所積極使用,可能會導致中斷發生。
因此,用戶和管理員必須對其集群進行徹底評估,以確定任何即將移除的正在使用的API,并隨后遷移受影響的組件,以利用適當的新API版本。
解決處理過時的Kubernetes API 問題,可以采用幾種工具:
FairwindsOps推出了Pluto,這是一個自動化解決方案,用于檢測代碼存儲庫和Helm發布中已棄用的Kubernetes API。通過無縫集成GitHub工作流程,Pluto確保持續監控,及時識別已棄用的API,并進行積極的管理。
由doitintl開發,Kube No Trouble (kubent) 專注于對過時API的全面集群級檢查,重點關注部署以進行檢測。該工具需要存儲原始清單,提供了一個全面的解決方案,用于識別和解決Kubernetes集群中的過時API。
The Helm MapkubeAPIs Plugin是一個有價值的工具,用于識別在集群上安裝的Helm charts中已棄用的API。該插件提供了一種有針對性的方法來管理API的棄用,確保在升級過程中兼容性和平穩過渡。
Plural CD,可全面管理已棄用的Kubernetes API。其多方面的能力有助于在Kubernetes升級期間實現更順暢的過渡,使其成為識別和有效處理已棄用API的重要組成部分。
這些工具共同幫助用戶主動識別和解決已棄用的API,最大限度地減少在Kubernetes升級過程中可能出現的問題。通過將這些工具無縫地整合到您的工作流程中,您可以確保平穩過渡到更新的API版本,提高Kubernetes基礎架構的整體穩定性和可靠性。
Kubernetes API被設計為靈活且經常變化,這是其核心優勢之一。
用戶必須知道他們的資源正在使用哪些組和版本,以確保與當前的Kubernetes API兼容。資源通常可以在沒有用戶操作的情況下被修改并存儲為更新的資源,從而實現逐步的模式更改,并增強對API升級的信心。
重要的是通過工具靜態驗證資源或使用轉換 Webhook 自動轉換資源,安全地將資源從一個版本遷移到另一個版本。早期添加測試將有助于增強長期使用 Kubernetes 的信心。
本文鏈接:http://www.www897cc.com/showinfo-26-66191-0.html管理棄用的Kubernetes API:優秀實踐和工具
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 深入C++異常處理:構建健壯程序的利器