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