升級Kubernetes 1.18前，你不得不知的9件事

本文來自Rancher Labs

昨天Kubernetes最新版本v1.18已經發布，其包含了38項功能加強，其中15項爲穩定版功能、11項beta版功能以及12項alpha版功能。在本文中，咱們將探索其中一些功能，但願能幫助你決定是否須要升級。那麼，咱們如今開始吧！

將Service Account Token做爲通用身份驗證方法

Kubernetes使用service account來驗證集羣內的服務。例如，若是你想要一個pod來管理其餘Kubernetes資源，如Deployment或者Service，你能夠與Service Account相關聯並建立必要的角色和角色綁定。Kubernetes Service Account（KSA）發送JSON Web Tokens（JWT）到API server以驗證它們。這使API server成爲service account身份驗證的惟一來源。

那麼，若是實體須要針對集羣外的其餘服務進行身份驗證，該怎麼辦？爲了使用其KSA，外部身份驗證器必須聯繫API server以驗證請求。可是，API server不該公開訪問。由於這使你可使用其餘身份驗證系統進行驗證，這會增長複雜性。即便第三方服務位於能夠訪問API server的集羣中，也會增長負載。

因而在Kubernetes 1.18中增長了一個功能（#1393），該功能使API server提供OpenID Connect發現文檔，該文檔包含Token的公共密鑰以及其餘元數據。OIDC身份驗證器可使用此數據對token進行身份驗證，而沒必要先引用API server。

爲特定Pod配置HPA速率

Horizontal Pod Autoscaler（HPA）可使你的Kubernetes集羣對高/低流量自動作出反應。經過HPA，你能夠指示controller根據CPU峯值、其餘指標或者應用程序提供的指標來建立更多的Pod。爲了優化成本，HPA會在不須要多餘的Pod（例如再也不有高負載時）時將其終止。而HPA是以配置的速率增長/減小Pod，以免在不穩定時間內產生/破壞波動的pod。可是，目前該功能僅在集羣級別能夠配置。在典型的微服務應用程序中，你常常擁有一些比其餘服務更重要的服務。假設你在Kubernetes上託管一個Web應用程序，該程序執行如下任務：

1. 響應最終客戶的請求（前端）

2. 處理客戶端提供的數據（包括執行大量CPU操做，例如map-reduce）。

3. 處理不過重要的數據（例如，存檔、清理等）

從上述內容明顯看出，任務1要求pod更快地擴展，以便應用程序能夠快速有效地處理增長的客戶端流量。此外，它們應該很是緩慢地縮小規模，以防再次出現流量高峯。

任務2須要pod也能夠很是快地擴展以響應增長的數據量。在關鍵任務應用程序中，不該延遲數據處理。可是，它們也應該很是迅速地縮減規模，由於一旦再也不須要，它們會消耗大量地資源，而沒法將這些資源用於其餘服務。

因爲它們的重要性，咱們能夠在必定程度上容忍屬於任務1和2的pod對誤報作出響應。畢竟，浪費一些資源比失去客戶要更好。

服務於任務3的pod不須要特別地安排，由於它們按照常規的方式擴展和縮小便可。

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

在集羣級別定義偶數Pod擴展規則

在Kubernetes 1.16中首次引入Even Pod Spreading，它能夠確保以最高的可用性和資源利用率的方式在可用區上（若是你使用的是多區域集羣）調度Pod。該功能經過指定topologySpreadConstraints來發揮做用，經過搜索具備相同topologyKey標籤的節點來識別區域。具備相同topologyKey標籤的節點屬於同一區域。該設置將pod均勻分配到不一樣區域中。可是，它的缺點是必須在Pod級別應用此設置。沒有配置參數的pod將不會在故障域之間分佈。

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

在Windows上支持Containerd 1.3

當咱們談論「Kubernetes」時，咱們幾乎第一時間想到的是Linux。即便在教程、大部分的書籍和文獻中也廣泛將Linux視爲運行Kubernetes的事實上的操做系統。

然而，Microsoft Windows已經採起相應的措施來支持Kubernetes在Windows Server系列產品上運行。這些措施包括添加對Containerd運行時版本1.3的支持。Windows Server2019包含更新的主機容器服務（HCS v2），其功能是加強了對容器管理的控制，這可能會改善Kubernetes API的兼容性。可是，當前的Docker版本（EE18.09）還未與Windows HCSv2兼容，只有Containerd可使用。使用Containerd運行時能夠在Windows操做系統和Kubernetes之間實現更好的兼容性，也將提供更多功能。該功能（#1001）引入了對Windows的Containerd 1.3版本的支持，並將其做爲容器運行時的接口（CRI）。

