Kubernetes 1.24新特性解讀

5月4日， Kubernetes 1.24版正式釋出了，像之前的幾個版本一樣，給Kubernetes帶來了大大小小多達幾十項的變化。幾十項涉及到基礎設施、運維和應用開發的方方面面，可能很難有人能夠全部搞懂，本文也不打算一一羅列，謹結合自己的體會，談幾個應用開發者可能比較關注的點。

Kubernetes 1.24版Logo：觀星者

首當其衝是對dockershim支援的正式移除。在一年多以前，Kubernetes 1.20版本宣佈對Docker的支援置為“廢棄(Deprecated)”狀態，不再演進，並“將在未來的某個版本中移除(Will be removed)”。這次釋出的1.24版即是所謂“正式移除Docker支援”的版本，然而，Docker公司卻宣稱，在Kubernetes環境中，可以繼續使用Docker，其Docker Desktop產品的使用者仍然能夠無縫使用Kubernetes的最新發布版本。這是怎麼回事?

事實上，仔細閱讀Kubernetes官方的1.24版的Change Log，你會發現，其對於Docker支援的表述與一年前的1.20版有微妙的不同。

1.20版Change Log 截圖

1.24版Change Log截圖

Kubernetes移除Docker主要是因為Docker長期以來不支援Kubernetes主推的CRI容器執行時介面標準，因此Kubernetes社群維護了一個dockershim元件專門用來對接Docker。

這在當年Docker具備壟斷地位時非常有必要，隨著containerd和kata等容器執行時發展成熟，尤其是containerd在生產環境中大量使用，Kubernetes社群決定不再維護dockershim。

然而，最近兩年Mirantis(已於2019年11月收購Docker Enterprise部門)和Docker公司在對Kubernetes的支援上不斷投入，目前社群裡已經有一個獨立於Kubernetes並且支援CRI的“shim”：cri-dockerd，繼續實現Kubernetes與Docker的對接。

Docker Desktop以其優秀的使用者體驗深得很多開發者的青睞，自Kubernetes 1.20版本釋出以來，筆者就在尋找Docker Desktop的替代品，也嘗試了不少，但目前還沒有找到能夠與之媲美的產品。cri-dockerd讓Kubernetes 1.24能夠繼續對接Docker容器執行時，這意味著使用者可以像以前一樣在Docker Desktop中一鍵安裝並無縫使用最新版的Kubernetes，對於開發者來說無疑是個好訊息。

同時由於Docker Image已經成為了各類容器執行時使用的標準映象格式，開發使用Docker，生產或者釋出到客戶的環境中使用的是其他容器執行時可能會成為一種長期存在的普遍現象。

第二個想聊一聊的是Kubernetes的Job。對於批處理類的應用負載，Kubernetes提供了Job資源來支援。但是當我們要執行並行處理或者分散式計算的Job時，會遇到一個問題：Kubernetes中的Pod是動態建立和回收的，這也是基於Kubernetes Job來執行批處理負載的優勢之一，因為資源能夠在需要時才被佔用，用完可以立即回收，然而這卻會導致任務在往各個Pod分配時缺少依據(基於機器的平行計算系統中往往需要將主機名稱等相對固定的標識作為任務排程的輸入)。

在早些版本中，Kubernetes官方建議引入訊息佇列或者記憶體資料庫來給Job的各個Pod分配編號以解決該問題[1]，這無疑提升了應用的複雜度且引入了第三方元件的運維問題。在Kubernetes 1.24版本中，有一項從Beta階段提升為正式特性的功能叫做“Indexed Job”，該特性會給同一個Job的各個Pod在環境變數中注入一個編號索引，應用可以根據這個編號為各個Pod分配具體的task。

去年該特性還在beta階段時，筆者嘗試將一個基於Kubernetes Job的雲原生分散式圖計算應用從依賴外部訊息佇列分配task改為Indexed Job，應用的可維護性、穩定性和資源消耗都得到了明顯的改善。

第三個推薦開發者關注的特性是gPRC健康狀態探針已經是beta狀態了，這是一個很值得期待的功能。gRPC協議在雲原生應用中得到日益廣泛的使用，然而Kubernetes過去一直缺少gRPC原生的健康狀態探針支援，使得對gRPC服務的啟動、存活和就緒狀態檢查都需要依賴其他手段，官網有一篇文章對這些技術手段進行了介紹[2]，從文章中不難看出，這些方法對於應用遷移上Kubernetes的成本和雲原生應用的可維護性、可用性都會有一定的影響。在Kubernetes原生支援gRPC探針後，這些問題得到了有效的解決，採用gRPC協議構建雲原生應用的同仁們可以期待一下這個特性未來從beta狀態變為正式可用。

最後想到一個非常有意思的更新，1.24版本以後，kubeadm安裝Kubernetes叢集時，不再給執行控制面元件的節點標記為“master”，因為這個詞被認為是“具有攻擊性的、無禮的(offensive)”。近幾年，一些用master-slave來表示主-從節點的計算機系統紛紛改掉術語，slave前兩年就已經銷聲匿跡了，現在看來master也不能用。