溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“升級Kubernetes 1.18前要注意哪些問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“升級Kubernetes 1.18前要注意哪些問題”吧!
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。
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部分中分別指定了用于按比例縮放的行為。
在Kubernetes 1.16中首次引入Even Pod Spreading，它可以確保以最高的可用性和資源利用率的方式在可用區上（如果你使用的是多區域集群）調度Pod。該功能通過指定topologySpreadConstraints來發揮作用，通過搜索具有相同topologyKey標簽的節點來識別區域。具有相同topologyKey標簽的節點屬于同一區域。該設置將pod均勻分配到不同區域中。但是，它的缺點是必須在Pod級別應用此設置。沒有配置參數的pod將不會在故障域之間分布。
這一功能（＃895）允許你為不提供任何topologySpreadConstraints的Pod定義default spreading constraints。已定義此設置的Pod將覆蓋全局級別。
當我們談論“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）。
既然Microsoft Windows正在積極支持Kubernetes的各種功能，因此今天能夠看到在Linux和Windows節點上運行的混合集群并不稀奇。早在Kubernetes 1.12就引入了RuntimeClass，而Kubernetes 1.14引入了主要的增強功能。它可以讓你選擇容器運行時，并且其上運行特定的pod。現在，在Kubernetes 1.18中，RuntimeClass支持Windows節點。所以你可以選擇節點來調度應僅在Windows上運行的Pod，該節點運行特定的Windows構建。
默認情況下，將volume安裝到Kubernetes集群中的容器時，該volume內的所有文件和目錄所有權都將更改為提供的fsGroup值。這樣做的原因是使該volume可由fsGroup讀取和寫入。但是，這種行為在某些情況下并不是那么受歡迎。例如：
某些應用程序（如數據庫）對文件許可權和所有權修改很敏感。裝入volume后，這些應用程序可能會停止啟動。
當volume很大（> 1TB）或者其中包含的文件和目錄的數量很大時，chown和chmod操作可能會太長。在某些情況下，啟動Pod時可能會導致超時。
該功能（#695）提供了FSGroupChangePolicy參數，將該參數設置為“always”，將保持當前行為。而設置為OnRootMismatch時，它只會在頂級目錄與預期的fsGroup值不匹配時更改volume權限。
在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，對資源鍵所做的任何更改都將被拒絕，從而保護集群不受意外的壞更新的影響。
作為Kubernetes用戶，當你需要查看正在運行的Pod時，你將受到kubectl exec和kubectl port-forward的限制。而在Kubernetes 1.18中，你還可以使用kubectl debug命令。該命令允許你執行以下操作：
將臨時容器部署到正在運行的Pod。臨時容器聲明周期短，它們通常包含必要的調試工具。由于它們是在同一pod中啟動的，因此它們可以訪問具有相同網絡和文件系統的其他容器。這在極大程度上可以幫助你解決問題或跟蹤問題。
使用修改后的PodSpec重新就地啟動Pod。這使你可以進行諸如更改容器的源鏡像或權限之類的操作。
你甚至可以在主機命名空間中啟動特權容器。這使你可以對節點問題進行故障排除。
到此，相信大家對“升級Kubernetes 1.18前要注意哪些問題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
