最搶鮮的Kubernetes 1.18 線上Demo來了！下周四（4月2日）晚上8點半，《Kubernetes 1.18網(wǎng)研會》為你帶來K8S 1.18的新特性詳解和實操演示，包括K8S拓?fù)涔芾砥?、IngressClass以及kubectl debug等等內(nèi)容。

PC端訪問以下鏈接即可報名：

http://z-mz.cn/lMe8

昨天Kubernetes最新版本v1.18已經(jīng)發(fā)布，其包含了38項功能增強(qiáng)，其中15項為穩(wěn)定版功能、11項beta版功能以及12項alpha版功能。在本文中，我們將探索其中一些功能，希望能幫助你決定是否需要升級。那么，我們現(xiàn)在開始吧！

將Service Account Token作為通用身份驗證方法

Kubernetes使用service account來驗證集群內(nèi)的服務(wù)。例如，如果你想要一個pod來管理其他Kubernetes資源，如Deployment或者Service，你可以與Service Account相關(guān)聯(lián)并創(chuàng)建必要的角色和角色綁定。Kubernetes Service Account（KSA）發(fā)送JSON Web Tokens（JWT）到API server以驗證它們。這使API server成為service account身份驗證的唯一來源。

那么，如果實體需要針對集群外的其他服務(wù)進(jìn)行身份驗證，該怎么辦？為了使用其KSA，外部身份驗證器必須聯(lián)系A(chǔ)PI server以驗證請求。但是，API server不應(yīng)公開訪問。因為這使你可以使用其他身份驗證系統(tǒng)進(jìn)行驗證，這會增加復(fù)雜性。即使第三方服務(wù)位于可以訪問API server的集群中，也會增加負(fù)載。

于是在Kubernetes 1.18中增加了一個功能（#1393），該功能使API server提供OpenID Connect發(fā)現(xiàn)文檔，該文檔包含Token的公共密鑰以及其他元數(shù)據(jù)。OIDC身份驗證器可以使用此數(shù)據(jù)對token進(jìn)行身份驗證，而不必先引用API server。

為特定Pod配置HPA速率

Horizontal Pod Autoscaler（HPA）可以使你的Kubernetes集群對高/低流量自動做出反應(yīng)。通過HPA，你可以指示controller根據(jù)CPU峰值、其他指標(biāo)或者應(yīng)用程序提供的指標(biāo)來創(chuàng)建更多的Pod。為了優(yōu)化成本，HPA會在不需要多余的Pod（例如不再有高負(fù)載時）時將其終止。而HPA是以配置的速率增加/減少Pod，以避免在不穩(wěn)定時間內(nèi)產(chǎn)生/破壞波動的pod。但是，目前該功能僅在集群級別可以配置。在典型的微服務(wù)應(yīng)用程序中，你經(jīng)常擁有一些比其他服務(wù)更重要的服務(wù)。假設(shè)你在Kubernetes上托管一個Web應(yīng)用程序，該程序執(zhí)行以下任務(wù)：

1. 響應(yīng)最終客戶的請求（前端）

2. 處理客戶端提供的數(shù)據(jù)（包括執(zhí)行大量CPU操作，例如map-reduce）。

3. 處理不太重要的數(shù)據(jù)（例如，存檔、清理等）

從上述內(nèi)容明顯看出，任務(wù)1要求pod更快地擴(kuò)展，以便應(yīng)用程序可以快速有效地處理增加的客戶端流量。此外，它們應(yīng)該非常緩慢地縮小規(guī)模，以防再次出現(xiàn)流量高峰。

任務(wù)2需要pod也可以非?？斓財U(kuò)展以響應(yīng)增加的數(shù)據(jù)量。在關(guān)鍵任務(wù)應(yīng)用程序中，不應(yīng)延遲數(shù)據(jù)處理。但是，它們也應(yīng)該非常迅速地縮減規(guī)模，因為一旦不再需要，它們會消耗大量地資源，而無法將這些資源用于其他服務(wù)。

