更新Kubernetes 1.18前，你不得不知的9件事

更新Kubernetes 1.18前，你不得不知的9件事

昨天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應用程式，該程式執行以下任務：

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

處理用戶端提供的資料（包括執行大量CPU操作，例如map-reduce）。

處理不太重要的資料（例如，存檔、清理等）

從上述内容明顯看出，任務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叢集并不是一個容易做出的決定。希望文章裡對一些功能的介紹，可以給予你一些有意義的參考。

本文來自Rancher Labs

轉載位址

https://www.cnblogs.com/rancherlabs/p/12579866.html