升級Kubernetes 1.18前要注意哪些問題

本篇內(nèi)容主要講解“升級Kubernetes 1.18前要注意哪些問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“升級Kubernetes 1.18前要注意哪些問題”吧!

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

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

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

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

為特定Pod配置HPA速率

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

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

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

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

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

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

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

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

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

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

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

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

在Windows上支持Containerd 1.3

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

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

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

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

跳過Volume所有權更改

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

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

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

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

允許Secret和ConfigMap不可變

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

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

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

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

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

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

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

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

到此，相信大家對“升級Kubernetes 1.18前要注意哪些問題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！