如何排查K8s Scheduler在調(diào)度pod過程中遺漏部分節(jié)點的問題

158次閱讀

共計 4126 個字符，預(yù)計需要花費(fèi) 11 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“如何排查 K8s Scheduler 在調(diào)度 pod 過程中遺漏部分節(jié)點的問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓丸趣 TV 小編來帶大家學(xué)習(xí)“如何排查 K8s Scheduler 在調(diào)度 pod 過程中遺漏部分節(jié)點的問題”吧!

問題現(xiàn)象

在 TKE 控制臺上新建版本為 v1.18.4（詳細(xì)版本號 v1.18.4-tke.5）的獨(dú)立集群，其中，集群的節(jié)點信息如下：

有 3 個 master node 和 1 個 worker node，并且 worker 和 master 在不同的可用區(qū)。

node 角色 label 信息 ss-stg-ma-01masterlabel[failure-domain.beta.kubernetes.io/region=sh,failure-domain.beta.kubernetes.io/zone=200002]ss-stg-ma-02masterlabel[failure-domain.beta.kubernetes.io/region=sh,failure-domain.beta.kubernetes.io/zone=200002]ss-stg-ma-03masterlabel[failure-domain.beta.kubernetes.io/region=sh,failure-domain.beta.kubernetes.io/zone=200002]ss-stg-test-01workerlabel[failure-domain.beta.kubernetes.io/region=sh,failure-domain.beta.kubernetes.io/zone=200004]

待集群創(chuàng)建好之后，再創(chuàng)建出一個 daemonset 對象，會出現(xiàn) daemonset 的某個 pod 一直卡住 pending 狀態(tài)的現(xiàn)象。現(xiàn)象如下：

$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE NODE 
debug-4m8lc 1/1 Running 1 89m ss-stg-ma-01
debug-dn47c 0/1 Pending 0 89m  none 
debug-lkmfs 1/1 Running 1 89m ss-stg-ma-02
debug-qwdbc 1/1 Running 1 89m ss-stg-test-01

（補(bǔ)充：TKE 當(dāng)前支持的最新版本號為 v1.18.4-tke.8，新建集群默認(rèn)使用最新版本）

問題結(jié)論

k8s 的調(diào)度器在調(diào)度某個 pod 時，會從調(diào)度器的內(nèi)部 cache 中同步一份快照（snapshot），其中保存了 pod 可以調(diào)度的 node 信息。上面問題（daemonset 的某個 pod 實例卡在 pending 狀態(tài)）的原因就是同步的過程發(fā)生了部分 node 信息丟失，導(dǎo)致了 daemonset 的部分 pod 實例無法調(diào)度到指定的節(jié)點上，卡在了 pending 狀態(tài)。

接下來是詳細(xì)的排查過程。

日志排查

截圖中出現(xiàn)的節(jié)點信息（來自客戶線上集群）：k8s master 節(jié)點：ss-stg-ma-01、ss-stg-ma-02、ss-stg-ma-03 k8s worker 節(jié)點：ss-stg-test-01

1、獲取調(diào)度器的日志這里首先是通過動態(tài)調(diào)大調(diào)度器的日志級別，比如，直接調(diào)大到 V(10)，嘗試獲取一些相關(guān)日志。當(dāng)日志級別調(diào)大之后，有抓取到一些關(guān)鍵信息，信息如下：

解釋一下，當(dāng)調(diào)度某個 pod 時，有可能會進(jìn)入到調(diào)度器的搶占 preempt 環(huán)節(jié)，而上面的日志就是出自于搶占環(huán)節(jié)。集群中有 4 個節(jié)點（3 個 master node 和 1 個 worker node），但是日志中只顯示了 3 個節(jié)點，缺少了一個 master 節(jié)點。所以，這里暫時懷疑下是調(diào)度器內(nèi)部緩存 cache 中少了 node info。

2、獲取調(diào)度器內(nèi)部 cache 信息 k8s v1.18 已經(jīng)支持打印調(diào)度器內(nèi)部的緩存 cache 信息。打印出來的調(diào)度器內(nèi)部緩存 cache 信息如下：

可以看出，調(diào)度器的內(nèi)部緩存 cache 中的 node info 是完整的（3 個 master node 和 1 個 worker node）。通過分析日志，可以得到一個初步結(jié)論：調(diào)度器內(nèi)部緩存 cache 中的 node info 是完整的，但是當(dāng)調(diào)度 pod 時，緩存 cache 中又會缺少部分 node 信息。

問題根因

在進(jìn)一步分析之前，我們先一起再熟悉下調(diào)度器調(diào)度 pod 的流程（部分展示）和 nodeTree 數(shù)據(jù)結(jié)構(gòu)。

