1.1 驅(qū)逐到底是什么

驅(qū)逐這個概念在k8s中個人理解有兩種場景：apiserver端的Pod驅(qū)逐接口和kubelet里面的驅(qū)逐管理器，兩者雖然都有類似的evictPod的操作，但本質(zhì)上卻根本不是一個東西, 在kubelet里面的驅(qū)逐最終會調(diào)用runtime來kill掉正在運行的容器, 而apiserver端的接口則是直接在etcd里面刪除對應(yīng)的Pod, 也是PDB真正起作用的地方, 本文后面的驅(qū)逐都是指的apiserver端的接口

1.2 Drain

drain是k8s用于維護(hù)節(jié)點擴(kuò)容的時候的一個命令，事實上默認(rèn)在k8s中也就只有該命令會進(jìn)行驅(qū)逐接口的調(diào)用了

1.3 Pod中斷預(yù)算

Pod中斷預(yù)算名字很直白但看介紹是真復(fù)雜， 其實簡單來說可以分為兩部分：中斷和預(yù)算，預(yù)算其實很容易理解，就跟大家平?；ㄥX一樣，有多少預(yù)算買多少錢的東西，這里的預(yù)算也是一樣，不過這里的預(yù)算是你可以進(jìn)行操作的數(shù)量，比如你允許某個資源的最多10%的Pod宕機(jī)，它就會根據(jù)你當(dāng)前的狀態(tài)和你的預(yù)算來計算出，你可以中斷多少機(jī)器那什么是中斷呢？答案就是刪除對應(yīng)的操作其實就是刪除對應(yīng)的Pod, 整合在一起其實就是根據(jù)你當(dāng)前的狀態(tài)計算出你可以進(jìn)行刪除Pod操作的數(shù)量

好了基礎(chǔ)概念就介紹到這里，下面開始其實現(xiàn)的探索

2. 核心實現(xiàn)

2.1 PDB的計算數(shù)據(jù)

我們上面提到了PDB的本質(zhì)就是計算允許進(jìn)行刪除操作的數(shù)量，那要進(jìn)行這種計算需要那些數(shù)據(jù)呢？首先我們需要一個PDB(預(yù)算)，然后我們需要當(dāng)前Pod的狀態(tài)(通過selector)這部分是不是夠了呢？答案肯定不是，還缺什么呢？就是我們上面提到的total，即該P(yáng)od當(dāng)前集群中期望有幾個，如何獲取呢？其實這個對應(yīng)的就是對應(yīng)的上層資源，比如Deployment、ReplicaSet、StatefulSet等，我們需要渠道對應(yīng)上層資源期望的Pod的數(shù)量，也就是我們的total

2.2 上層資源的關(guān)聯(lián)

那么如何我才能知道我Pod的管理的上層控制器具體是誰呢？答案其實就是Controlled By字段我們可以獲取對應(yīng)的ownerReferences這樣我們就可以知道上層的控制器是誰，然后我們就可以從對應(yīng)控制器字段里面取出對應(yīng)的期望的數(shù)量

2.3 中斷有效時間

中斷有效時間這個名字我感覺很貼切，官方的名字叫DeletionTImeout，因為在k8s里面控制器和apiserver是可以分開的兩個組件，上面我提到了驅(qū)逐接口會接收到驅(qū)逐請求，那怎么把這種驅(qū)逐的Pod傳遞給PDB呢因為他要計算還可以繼續(xù)驅(qū)逐多少，除了當(dāng)前的Pod和期望的Pod數(shù)量之外，也肯定需要知道當(dāng)前還可以繼續(xù)已經(jīng)被中斷(正在進(jìn)行驅(qū)逐的)的數(shù)量

如果因為集群的不穩(wěn)定造成PDB過了很久才收到這條消息，實際上對應(yīng)的請求可能早就已經(jīng)失效了，則對應(yīng)的被驅(qū)逐的Pod實際上并沒有被驅(qū)逐計算的時候還依舊將其計算在內(nèi)，則可能會影響后續(xù)的驅(qū)逐操作，所以為了解決這種延遲和不同步問題，才有了中斷有效時間，默認(rèn)是2分鐘，過期后就會自動刪除，并且計算的時候就會跳過該P(yáng)od

2.4 整體實現(xiàn)大揭秘

控制整體實現(xiàn)分為如下幾個大的步驟：1.用戶定義PDB要保護(hù)的資源2.controller感知資源然后計算PDB對應(yīng)的數(shù)據(jù)3.eviction接口接收到驅(qū)逐請求后,檢測PDB是否允許，如果允許就更新中斷的Pod到PDB的DisruptedPods字段中4.PDB感知到更新之后，重新進(jìn)行計算更新PDB，這樣eviction下次接收到驅(qū)逐請求之后就可以使用，反反復(fù)復(fù)