共計 3958 個字符，預計需要花費 10 分鐘才能閱讀完成。
本篇內容主要講解“升級 Kubernetes 1.18 前要注意哪些問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“升級 Kubernetes 1.18 前要注意哪些問題”吧!
將 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 1.18 前要注意哪些問題”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
