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

首當其沖是對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也不能用。