Pod一直處于Pending狀態(tài)？什么是Pod拓撲約束？
起因： 今天在部署組件的時候，發(fā)現(xiàn)組件的pod一直處于Pending狀態(tài)，報錯顯示的原因是：不滿足Pod拓撲分布約束，看了代碼發(fā)現(xiàn)是原來同事給組件新增了Pod拓撲約束。對于Pod拓撲約束，我先前并沒有認真了解過，剛好可以借這個排查問題的機會深入了解什么是Pod拓撲約束。
文檔參考主要是上述兩篇k8s官方的文檔，建議英文功底好的可以直接看第二篇文檔。
topologySpreadConstraints是一個Pod Spec層級的字段，其定義的結(jié)構(gòu)體如下：
spec: topologySpreadConstraints: - maxSkew:topologyKey: whenUnsatisfiable: labelSelector:
在官方文檔里還描述了許多beta特性的字段，但如果是剛上手Pod拓撲約束的小伙伴，可以從這上面的四個基本字段入手，先把這四個字段的含義吃透。
labelSelector：labelSelector是用來尋找匹配標簽的Pod，對于每一個拓撲域來說，k8s調(diào)度器會計算其中匹配labelSelector的Pod數(shù)量。在上圖中，我們定義的拓撲約束只針對含有l(wèi)abel app=foo的Pod生效。
topologyKey：topologyKey用于一個拓撲域，這個值通常情況下是定義在節(jié)點上的標簽。在上圖中，我們定義的拓撲域就是zone，也就是含有zone這個label的節(jié)點才算在我們的拓撲域中。
maxSkew：maxSkew指的就是Pod分布在不同的拓撲域中的數(shù)量差異。maxSkew要求其設(shè)定的值大于0，其值越小，說明我們期望Pod能夠越均衡地打散分布在拓撲域中，其值越大，則反之。在上圖中，如果新的Pod調(diào)度到Zone1中，則Zone1和Zone2的skew就是3-0=3，如果新的Pod調(diào)度到Zone2中，則Zone1和Zone2的skew就是2-1=1.
whenUnsatisfiable：whenUnsatisfiable指當skew不滿足maxSkew時，調(diào)度器會執(zhí)行的動作，可選值為：
DoNotSchedule：（默認值）不調(diào)度。
ScheduleAnyway：仍然調(diào)度，但會趨向于調(diào)度到使skew最小的拓撲域中。
了解到這里，我就已經(jīng)排查出來調(diào)度不上去的原因了：集群是一個兩節(jié)點的集群（1master+1worker），但這兩個節(jié)點屬于同一個可用區(qū)，但有一點奇怪的是，按照算法，應(yīng)該會有一個Pod調(diào)度上去，另一個Pod處于Pending狀態(tài)，但現(xiàn)實卻是兩個Pod都處于Pending狀態(tài)。繼續(xù)看代碼，我發(fā)現(xiàn)了同事不僅用了topologySpreadConstraints，還結(jié)合了親和性反親和性一起使用。
Pod拓撲約束可以結(jié)合親和和反親和特性一起使用，達到更豐富的效果，以實際業(yè)務(wù)場景中的代碼為例：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: app-server
topologyKey: kubernetes.io/hostname
schedulerName: default-scheduler
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedulable
labelSelector:
matchLabels:
app.kubernetes.io/instance: app-server
app.kubernetes.io/name: app-server
可以看到，我們設(shè)置了Pod 反親和性，禁止符合條件的Pod調(diào)度到同一個節(jié)點上（可能是出于容災(zāi)或其他方面的考慮），再看Pod拓撲約束，要求Pod均勻地分布在每個可用區(qū)中，且每個可用區(qū)之間符合條件的Pod的數(shù)量差值最大為1，如果不滿足的條件下，禁止調(diào)度。（強打散Pod到每個可用區(qū)中，可能是出于網(wǎng)絡(luò)帶寬，cpu內(nèi)存等資源角度的考慮）。
因此，在僅有兩個節(jié)點的集群中，且這兩個節(jié)點還是屬于同一個可用區(qū)的情況下，無法滿足上述的調(diào)度條件，因此兩個Pod均處于Pending狀態(tài)。
解決方式有兩種，可以設(shè)置maxSkew的值為2，或者設(shè)置whenUnsatisfiable的值為ScheduleAnyway。
鏈接：https://juejin.cn/post/7245179553886486584
審核編輯：劉清
-
SPEC
+關(guān)注
關(guān)注
0文章
31瀏覽量
15845 -
POD
+關(guān)注
關(guān)注
0文章
18瀏覽量
6050 -
調(diào)度器
+關(guān)注
關(guān)注
0文章
98瀏覽量
5298
原文標題：Pod一直處于Pending狀態(tài)？可以看一下是不是拓撲約束的問題
文章出處：【微信號：magedu-Linux，微信公眾號：馬哥Linux運維】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
LDC1614EVM一直處于紅燈狀態(tài)，為什么？
從零開始入門 K8s| 詳解 Pod 及容器設(shè)計模式
Kubernetes組件pod核心原理
pod底層網(wǎng)絡(luò)和數(shù)據(jù)存儲是如何進行的
word文檔如何解密
如何利用Docker實現(xiàn)Pod
Kubernetes中的Pod簡易理解
什么是CNI，基于Calico的Pod網(wǎng)絡(luò)介紹
k8s與pod之間是如何進行網(wǎng)絡(luò)隔離的？
iOS中Pod庫資源引用探究
POD到底是什么？聊聊POD
如何快速查看Kubernetes Pod崩潰前的日志
Pod是如何在底層實現(xiàn)的？如何使用Docker創(chuàng)建Pod？
工商網(wǎng)監(jiān)
評論