建站
咨詢
售后
建站咨詢
新聞中心
Pod 優(yōu)先級和搶占
FEATURE STATE: Kubernetes v1.14 [stable]
專業(yè)從事成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè),高端網(wǎng)站制作設(shè)計,微信小程序定制開發(fā),網(wǎng)站推廣的成都做網(wǎng)站的公司。優(yōu)秀技術(shù)團(tuán)隊竭力真誠服務(wù)，采用成都h5網(wǎng)站建設(shè)+CSS3前端渲染技術(shù)，成都響應(yīng)式網(wǎng)站建設(shè)公司，讓網(wǎng)站在手機(jī)、平板、PC、微信下都能呈現(xiàn)。建站過程建立專項小組，與您實(shí)時在線互動，隨時提供解決方案，暢聊想法和感受。
Pod 可以有 優(yōu)先級。 優(yōu)先級表示一個 Pod 相對于其他 Pod 的重要性。 如果一個 Pod 無法被調(diào)度，調(diào)度程序會嘗試搶占（驅(qū)逐）較低優(yōu)先級的 Pod， 以使懸決 Pod 可以被調(diào)度。
Warning:
在一個并非所有用戶都是可信的集群中，惡意用戶可能以最高優(yōu)先級創(chuàng)建 Pod， 導(dǎo)致其他 Pod 被驅(qū)逐或者無法被調(diào)度。 管理員可以使用 ResourceQuota 來阻止用戶創(chuàng)建高優(yōu)先級的 Pod。
如何使用優(yōu)先級和搶占
要使用優(yōu)先級和搶占：
- 新增一個或多個 PriorityClass。
- 創(chuàng)建 Pod，并將其 ?
priorityClassName?設(shè)置為新增的 PriorityClass。 當(dāng)然你不需要直接創(chuàng)建 Pod；通常，你將會添加 ?priorityClassName?到集合對象（如 Deployment） 的 Pod 模板中。
Note:
Kubernetes 已經(jīng)提供了 2 個 PriorityClass： ?
system-cluster-critical? 和 ?
system-node-critical?。 這些是常見的類，用于確保始終優(yōu)先調(diào)度關(guān)鍵組件。
PriorityClass
PriorityClass 是一個無名稱空間對象，它定義了從優(yōu)先級類名稱到優(yōu)先級整數(shù)值的映射。 名稱在 PriorityClass 對象元數(shù)據(jù)的 ?name ?字段中指定。 值在必填的 ?value ?字段中指定。值越大，優(yōu)先級越高。 PriorityClass 對象的名稱必須是有效的 DNS 子域名， 并且它不能以 ?system-? 為前綴。
PriorityClass 對象可以設(shè)置任何小于或等于 10 億的 32 位整數(shù)值。 較大的數(shù)字是為通常不應(yīng)被搶占或驅(qū)逐的關(guān)鍵的系統(tǒng) Pod 所保留的。 集群管理員應(yīng)該為這類映射分別創(chuàng)建獨(dú)立的 PriorityClass 對象。
PriorityClass 還有兩個可選字段：?globalDefault ?和 ?description?。 ?globalDefault ?字段表示這個 PriorityClass 的值應(yīng)該用于沒有 ?priorityClassName ?的 Pod。 系統(tǒng)中只能存在一個 ?globalDefault ?設(shè)置為 true 的 PriorityClass。 如果不存在設(shè)置了 ?globalDefault ?的 PriorityClass， 則沒有 ?priorityClassName ?的 Pod 的優(yōu)先級為零。
?description ?字段是一個任意字符串。 它用來告訴集群用戶何時應(yīng)該使用此 PriorityClass。
關(guān)于 PodPriority 和現(xiàn)有集群的注意事項
- 如果你升級一個已經(jīng)存在的但尚未使用此特性的集群，該集群中已經(jīng)存在的 Pod 的優(yōu)先級等效于零。
- 添加一個將 ?
globalDefault?設(shè)置為 ?true?的 PriorityClass 不會改變現(xiàn)有 Pod 的優(yōu)先級。 此類 PriorityClass 的值僅用于添加 PriorityClass 后創(chuàng)建的 Pod。 - 如果你刪除了某個 PriorityClass 對象，則使用被刪除的 PriorityClass 名稱的現(xiàn)有 Pod 保持不變， 但是你不能再創(chuàng)建使用已刪除的 PriorityClass 名稱的 Pod。
PriorityClass 示例
apiVersion: scheduling.K8S.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000000
globalDefault: false
description: "此優(yōu)先級類應(yīng)僅用于 XYZ 服務(wù) Pod。"非搶占式 PriorityClass
FEATURE STATE: Kubernetes v1.24 [stable]
配置了 ?preemptionPolicy: Never? 的 Pod 將被放置在調(diào)度隊列中較低優(yōu)先級 Pod 之前， 但它們不能搶占其他 Pod。等待調(diào)度的非搶占式 Pod 將留在調(diào)度隊列中，直到有足夠的可用資源， 它才可以被調(diào)度。非搶占式 Pod，像其他 Pod 一樣，受調(diào)度程序回退的影響。 這意味著如果調(diào)度程序嘗試這些 Pod 并且無法調(diào)度它們，它們將以更低的頻率被重試， 從而允許其他優(yōu)先級較低的 Pod 排在它們之前。
非搶占式 Pod 仍可能被其他高優(yōu)先級 Pod 搶占。
?preemptionPolicy ?默認(rèn)為 ?PreemptLowerPriority?， 這將允許該 PriorityClass 的 Pod 搶占較低優(yōu)先級的 Pod（現(xiàn)有默認(rèn)行為也是如此）。 如果 ?preemptionPolicy ?設(shè)置為 ?Never?，則該 PriorityClass 中的 Pod 將是非搶占式的。
數(shù)據(jù)科學(xué)工作負(fù)載是一個示例用例。用戶可以提交他們希望優(yōu)先于其他工作負(fù)載的作業(yè)， 但不希望因?yàn)閾屨歼\(yùn)行中的 Pod 而導(dǎo)致現(xiàn)有工作被丟棄。 設(shè)置為 ?preemptionPolicy: Never? 的高優(yōu)先級作業(yè)將在其他排隊的 Pod 之前被調(diào)度， 只要足夠的集群資源“自然地”變得可用。
非搶占式 PriorityClass 示例
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority-nonpreempting
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "This priority class will not cause other pods to be preempted."Pod 優(yōu)先級
在你擁有一個或多個 PriorityClass 對象之后， 你可以創(chuàng)建在其規(guī)約中指定這些 PriorityClass 名稱之一的 Pod。 優(yōu)先級準(zhǔn)入控制器使用 ?priorityClassName ?字段并填充優(yōu)先級的整數(shù)值。 如果未找到所指定的優(yōu)先級類，則拒絕 Pod。
以下 YAML 是 Pod 配置的示例，它使用在前面的示例中創(chuàng)建的 PriorityClass。 優(yōu)先級準(zhǔn)入控制器檢查 Pod 規(guī)約并將其優(yōu)先級解析為 1000000。
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
priorityClassName: high-priorityPod 優(yōu)先級對調(diào)度順序的影響
當(dāng)啟用 Pod 優(yōu)先級時，調(diào)度程序會按優(yōu)先級對懸決 Pod 進(jìn)行排序， 并且每個懸決的 Pod 會被放置在調(diào)度隊列中其他優(yōu)先級較低的懸決 Pod 之前。 因此，如果滿足調(diào)度要求，較高優(yōu)先級的 Pod 可能會比具有較低優(yōu)先級的 Pod 更早調(diào)度。 如果無法調(diào)度此類 Pod，調(diào)度程序?qū)⒗^續(xù)并嘗試調(diào)度其他較低優(yōu)先級的 Pod。
搶占
Pod 被創(chuàng)建后會進(jìn)入隊列等待調(diào)度。 調(diào)度器從隊列中挑選一個 Pod 并嘗試將它調(diào)度到某個節(jié)點(diǎn)上。 如果沒有找到滿足 Pod 的所指定的所有要求的節(jié)點(diǎn)，則觸發(fā)對懸決 Pod 的搶占邏輯。 讓我們將懸決 Pod 稱為 P。搶占邏輯試圖找到一個節(jié)點(diǎn)， 在該節(jié)點(diǎn)中刪除一個或多個優(yōu)先級低于 P 的 Pod，則可以將 P 調(diào)度到該節(jié)點(diǎn)上。 如果找到這樣的節(jié)點(diǎn)，一個或多個優(yōu)先級較低的 Pod 會被從節(jié)點(diǎn)中驅(qū)逐。 被驅(qū)逐的 Pod 消失后，P 可以被調(diào)度到該節(jié)點(diǎn)上。
用戶暴露的信息
當(dāng) Pod P 搶占節(jié)點(diǎn) N 上的一個或多個 Pod 時， Pod P 狀態(tài)的 ?nominatedNodeName ?字段被設(shè)置為節(jié)點(diǎn) N 的名稱。 該字段幫助調(diào)度程序跟蹤為 Pod P 保留的資源，并為用戶提供有關(guān)其集群中搶占的信息。
請注意，Pod P 不一定會調(diào)度到“被提名的節(jié)點(diǎn)（Nominated Node）”。 調(diào)度程序總是在迭代任何其他節(jié)點(diǎn)之前嘗試“指定節(jié)點(diǎn)”。 在 Pod 因搶占而犧牲時，它們將獲得體面終止期。 如果調(diào)度程序正在等待犧牲者 Pod 終止時另一個節(jié)點(diǎn)變得可用， 則調(diào)度程序可以使用另一個節(jié)點(diǎn)來調(diào)度 Pod P。 因此，Pod 規(guī)約中的 ?nominatedNodeName ?和 ?nodeName ?并不總是相同。 此外，如果調(diào)度程序搶占節(jié)點(diǎn) N 上的 Pod，但隨后比 Pod P 更高優(yōu)先級的 Pod 到達(dá)， 則調(diào)度程序可能會將節(jié)點(diǎn) N 分配給新的更高優(yōu)先級的 Pod。 在這種情況下，調(diào)度程序會清除 Pod P 的 ?nominatedNodeName?。 通過這樣做，調(diào)度程序使 Pod P 有資格搶占另一個節(jié)點(diǎn)上的 Pod。
搶占的限制
被搶占犧牲者的體面終止
當(dāng) Pod 被搶占時，犧牲者會得到他們的 體面終止期。 它們可以在體面終止期內(nèi)完成工作并退出。如果它們不這樣做就會被殺死。 這個體面終止期在調(diào)度程序搶占 Pod 的時間點(diǎn)和待處理的 Pod (P) 可以在節(jié)點(diǎn) (N) 上調(diào)度的時間點(diǎn)之間劃分出了一個時間跨度。 同時，調(diào)度器會繼續(xù)調(diào)度其他待處理的 Pod。當(dāng)犧牲者退出或被終止時， 調(diào)度程序會嘗試在待處理隊列中調(diào)度 Pod。 因此，調(diào)度器搶占犧牲者的時間點(diǎn)與 Pod P 被調(diào)度的時間點(diǎn)之間通常存在時間間隔。 為了最小化這個差距，可以將低優(yōu)先級 Pod 的體面終止時間設(shè)置為零或一個小數(shù)字。
支持 PodDisruptionBudget，但不保證
PodDisruptionBudget (PDB) 允許多副本應(yīng)用程序的所有者限制因自愿性質(zhì)的干擾而同時終止的 Pod 數(shù)量。 Kubernetes 在搶占 Pod 時支持 PDB，但對 PDB 的支持是基于盡力而為原則的。 調(diào)度器會嘗試尋找不會因被搶占而違反 PDB 的犧牲者，但如果沒有找到這樣的犧牲者， 搶占仍然會發(fā)生，并且即使違反了 PDB 約束也會刪除優(yōu)先級較低的 Pod。
與低優(yōu)先級 Pod 之間的 Pod 間親和性
只有當(dāng)這個問題的答案是肯定的時，才考慮在一個節(jié)點(diǎn)上執(zhí)行搶占操作： “如果從此節(jié)點(diǎn)上刪除優(yōu)先級低于懸決 Pod 的所有 Pod，懸決 Pod 是否可以在該節(jié)點(diǎn)上調(diào)度？”
Note: 搶占并不一定會刪除所有較低優(yōu)先級的 Pod。 如果懸決 Pod 可以通過刪除少于所有較低優(yōu)先級的 Pod 來調(diào)度， 那么只有一部分較低優(yōu)先級的 Pod 會被刪除。 即便如此，上述問題的答案必須是肯定的。 如果答案是否定的，則不考慮在該節(jié)點(diǎn)上執(zhí)行搶占。
如果懸決 Pod 與節(jié)點(diǎn)上的一個或多個較低優(yōu)先級 Pod 具有 Pod 間親和性， 則在沒有這些較低優(yōu)先級 Pod 的情況下，無法滿足 Pod 間親和性規(guī)則。 在這種情況下，調(diào)度程序不會搶占節(jié)點(diǎn)上的任何 Pod。 相反，它尋找另一個節(jié)點(diǎn)。調(diào)度程序可能會找到合適的節(jié)點(diǎn)， 也可能不會。無法保證懸決 Pod 可以被調(diào)度。
我們針對此問題推薦的解決方案是僅針對同等或更高優(yōu)先級的 Pod 設(shè)置 Pod 間親和性。
跨節(jié)點(diǎn)搶占
假設(shè)正在考慮在一個節(jié)點(diǎn) N 上執(zhí)行搶占，以便可以在 N 上調(diào)度待處理的 Pod P。 只有當(dāng)另一個節(jié)點(diǎn)上的 Pod 被搶占時，P 才可能在 N 上變得可行。 下面是一個例子：
- 正在考慮將 Pod P 調(diào)度到節(jié)點(diǎn) N 上。
- Pod Q 正在與節(jié)點(diǎn) N 位于同一區(qū)域的另一個節(jié)點(diǎn)上運(yùn)行。
- Pod P 與 Pod Q 具有 Zone 維度的反親和（?
topologyKey:topology.kubernetes.io/zone?）。 - Pod P 與 Zone 中的其他 Pod 之間沒有其他反親和性設(shè)置。
- 為了在節(jié)點(diǎn) N 上調(diào)度 Pod P，可以搶占 Pod Q，但調(diào)度器不會進(jìn)行跨節(jié)點(diǎn)搶占。 因此，Pod P 將被視為在節(jié)點(diǎn) N 上不可調(diào)度。
如果將 Pod Q 從所在節(jié)點(diǎn)中移除，則不會違反 Pod 間反親和性約束， 并且 Pod P 可能會被調(diào)度到節(jié)點(diǎn) N 上。
如果有足夠的需求，并且如果我們找到性能合理的算法， 我們可能會考慮在未來版本中添加跨節(jié)點(diǎn)搶占。
故障排除
Pod 優(yōu)先級和搶占可能會產(chǎn)生不必要的副作用。以下是一些潛在問題的示例以及處理這些問題的方法。
Pod 被不必要地?fù)屨?
搶占在資源壓??力較大時從集群中刪除現(xiàn)有 Pod，為更高優(yōu)先級的懸決 Pod 騰出空間。 如果你錯誤地為某些 Pod 設(shè)置了高優(yōu)先級，這些無意的高優(yōu)先級 Pod 可能會導(dǎo)致集群中出現(xiàn)搶占行為。 Pod 優(yōu)先級是通過設(shè)置 Pod 規(guī)約中的 ?priorityClassName ?字段來指定的。 優(yōu)先級的整數(shù)值然后被解析并填充到 ?podSpec ?的 ?priority ?字段。
為了解決這個問題，你可以將這些 Pod 的 ?priorityClassName ?更改為使用較低優(yōu)先級的類， 或者將該字段留空。默認(rèn)情況下，空的 ?priorityClassName ?解析為零。
當(dāng) Pod 被搶占時，集群會為被搶占的 Pod 記錄事件。只有當(dāng)集群沒有足夠的資源用于 Pod 時， 才會發(fā)生搶占。在這種情況下，只有當(dāng)懸決 Pod（搶占者）的優(yōu)先級高于受害 Pod 時才會發(fā)生搶占。 當(dāng)沒有懸決 Pod，或者懸決 Pod 的優(yōu)先級等于或低于犧牲者時，不得發(fā)生搶占。 如果在這種情況下發(fā)生搶占，請?zhí)岢鰡栴}。
有 Pod 被搶占，但搶占者并沒有被調(diào)度
當(dāng) Pod 被搶占時，它們會收到請求的體面終止期，默認(rèn)為 30 秒。 如果受害 Pod 在此期限內(nèi)沒有終止，它們將被強(qiáng)制終止。 一旦所有犧牲者都離開，就可以調(diào)度搶占者 Pod。
在搶占者 Pod 等待犧牲者離開的同時，可能某個適合同一個節(jié)點(diǎn)的更高優(yōu)先級的 Pod 被創(chuàng)建。 在這種情況下，調(diào)度器將調(diào)度優(yōu)先級更高的 Pod 而不是搶占者。
這是預(yù)期的行為：具有較高優(yōu)先級的 Pod 應(yīng)該取代具有較低優(yōu)先級的 Pod。
優(yōu)先級較高的 Pod 在優(yōu)先級較低的 Pod 之前被搶占
調(diào)度程序嘗試查找可以運(yùn)行懸決 Pod 的節(jié)點(diǎn)。如果沒有找到這樣的節(jié)點(diǎn)， 調(diào)度程序會嘗試從任意節(jié)點(diǎn)中刪除優(yōu)先級較低的 Pod，以便為懸決 Pod 騰出空間。 如果具有低優(yōu)先級 Pod 的節(jié)點(diǎn)無法運(yùn)行懸決 Pod， 調(diào)度器可能會選擇另一個具有更高優(yōu)先級 Pod 的節(jié)點(diǎn)（與其他節(jié)點(diǎn)上的 Pod 相比）進(jìn)行搶占。 犧牲者的優(yōu)先級必須仍然低于搶占者 Pod。
當(dāng)有多個節(jié)點(diǎn)可供執(zhí)行搶占操作時，調(diào)度器會嘗試選擇具有一組優(yōu)先級最低的 Pod 的節(jié)點(diǎn)。 但是，如果此類 Pod 具有 PodDisruptionBudget，當(dāng)它們被搶占時， 則會違反 PodDisruptionBudget，那么調(diào)度程序可能會選擇另一個具有更高優(yōu)先級 Pod 的節(jié)點(diǎn)。
當(dāng)存在多個節(jié)點(diǎn)搶占且上述場景均不適用時，調(diào)度器會選擇優(yōu)先級最低的節(jié)點(diǎn)。
Pod 優(yōu)先級和服務(wù)質(zhì)量之間的相互作用
Pod 優(yōu)先級和 QoS 類 是兩個正交特征，交互很少，并且對基于 QoS 類設(shè)置 Pod 的優(yōu)先級沒有默認(rèn)限制。 調(diào)度器的搶占邏輯在選擇搶占目標(biāo)時不考慮 QoS。 搶占會考慮 Pod 優(yōu)先級并嘗試選擇一組優(yōu)先級最低的目標(biāo)。 僅當(dāng)移除優(yōu)先級最低的 Pod 不足以讓調(diào)度程序調(diào)度搶占式 Pod， 或者最低優(yōu)先級的 Pod 受 PodDisruptionBudget 保護(hù)時，才會考慮優(yōu)先級較高的 Pod。
kubelet 使用優(yōu)先級來確定 節(jié)點(diǎn)壓力驅(qū)逐 Pod 的順序。 你可以使用 QoS 類來估計 Pod 最有可能被驅(qū)逐的順序。kubelet 根據(jù)以下因素對 Pod 進(jìn)行驅(qū)逐排名：
- 對緊俏資源的使用是否超過請求值
- Pod 優(yōu)先級
- 相對于請求的資源使用量
當(dāng)某 Pod 的資源用量未超過其請求時，kubelet 節(jié)點(diǎn)壓力驅(qū)逐不會驅(qū)逐該 Pod。 如果優(yōu)先級較低的 Pod 沒有超過其請求，則不會被驅(qū)逐。 另一個優(yōu)先級高于其請求的 Pod 可能會被驅(qū)逐。
分享文章：創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod優(yōu)先級和搶占
URL標(biāo)題：http://www.dlmjj.cn/article/cdpeede.html
