Pod 一直處于Pending狀態(tài)？可能是拓?fù)浼s束的問題
Sealos 公眾號(hào)已接入了 GPT-4，完全免費(fèi)！歡迎前來調(diào)戲??
?原文鏈接：https://juejin.cn/post/7245179553886486584
起因：今天在部署組件的時(shí)候，發(fā)現(xiàn)組件的 pod 一直處于 Pending 狀態(tài)，報(bào)錯(cuò)顯示的原因是：不滿足 Pod 拓?fù)浞植技s束，看了代碼發(fā)現(xiàn)是原來同事給組件新增了 Pod 拓?fù)浼s束。對(duì)于 Pod 拓?fù)浼s束，我先前并沒有認(rèn)真了解過，剛好可以借這個(gè)排查問題的機(jī)會(huì)深入了解什么是 Pod 拓?fù)浼s束。
?文檔參考：
kubernetes.io/zh-cn/docs/…[1]
文檔參考主要是上述兩篇 k8s 官方的文檔，建議英文功底好的可以直接看第二篇文檔。
API 定義
topologySpreadConstraints 是一個(gè) Pod Spec 層級(jí)的字段，其定義的結(jié)構(gòu)體如下：
spec:
??topologySpreadConstraints:
??-?maxSkew:?
????topologyKey:?
????whenUnsatisfiable:?
????labelSelector:?
在官方文檔里還描述了許多 beta 特性的字段，但如果是剛上手 Pod 拓?fù)浼s束的小伙伴，可以從這上面的四個(gè)基本字段入手，先把這四個(gè)字段的含義吃透。
labelSelector：labelSelector 是用來尋找匹配標(biāo)簽的 Pod，對(duì)于每一個(gè)拓?fù)溆騺碚f，k8s 調(diào)度器會(huì)計(jì)算其中匹配 labelSelector 的 Pod 數(shù)量。在上圖中，我們定義的拓?fù)浼s束只針對(duì)含有 label app=foo 的 Pod 生效。 topologyKey：topologyKey 用于一個(gè)拓?fù)溆颍@個(gè)值通常情況下是定義在節(jié)點(diǎn)上的標(biāo)簽。在上圖中，我們定義的拓?fù)溆蚓褪?zone，也就是含有 zone 這個(gè) label 的節(jié)點(diǎn)才算在我們的拓?fù)溆蛑小?/section> maxSkew：maxSkew 指的就是 Pod 分布在不同的拓?fù)溆蛑械臄?shù)量差異。maxSkew 要求其設(shè)定的值大于 0，其值越小，說明我們期望 Pod 能夠越均衡地打散分布在拓?fù)溆蛑校渲翟酱螅瑒t反之。在上圖中，如果新的 Pod 調(diào)度到 Zone1 中，則 Zone1 和 Zone2 的 skew 就是 3-0=3，如果新的 Pod 調(diào)度到 Zone2 中，則 Zone1 和 Zone2 的 skew 就是 2-1=1. whenUnsatisfiable：whenUnsatisfiable 指當(dāng) skew 不滿足 maxSkew 時(shí)，調(diào)度器會(huì)執(zhí)行的動(dòng)作，可選值為： DoNotSchedule：（默認(rèn)值）不調(diào)度。 ScheduleAnyway：仍然調(diào)度，但會(huì)趨向于調(diào)度到使 skew 最小的拓?fù)溆蛑小?/section>
了解到這里，我就已經(jīng)排查出來調(diào)度不上去的原因了：集群是一個(gè)兩節(jié)點(diǎn)的集群（1master+1worker），但這兩個(gè)節(jié)點(diǎn)屬于同一個(gè)可用區(qū)，但有一點(diǎn)奇怪的是，按照算法，應(yīng)該會(huì)有一個(gè) Pod 調(diào)度上去，另一個(gè) Pod 處于 Pending 狀態(tài)，但現(xiàn)實(shí)卻是兩個(gè) Pod 都處于 Pending 狀態(tài)。繼續(xù)看代碼，我發(fā)現(xiàn)了同事不僅用了 topologySpreadConstraints，還結(jié)合了親和性反親和性一起使用。
拓?fù)浞植技s束 and 親和性反親和性
Pod 拓?fù)浼s束可以結(jié)合親和和反親和特性一起使用，達(dá)到更豐富的效果，以實(shí)際業(yè)務(wù)場(chǎng)景中的代碼為例：
????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
可以看到，我們?cè)O(shè)置了 Pod ?反親和性，禁止符合條件的 Pod 調(diào)度到同一個(gè)節(jié)點(diǎn)上（可能是出于容災(zāi)或其他方面的考慮），再看 Pod 拓?fù)浼s束，要求 Pod 均勻地分布在每個(gè)可用區(qū)中，且每個(gè)可用區(qū)之間符合條件的 Pod 的數(shù)量差值最大為 1，如果不滿足的條件下，禁止調(diào)度。（強(qiáng)打散 Pod 到每個(gè)可用區(qū)中，可能是出于網(wǎng)絡(luò)帶寬，cpu 內(nèi)存等資源角度的考慮）。
因此，在僅有兩個(gè)節(jié)點(diǎn)的集群中，且這兩個(gè)節(jié)點(diǎn)還是屬于同一個(gè)可用區(qū)的情況下，無(wú)法滿足上述的調(diào)度條件，因此兩個(gè) Pod 均處于 Pending 狀態(tài)。
?解決方式有兩種，可以設(shè)置 maxSkew 的值為 2，或者設(shè)置 whenUnsatisfiable 的值為 ScheduleAnyway。
引用鏈接
kubernetes.io/zh-cn/docs/…: https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/
關(guān)于 Sealos
Sealos 是一款以 Kubernetes 為內(nèi)核的云操作系統(tǒng)發(fā)行版。它以云原生的方式，拋棄了傳統(tǒng)的云計(jì)算架構(gòu)，轉(zhuǎn)向以 Kubernetes 為云內(nèi)核的新架構(gòu)，使企業(yè)能夠像使用個(gè)人電腦一樣簡(jiǎn)單地使用云。
??GitHub：https://github.com/labring/sealos
??官網(wǎng)：https://sealos.io
??開發(fā)者論壇：https://forum.laf.run
關(guān)注 Sealos?公眾號(hào)與我們一同成長(zhǎng)??????