由于它們的重要性，我們可以在一定程度上容忍屬于任務(wù)1和2的pod對誤報做出響應(yīng)。畢竟，浪費一些資源比失去客戶要更好。

服務(wù)于任務(wù)3的pod不需要特別地安排，因為它們按照常規(guī)的方式擴(kuò)展和縮小即可。

在Kubernetes 1.18中提供了功能（#853），允許通過HPA行為字段配置彈性伸縮。在行為字段下的scaleUp或scaleDown部分中分別指定了用于按比例縮放的行為。

在集群級別定義偶數(shù)Pod擴(kuò)展規(guī)則

在Kubernetes 1.16中首次引入Even Pod Spreading，它可以確保以最高的可用性和資源利用率的方式在可用區(qū)上（如果你使用的是多區(qū)域集群）調(diào)度Pod。該功能通過指定topologySpreadConstraints來發(fā)揮作用，通過搜索具有相同topologyKey標(biāo)簽的節(jié)點來識別區(qū)域。具有相同topologyKey標(biāo)簽的節(jié)點屬于同一區(qū)域。該設(shè)置將pod均勻分配到不同區(qū)域中。但是，它的缺點是必須在Pod級別應(yīng)用此設(shè)置。沒有配置參數(shù)的pod將不會在故障域之間分布。

這一功能（＃895）允許你為不提供任何topologySpreadConstraints的Pod定義default spreading constraints。已定義此設(shè)置的Pod將覆蓋全局級別。

在Windows上支持Containerd 1.3

當(dāng)我們談?wù)摗癒ubernetes”時，我們幾乎第一時間想到的是Linux。即使在教程、大部分的書籍和文獻(xiàn)中也普遍將Linux視為運行Kubernetes的事實上的操作系統(tǒng)。

然而，Microsoft Windows已經(jīng)采取相應(yīng)的措施來支持Kubernetes在Windows Server系列產(chǎn)品上運行。這些措施包括添加對Containerd運行時版本1.3的支持。Windows Server2019包含更新的主機(jī)容器服務(wù)（HCS v2），其功能是增強(qiáng)了對容器管理的控制，這可能會改善Kubernetes API的兼容性。但是，當(dāng)前的Docker版本（EE18.09）還未與Windows HCSv2兼容，只有Containerd可以使用。使用Containerd運行時可以在Windows操作系統(tǒng)和Kubernetes之間實現(xiàn)更好的兼容性，也將提供更多功能。該功能（#1001）引入了對Windows的Containerd 1.3版本的支持，并將其作為容器運行時的接口（CRI）。

在同一集群中支持RuntimeClass和多個Windows版本的標(biāo)簽

既然Microsoft Windows正在積極支持Kubernetes的各種功能，因此今天能夠看到在Linux和Windows節(jié)點上運行的混合集群并不稀奇。早在Kubernetes 1.12就引入了RuntimeClass，而Kubernetes 1.14引入了主要的增強(qiáng)功能。它可以讓你選擇容器運行時，并且其上運行特定的pod?，F(xiàn)在，在Kubernetes 1.18中，RuntimeClass支持Windows節(jié)點。所以你可以選擇節(jié)點來調(diào)度應(yīng)僅在Windows上運行的Pod，該節(jié)點運行特定的Windows構(gòu)建。

跳過Volume所有權(quán)更改

默認(rèn)情況下，將volume安裝到Kubernetes集群中的容器時，該volume內(nèi)的所有文件和目錄所有權(quán)都將更改為提供的fsGroup值。這樣做的原因是使該volume可由fsGroup讀取和寫入。但是，這種行為在某些情況下并不是那么受歡迎。例如：

• 某些應(yīng)用程序（如數(shù)據(jù)庫）對文件許可權(quán)和所有權(quán)修改很敏感。裝入volume后，這些應(yīng)用程序可能會停止啟動。

