本文來自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叢集並不是一個容易做出的決定。希望文章裡對一些功能的介紹，可以給予你一些有意義的參考