5月4日， Kubernetes 1.24版正式發(fā)布了，像之前的幾個(gè)版本一樣，給Kubernetes帶來(lái)了大大小小多達(dá)幾十項(xiàng)的變化。幾十項(xiàng)涉及到基礎(chǔ)設(shè)施、運(yùn)維和應(yīng)用開(kāi)發(fā)的方方面面，可能很難有人能夠全部搞懂，本文也不打算一一羅列，謹(jǐn)結(jié)合自己的體會(huì)，談幾個(gè)應(yīng)用開(kāi)發(fā)者可能比較關(guān)注的點(diǎn)。

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

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

1.20版Change Log 截圖

1.24版Change Log截圖

Kubernetes移除Docker主要是因?yàn)镈ocker長(zhǎng)期以來(lái)不支持Kubernetes主推的CRI容器運(yùn)行時(shí)接口標(biāo)準(zhǔn)，因此Kubernetes社區(qū)維護(hù)了一個(gè)dockershim組件專(zhuān)門(mén)用來(lái)對(duì)接Docker。

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

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

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

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

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

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

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

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

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