Kubernetes 1.24删除Dockershim，為有狀态工作負載騰出空間

Kubernetes容器編排引擎的最新版本，綽号為“Stargazer”，旨在更好地支援資料庫、微服務和其他新興用例，同時擺脫此前阻礙K8s核心開發人員生産力的失誤。

據管理該開源項目的CNCF稱，總的來說，這個版本有46個“增強”。15項增強功能已更新到穩定狀态，這意味着它們已準備好投入生産使用，15項增強功能正在更新到beta，13項增強功能已進入alpha狀态。

首先，從老版本走出去。

那些仍在使用Docker運作時引擎的人必須找到替代品或商業解決方案，才能将其用于Kubernetes的新版本：從1.24開始，Dockershim将不再受支援。

2020年決定放棄對Docker運作時的支援。盡管Docker在容器的使用方面首次取得了廣泛的成功，但Kubernetes還是轉向了2016年推出的标準化容器運作時接口，以允許Kubernetes-Kubelet節點引擎與任何相容的運作時引擎接口，其目标是不完全依賴Docker本身。

當然，最初的Docker引擎本身并不相容，是以制作了一個墊片來操作K8s上的運作時。在這次釋出之前，該墊片一直被支援。

此更改将與仍在使用Docker引擎本身的正在運作的部署相關，在更新之前，需要将其更新到相容的運作時（CRI-O或containerd）或商用Mirantis容器運作時（MCR）。

在Docker開發工具上建構的容器現在建構為在CRI規範上運作，并且不受此更改的影響。“對于大多數應用程式開發人員來說，這将是一個透明的變化。”v1.24釋出項目負責人James Laverack解釋道。

雖然Laverack沒有估計有多少部署仍然依賴Docker引擎，但他指出，仍然這樣做的唯一原因是如果Kubernetes功能是在其API之外通路的。在這些情況下，這樣做的應用程式需要進行一些更新工作。

Laverack解釋說，通過API以外的方式通路Kubernetes是有問題的，原因有幾個。首先，它可以将使用者鎖定為隻使用一個引擎（在本例中為Docker）來通路Kubernetes功能。

Docker墊片也存在問題，因為它為K8s維護人員帶來了大量維護工作。有很多專門用來處理Docker的代碼（與CRI本身并行），而且都有缺陷。Lavelack說，消除支援有助于K8s工程師簡化代碼庫。

“社群認為，删除它将使代碼庫的這一部分得到簡化，減少bug，提高穩定性，并提高更多釋出的速度。”Laverack說，“是以，這确實是一個基礎性的改變，将有助于Kubernetes在未來以更好的品質推出更多功能。”

還有什麼？

Stargazer還展示了為Kubernetes提供存儲感覺控制所做的工作。對于那些計劃在Kubernetes上運作有狀态工作負載（如資料庫）的人來說，這将是個好消息。Kubernetes-aware應用程式将能夠使用這些功能以更精細的粒度管理存儲，提供調整卷大小的能力，或允許應用程式根據任何給定時刻可用的剩餘存儲做出決策。

作為API伺服器的alpha版本引入的上下文日志功能将幫助平台工程師和Kubernetes核心開發團隊自己調試Kubernetes。該版本現在在測試版中支援Kubernetes OpenAPI的第3版，該版本允許第三方開發人員編寫operator和自定義資源定義來擴充Kubernetes。

對于微服務開發者來說，好消息是：Kubernetes 1.24支援谷歌的gRPC通信協定。

一個新的探測功能消除了設定單獨的HTTP伺服器來檢查容器準備就緒和可用性的需要。Lavelack說，微服務經常使用gRPC進行通信，這将允許開發者在gRPC上标準化他們的堆棧。

安全性已經向前邁出了一大步，現在可以使用Sigstore簽署釋出工件。K8s使用者現在可以簽署他們的軟體元件，確定它們沒有被篡改。

Chainguard開源負責人Tracy Miranda在Sigstore的一篇部落格文章中表示：“這是保護Kubernetes生态系統完整性的一大步，并證明了由于供應鍊攻擊的增加，大規模的代碼簽名是可能的，而且坦率地說是必要的。”

原文連結：