在同一集羣中支持RuntimeClass和多個Windows版本的標籤

既然Microsoft Windows正在積極支持Kubernetes的各類功能，所以今天可以看到在Linux和Windows節點上運行的混合集羣並不稀奇。早在Kubernetes 1.12就引入了RuntimeClass，而Kubernetes 1.14引入了主要的加強功能。它可讓你選擇容器運行時，而且其上運行特定的pod。如今，在Kubernetes 1.18中，RuntimeClass支持Windows節點。因此你能夠選擇節點來調度應僅在Windows上運行的Pod，該節點運行特定的Windows構建。

跳過Volume全部權更改

默認狀況下，將volume安裝到Kubernetes集羣中的容器時，該volume內的全部文件和目錄全部權都將更改成提供的fsGroup值。這樣作的緣由是使該volume可由fsGroup讀取和寫入。可是，這種行爲在某些狀況下並非那麼受歡迎。例如：

• 某些應用程序（如數據庫）對文件許可權和全部權修改很敏感。裝入volume後，這些應用程序可能會中止啓動。

• 當volume很大（> 1TB）或者其中包含的文件和目錄的數量很大時，chown和chmod操做可能會太長。在某些狀況下，啓動Pod時可能會致使超時。

該功能（#695）提供了FSGroupChangePolicy參數，將該參數設置爲「always」，將保持當前行爲。而設置爲OnRootMismatch時，它只會在頂級目錄與預期的fsGroup值不匹配時更改volume權限。

容許Secret和ConfigMap不可變

在Kubernetes早期，咱們就已經使用ConfigMap來將配置數據注入到咱們的容器中。若是數據十分敏感，那麼則會使用Secret。將數據呈現給容器最多見的方式是經過掛載一個包含數據的文件。可是，當對ConfigMap或Secret進行更改時，此更改將會馬上傳遞到安裝了該配置文件的全部pod。也許這並非將更改應用於正在運行的集羣的最佳方式。由於若是新配置有問題，咱們將面臨中止運行應用程序的風險。

修改Deployment時，將經過滾動更新策略應用更改，在該策略中，將建立新的Pod，而舊的Pod在刪除以前仍然有做用。該策略能夠確保若是新的Pod沒法啓動，則該應用程序仍將在舊的Pod上運行。ConfigMap和Secret也採用了相似的方法，它們經過在不可變字段中啓用不可變性。當對象不可變時，API將拒絕對其進行任何更改。爲了修改對象，你必須刪除它並從新建立它，同事還要從新建立使用它的全部容器。使用Deployment滾動更新，能夠在刪除舊的Pod以前確保新的pod在新的配置中正常工做，以免因爲配置更改錯誤而致使應用程序中斷。

另外，將ConfigMaps和Secrets設置爲不可變，能夠節省API server沒必要按期輪詢它們的更改。經過啓用ImmutableEmphemeralVolumes功能門，能夠在Kubernetes 1.18中啓用該功能（＃1412）。而後在ConfigMap或Secret資源文件中將不可變值設置爲true，對資源鍵所作的任何更改都將被拒絕，從而保護集羣不受意外的壞更新的影響。

使用Kubectl調試爲用戶提供更多故障排除功能

做爲Kubernetes用戶，當你須要查看正在運行的Pod時，你將受到kubectl exec和kubectl port-forward的限制。而在Kubernetes 1.18中，你還可使用kubectl debug命令。該命令容許你執行如下操做：

將臨時容器部署到正在運行的Pod。臨時容器聲明週期短，它們一般包含必要的調試工具。因爲它們是在同一pod中啓動的，所以它們能夠訪問具備相同網絡和文件系統的其餘容器。這在極大程度上能夠幫助你解決問題或跟蹤問題。

使用修改後的PodSpec從新就地啓動Pod。這使你能夠進行諸如更改容器的源鏡像或權限之類的操做。

你甚至能夠在主機命名空間中啓動特權容器。這使你能夠對節點問題進行故障排除。

總 結

Kubernetes是一項不斷變化的技術，每一個版本中都添加了愈來愈多的功能。在本文中，咱們簡要討論了Kubernetes 1.18中一些最有趣的新功能。可是，毋庸置疑，升級Kubernetes集羣並非一個容易作出的決定。但願文章裏對一些功能的介紹，能夠給予你一些有意義的參考。