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

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序定制開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了宜昌免費(fèi)建站歡迎大家使用！

將Service Account Token作為通用身份驗(yàn)證方法

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

那么，如果實(shí)體需要針對(duì)集群外的其他服務(wù)進(jìn)行身份驗(yàn)證，該怎么辦？為了使用其KSA，外部身份驗(yàn)證器必須聯(lián)系A(chǔ)PI server以驗(yàn)證請(qǐng)求。但是，API server不應(yīng)公開(kāi)訪問(wèn)。因?yàn)檫@使你可以使用其他身份驗(yàn)證系統(tǒng)進(jìn)行驗(yàn)證，這會(huì)增加復(fù)雜性。即使第三方服務(wù)位于可以訪問(wèn)API server的集群中，也會(huì)增加負(fù)載。

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

為特定Pod配置HPA速率

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

1. 響應(yīng)最終客戶的請(qǐng)求（前端）

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

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

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

任務(wù)2需要pod也可以非常快地?cái)U(kuò)展以響應(yīng)增加的數(shù)據(jù)量。在關(guān)鍵任務(wù)應(yīng)用程序中，不應(yīng)延遲數(shù)據(jù)處理。但是，它們也應(yīng)該非常迅速地縮減規(guī)模，因?yàn)橐坏┎辉傩枰鼈儠?huì)消耗大量地資源，而無(wú)法將這些資源用于其他服務(wù)。

由于它們的重要性，我們可以在一定程度上容忍屬于任務(wù)1和2的pod對(duì)誤報(bào)做出響應(yīng)。畢竟，浪費(fèi)一些資源比失去客戶要更好。

服務(wù)于任務(wù)3的pod不需要特別地安排，因?yàn)樗鼈儼凑粘Ｒ?guī)的方式擴(kuò)展和縮小即可。

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

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

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

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

在Windows上支持Containerd 1.3

當(dāng)我們談?wù)摗癒ubernetes”時(shí)，我們幾乎第一時(shí)間想到的是Linux。即使在教程、大部分的書籍和文獻(xiàn)中也普遍將Linux視為運(yùn)行Kubernetes的事實(shí)上的操作系統(tǒng)。

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

在同一集群中支持RuntimeClass和多個(gè)Windows版本的標(biāo)簽

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

跳過(guò)Volume所有權(quán)更改

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

• 某些應(yīng)用程序（如數(shù)據(jù)庫(kù)）對(duì)文件許可權(quán)和所有權(quán)修改很敏感。裝入volume后，這些應(yīng)用程序可能會(huì)停止啟動(dòng)。

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

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

允許Secret和ConfigMap不可變

在Kubernetes早期，我們就已經(jīng)使用ConfigMap來(lái)將配置數(shù)據(jù)注入到我們的容器中。如果數(shù)據(jù)十分敏感，那么則會(huì)使用Secret。將數(shù)據(jù)呈現(xiàn)給容器最常見(jiàn)的方式是通過(guò)掛載一個(gè)包含數(shù)據(jù)的文件。但是，當(dāng)對(duì)ConfigMap或Secret進(jìn)行更改時(shí)，此更改將會(huì)立刻傳遞到安裝了該配置文件的所有pod。也許這并不是將更改應(yīng)用于正在運(yùn)行的集群的最佳方式。因?yàn)槿绻屡渲糜袉?wèn)題，我們將面臨停止運(yùn)行應(yīng)用程序的風(fēng)險(xiǎn)。

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

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

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

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

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

使用修改后的PodSpec重新就地啟動(dòng)Pod。這使你可以進(jìn)行諸如更改容器的源鏡像或權(quán)限之類的操作。

你甚至可以在主機(jī)命名空間中啟動(dòng)特權(quán)容器。這使你可以對(duì)節(jié)點(diǎn)問(wèn)題進(jìn)行故障排除。

到此，相信大家對(duì)“升級(jí)Kubernetes 1.18前要注意哪些問(wèn)題”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

新聞標(biāo)題：升級(jí)Kubernetes1.18前要注意哪些問(wèn)題
本文地址：http://chinadenli.net/article16/poopgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、標(biāo)簽優(yōu)化、用戶體驗(yàn)、網(wǎng)站營(yíng)銷、網(wǎng)站改版、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)