k8s kubelet 狀態(tài)更新機(jī)制

場(chǎng)景：

當(dāng) Kubernetes 中 Node 節(jié)點(diǎn)出現(xiàn)狀態(tài)異常的情況下，節(jié)點(diǎn)上的 Pod 會(huì)被重新調(diào)度到其他節(jié)點(diǎn)上去，但是有的時(shí)候我們會(huì)發(fā)現(xiàn)節(jié)點(diǎn) Down 掉以后，Pod 并不會(huì)立即觸發(fā)重新調(diào)度，這實(shí)際上就是和 Kubelet 的狀態(tài)更新機(jī)制密切相關(guān)的，Kubernetes 提供了一些參數(shù)配置來(lái)觸發(fā)重新調(diào)度的時(shí)間

kubelet 狀態(tài)更新的基本流程：

• 1、kubelet 自身會(huì)定期更新狀態(tài)到 apiserver，通過參數(shù)–node-status-update-frequency指定上報(bào)頻率，默認(rèn)是 10s 上報(bào)一次。
• 2、kube-controller-manager 會(huì)每隔–node-monitor-period時(shí)間去檢查 kubelet 的狀態(tài)，默認(rèn)是 5s。
• 3、當(dāng) node 失聯(lián)一段時(shí)間后，kubernetes 判定 node 為 notready 狀態(tài)，這段時(shí)長(zhǎng)通過–node-monitor-grace-period參數(shù)配置，默認(rèn) 40s。
• 4、當(dāng) node 失聯(lián)一段時(shí)間后，kubernetes 判定 node 為 unhealthy 狀態(tài)，這段時(shí)長(zhǎng)通過–node-startup-grace-period參數(shù)配置，默認(rèn) 1m0s。
• 5、當(dāng) node 失聯(lián)一段時(shí)間后，kubernetes 開始刪除原 node 上的 pod，這段時(shí)長(zhǎng)是通過–pod-eviction-timeout參數(shù)配置，默認(rèn) 5m0s。

kube-controller-manager 和 kubelet 是異步工作的，這意味著延遲可能包括任何的網(wǎng)絡(luò)延遲、apiserver 的延遲、etcd 延遲，一個(gè)節(jié)點(diǎn)上的負(fù)載引起的延遲等等。因此，如果–node-status-update-frequency設(shè)置為 5s，那么實(shí)際上 etcd 中的數(shù)據(jù)變化會(huì)需要 6-7s，甚至更長(zhǎng)時(shí)間。

注意：

• kubelet 在更新狀態(tài)失敗時(shí)，會(huì)進(jìn)行nodeStatusUpdateRetry次重試，默認(rèn)為 5 次。

• kubelet 會(huì)在函數(shù)tryUpdateNodeStatus中嘗試進(jìn)行狀態(tài)更新。Kubelet 使用了 Golang 中的http.Client()方法，但是沒有指定超時(shí)時(shí)間，因此，如果 API Server 過載時(shí)，當(dāng)建立 TCP 連接時(shí)可能會(huì)出現(xiàn)一些故障。

• 因此，在nodeStatusUpdateRetry * --node-status-update-frequency時(shí)間后才會(huì)更新一次節(jié)點(diǎn)狀態(tài)。

• 同時(shí)，Kubernetes 的 controller manager 將嘗試每–node-monitor-period時(shí)間周期內(nèi)檢查nodeStatusUpdateRetry次。在–node-monitor-grace-period之后，會(huì)認(rèn)為節(jié)點(diǎn) unhealthy，然后會(huì)在–pod-eviction-timeout后刪除 Pod。

• kube proxy 有一個(gè) watcher API，一旦 Pod 被驅(qū)逐了，kube proxy 將會(huì)通知更新節(jié)點(diǎn)的 iptables 規(guī)則，將 Pod 從 Service 的 Endpoints 中移除，這樣就不會(huì)訪問到來(lái)自故障節(jié)點(diǎn)的 Pod 了。

如何配置：

對(duì)于這些參數(shù)的配置，需要根據(jù)不通的集群規(guī)模場(chǎng)景來(lái)進(jìn)行配置。

社區(qū)默認(rèn)的配置：

• –node-status-update-frequency 10s
• –node-monitor-period 5s
• –node-monitor-grace-period 40s
• –pod-eviction-timeout 5m

快速更新和快速響應(yīng)：

• –node-status-update-frequency 4s
• –node-monitor-period 2s
• –node-monitor-grace-period 20s
• –pod-eviction-timeout 30s

在這種情況下，Pod 將在 50s 被驅(qū)逐，因?yàn)樵摴?jié)點(diǎn)在 20s 后被視為 Down 掉了，–pod-eviction-timeout在 30s 之后發(fā)生，但是，這種情況會(huì)給 etcd 產(chǎn)生很大的開銷，因?yàn)槊總€(gè)節(jié)點(diǎn)都會(huì)嘗試每 2s 更新一次狀態(tài)。

如果環(huán)境有 1000 個(gè)節(jié)點(diǎn)，那么每分鐘將有 15000 次節(jié)點(diǎn)更新操作，這可能需要大型 etcd 容器甚至是 etcd 的專用節(jié)點(diǎn)。

如果我們計(jì)算嘗試次數(shù)，則除法將給出 5，但實(shí)際上每次嘗試的 nodeStatusUpdateRetry 嘗試將從 3 到 5。 由于所有組件的延遲，嘗試總次數(shù)將在 15 到 25 之間變化。

中等更新和平均響應(yīng)：

• –node-status-update-frequency 20s
• –node-monitor-period 5s
• –node-monitor-grace-period 2m
• –pod-eviction-timeout 1m

這種場(chǎng)景下會(huì) 20s 更新一次 node 狀態(tài)，controller manager 認(rèn)為 node 狀態(tài)不正常之前，會(huì)有 2m60/205=30 次的 node 狀態(tài)更新，Node 狀態(tài)為 down 之后 1m，就會(huì)觸發(fā)驅(qū)逐操作。

如果有 1000 個(gè)節(jié)點(diǎn)，1 分鐘之內(nèi)就會(huì)有 60s/20s*1000=3000 次的節(jié)點(diǎn)狀態(tài)更新操作。

低更新和慢響應(yīng)：

• –node-status-update-frequency 1m
• –node-monitor-period 5s
• –node-monitor-grace-period 5m
• –pod-eviction-timeout 1m

Kubelet 將會(huì) 1m 更新一次節(jié)點(diǎn)的狀態(tài)，在認(rèn)為不健康之后會(huì)有 5m/1m*5=25 次重試更新的機(jī)會(huì)。Node 為不健康的時(shí)候，1m 之后 pod 開始被驅(qū)逐。

更多細(xì)節(jié)參考官方文檔：

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-645621.html

到了這里，關(guān)于【博客694】k8s kubelet 狀態(tài)更新機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！