pod 調(diào)度流程（部分展示）

結(jié)合上圖，一次 pod 的調(diào)度過程就是一次 Scheduler Cycle。在這個 Cycle 開始時，第一步就是 update snapshot。snapshot 我們可以理解為 cycle 內(nèi)的 cache，其中保存了 pod 調(diào)度時所需的 node info，而 update snapshot，就是一次 nodeTree（調(diào)度器內(nèi)部 cache 中保存的 node 信息）到 snapshot 的同步過程。而同步過程主要是通過 nodeTree.next() 函數(shù)來實現(xiàn)，函數(shù)邏輯如下：

// next returns the name of the next node. NodeTree iterates over zones and in each zone iterates
// over nodes in a round robin fashion.
func (nt *nodeTree) next() string {if len(nt.zones) == 0 {
 return  
 numExhaustedZones := 0
 for {if nt.zoneIndex  = len(nt.zones) {
 nt.zoneIndex = 0
 zone := nt.zones[nt.zoneIndex]
 nt.zoneIndex++
 // We do not check the exhausted zones before calling next() on the zone. This ensures
 // that if more nodes are added to a zone after it is exhausted, we iterate over the new nodes.
 nodeName, exhausted := nt.tree[zone].next()
 if exhausted {
 numExhaustedZones++
 if numExhaustedZones  = len(nt.zones) { // all zones are exhausted. we should reset.
 nt.resetExhausted()} else {return nodeName}

再結(jié)合上面排查過程得出的結(jié)論，我們可以再進(jìn)一步縮小問題范圍：nodeTree（調(diào)度器內(nèi)部 cache）到的同步過程丟失了某個節(jié)點信息。

### nodeTree 數(shù)據(jù)結(jié)構(gòu)（方便理解，本文使用了鏈表來展示）

在 nodeTree 數(shù)據(jù)結(jié)構(gòu)中，有兩個游標(biāo) zoneIndex 和 lastIndex（zone 級別），用來控制 nodeTree（調(diào)度器內(nèi)部 cache）到 snapshot.nodeInfoList 的同步過程。并且，重要的一點是：上次同步后的游標(biāo)值會被記錄下來，用于下次同步過程的初始值。

### 重現(xiàn)問題，定位根因

創(chuàng)建 k8s 集群時，會先加入 master node，然后再加入 worker node（意思是 worker node 時間上會晚于 master node 加入集群的時間）。

第一輪同步：3 臺 master node 創(chuàng)建好，然后發(fā)生 pod 調(diào)度（比如，cni 插件，以 daemonset 的方式部署在集群中），會觸發(fā)一次 nodeTree（調(diào)度器內(nèi)部 cache）到的同步。同步之后，nodeTree 的兩個游標(biāo)就變成了如下結(jié)果：

nodeTree.zoneIndex = 1,
nodeTree.nodeArray[sh:200002].lastIndex = 3,

第二輪同步：當(dāng) worker node 加入集群中后，然后新建一個 daemonset，就會觸發(fā)第二輪的同步（nodeTree（調(diào)度器內(nèi)部 cache）到的同步）。同步過程如下：

1、zoneIndex=1, nodeArray[sh:200004].lastIndex=0, we get ss-stg-test-01.

2、zoneIndex=2 = len(zones); zoneIndex=0, nodeArray[sh:200002].lastIndex=3, return.

3、zoneIndex=1, nodeArray[sh:200004].lastIndex=1, return.

4、zoneIndex=0, nodeArray[sh:200002].lastIndex=0, we get ss-stg-ma-01.

5、zoneIndex=1, nodeArray[sh:200004].lastIndex=0, we get ss-stg-test-01.

6、zoneIndex=2 = len(zones); zoneIndex=0, nodeArray[sh:200002].lastIndex=1, we get ss-stg-ma-02.

同步完成之后，調(diào)度器的 snapshot.nodeInfoList 得到如下的結(jié)果：

[
 ss-stg-test-01,
 ss-stg-ma-01,
 ss-stg-test-01,
 ss-stg-ma-02,
]

ss-stg-ma-03 去哪了？在第二輪同步的過程中丟了。

解決方案

從問題根因的分析中，可以看出，導(dǎo)致問題發(fā)生的原因，在于 nodeTree 數(shù)據(jù)結(jié)構(gòu)中的游標(biāo) zoneIndex 和 lastIndex（zone 級別）值被保留了，所以，解決的方案就是在每次同步 SYNC 時，強(qiáng)制重置游標(biāo)（歸 0）。

到此，相信大家對“如何排查 K8s Scheduler 在調(diào)度 pod 過程中遺漏部分節(jié)點的問題”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

正文完