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

首當其沖是對dockershim支持的正式移除。在一年多以前，Kubernetes 1.20版本宣布對Docker的支持置為“廢棄(Deprecated)”狀態(tài)，不再演進，并“將在未來的某個版本中移除(Will be removed)”。這次發(fā)布的1.24版即是所謂“正式移除Docker支持”的版本，然而，Docker公司卻宣稱，在Kubernetes環(huán)境中，可以繼續(xù)使用Docker，其Docker Desktop產(chǎn)品的用戶仍然能夠無縫使用Kubernetes的最新發(fā)布版本。這是怎么回事？

事實上，仔細閱讀Kubernetes官方的1.24版的Change Log，你會發(fā)現(xiàn)，其對于Docker支持的表述與一年前的1.20版有微妙的不同。

1.20版Change Log 截圖

1.24版Change Log截圖

Kubernetes移除Docker主要是因為Docker長期以來不支持Kubernetes主推的CRI容器運行時接口標準，因此Kubernetes社區(qū)維護了一個dockershim組件專門用來對接Docker。

這在當年Docker具備壟斷地位時非常有必要，隨著containerd和kata等容器運行時發(fā)展成熟，尤其是containerd在生產(chǎn)環(huán)境中大量使用，Kubernetes社區(qū)決定不再維護dockershim。

然而，最近兩年Mirantis(已于2019年11月收購Docker Enterprise部門)和Docker公司在對Kubernetes的支持上不斷投入，目前社區(qū)里已經(jīng)有一個獨立于Kubernetes并且支持CRI的“shim”：cri-dockerd，繼續(xù)實現(xiàn)Kubernetes與Docker的對接。

Docker Desktop以其優(yōu)秀的用戶體驗深得很多開發(fā)者的青睞，自Kubernetes 1.20版本發(fā)布以來，筆者就在尋找Docker Desktop的替代品，也嘗試了不少，但目前還沒有找到能夠與之媲美的產(chǎn)品。cri-dockerd讓Kubernetes 1.24能夠繼續(xù)對接Docker容器運行時，這意味著用戶可以像以前一樣在Docker Desktop中一鍵安裝并無縫使用最新版的Kubernetes，對于開發(fā)者來說無疑是個好消息。

同時由于Docker Image已經(jīng)成為了各類容器運行時使用的標準鏡像格式，開發(fā)使用Docker，生產(chǎn)或者發(fā)布到客戶的環(huán)境中使用的是其他容器運行時可能會成為一種長期存在的普遍現(xiàn)象。

第二個想聊一聊的是Kubernetes的Job。對于批處理類的應用負載，Kubernetes提供了Job資源來支持。但是當我們要運行并行處理或者分布式計算的Job時，會遇到一個問題：Kubernetes中的Pod是動態(tài)創(chuàng)建和回收的，這也是基于Kubernetes Job來運行批處理負載的優(yōu)勢之一，因為資源能夠在需要時才被占用，用完可以立即回收，然而這卻會導致任務在往各個Pod分配時缺少依據(jù)(基于機器的并行計算系統(tǒng)中往往需要將主機名稱等相對固定的標識作為任務調度的輸入)。

在早些版本中，Kubernetes官方建議引入消息隊列或者內存數(shù)據(jù)庫來給Job的各個Pod分配編號以解決該問題[1]，這無疑提升了應用的復雜度且引入了第三方組件的運維問題。在Kubernetes 1.24版本中，有一項從Beta階段提升為正式特性的功能叫做“Indexed Job”，該特性會給同一個Job的各個Pod在環(huán)境變量中注入一個編號索引，應用可以根據(jù)這個編號為各個Pod分配具體的task。

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

第三個推薦開發(fā)者關注的特性是gPRC健康狀態(tài)探針已經(jīng)是beta狀態(tài)了，這是一個很值得期待的功能。gRPC協(xié)議在云原生應用中得到日益廣泛的使用，然而Kubernetes過去一直缺少gRPC原生的健康狀態(tài)探針支持，使得對gRPC服務的啟動、存活和就緒狀態(tài)檢查都需要依賴其他手段，官網(wǎng)有一篇文章對這些技術手段進行了介紹[2]，從文章中不難看出，這些方法對于應用遷移上Kubernetes的成本和云原生應用的可維護性、可用性都會有一定的影響。在Kubernetes原生支持gRPC探針后，這些問題得到了有效的解決，采用gRPC協(xié)議構建云原生應用的同仁們可以期待一下這個特性未來從beta狀態(tài)變?yōu)檎娇捎谩?/p>

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