• 當(dāng)volume很大（> 1TB）或者其中包含的文件和目錄的數(shù)量很大時，chown和chmod操作可能會太長。在某些情況下，啟動Pod時可能會導(dǎo)致超時。

該功能（#695）提供了FSGroupChangePolicy參數(shù)，將該參數(shù)設(shè)置為“always”，將保持當(dāng)前行為。而設(shè)置為OnRootMismatch時，它只會在頂級目錄與預(yù)期的fsGroup值不匹配時更改volume權(quán)限。

允許Secret和ConfigMap不可變

在Kubernetes早期，我們就已經(jīng)使用ConfigMap來將配置數(shù)據(jù)注入到我們的容器中。如果數(shù)據(jù)十分敏感，那么則會使用Secret。將數(shù)據(jù)呈現(xiàn)給容器最常見的方式是通過掛載一個包含數(shù)據(jù)的文件。但是，當(dāng)對ConfigMap或Secret進(jìn)行更改時，此更改將會立刻傳遞到安裝了該配置文件的所有pod。也許這并不是將更改應(yīng)用于正在運行的集群的最佳方式。因為如果新配置有問題，我們將面臨停止運行應(yīng)用程序的風(fēng)險。

修改Deployment時，將通過滾動更新策略應(yīng)用更改，在該策略中，將創(chuàng)建新的Pod，而舊的Pod在刪除之前仍然有作用。該策略可以確保如果新的Pod無法啟動，則該應(yīng)用程序仍將在舊的Pod上運行。ConfigMap和Secret也采用了類似的方法，它們通過在不可變字段中啟用不可變性。當(dāng)對象不可變時，API將拒絕對其進(jìn)行任何更改。為了修改對象，你必須刪除它并重新創(chuàng)建它，同事還要重新創(chuàng)建使用它的所有容器。使用Deployment滾動更新，可以在刪除舊的Pod之前確保新的pod在新的配置中正常工作，以避免由于配置更改錯誤而導(dǎo)致應(yīng)用程序中斷。

另外，將ConfigMaps和Secrets設(shè)置為不可變，可以節(jié)省API server不必定期輪詢它們的更改。通過啟用ImmutableEmphemeralVolumes功能門，可以在Kubernetes 1.18中啟用該功能（＃1412）。然后在ConfigMap或Secret資源文件中將不可變值設(shè)置為true，對資源鍵所做的任何更改都將被拒絕，從而保護(hù)集群不受意外的壞更新的影響。

使用Kubectl調(diào)試為用戶提供更多故障排除功能

作為Kubernetes用戶，當(dāng)你需要查看正在運行的Pod時，你將受到kubectl exec和kubectl port-forward的限制。而在Kubernetes 1.18中，你還可以使用kubectl debug命令。該命令允許你執(zhí)行以下操作：

• 將臨時容器部署到正在運行的Pod。臨時容器聲明周期短，它們通常包含必要的調(diào)試工具。由于它們是在同一pod中啟動的，因此它們可以訪問具有相同網(wǎng)絡(luò)和文件系統(tǒng)的其他容器。這在極大程度上可以幫助你解決問題或跟蹤問題。

• 使用修改后的PodSpec重新就地啟動Pod。這使你可以進(jìn)行諸如更改容器的源鏡像或權(quán)限之類的操作。

• 你甚至可以在主機(jī)命名空間中啟動特權(quán)容器。這使你可以對節(jié)點問題進(jìn)行故障排除。

總? 結(jié)

Kubernetes是一項不斷變化的技術(shù)，每個版本中都添加了越來越多的功能。在本文中，我們簡要討論了Kubernetes 1.18中一些最有趣的新功能。但是，毋庸置疑，升級Kubernetes集群并不是一個容易做出的決定。希望文章里對一些功能的介紹，可以給予你一些有意義的參考。

如果你還想更詳細(xì)地了解Kubernetes 1.18中的新功能以及其應(yīng)用場景，趕緊來報名參加下周四晚上的Webinar！我們的宗旨是：demo、demo and more demo！