本篇內(nèi)容介紹了“影響 Kubernetes 調(diào)度的決策因素是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)是一家網(wǎng)站設(shè)計公司，集創(chuàng)意、互聯(lián)網(wǎng)應(yīng)用、軟件技術(shù)為一體的創(chuàng)意網(wǎng)站建設(shè)服務(wù)商，主營產(chǎn)品：響應(yīng)式網(wǎng)站建設(shè)、高端網(wǎng)站設(shè)計、成都全網(wǎng)營銷推廣。我們專注企業(yè)品牌在網(wǎng)站中的整體樹立，網(wǎng)絡(luò)互動的體驗，以及在手機等移動端的優(yōu)質(zhì)呈現(xiàn)。網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、移動互聯(lián)產(chǎn)品、網(wǎng)絡(luò)運營、VI設(shè)計、云產(chǎn)品.運維為核心業(yè)務(wù)。為用戶提供一站式解決方案，我們深知市場的競爭激烈，認真對待每位客戶，為客戶提供賞析悅目的作品，網(wǎng)站的價值服務(wù)。

哪個節(jié)點具有可用資源？

選擇適當?shù)墓?jié)點時，調(diào)度程序會檢查每個節(jié)點是否有足夠的資源滿足 Pod 調(diào)度。如果您已經(jīng)聲明 Pod 所需的 CPU 和內(nèi)存量（通過請求和限制），調(diào)度程序?qū)⑹褂靡韵鹿絹碛嬎憬o定節(jié)點上的可用內(nèi)存：

調(diào)度可用內(nèi)存 = 節(jié)點總內(nèi)存 - 已預(yù)留內(nèi)存

保留內(nèi)存是指：

1. Kubernetes 守護進程使用的內(nèi)存，例如：kubelet、containerd（一種容器運行時）。

2. 節(jié)點操作系統(tǒng)使用的內(nèi)存，例如：內(nèi)核守護程序。

通過使用此方程式，調(diào)度程序可確保由于過多 Pod 競爭消耗節(jié)點所有可用資源，從而導(dǎo)致節(jié)點資源耗盡引起其他系統(tǒng)異常，比如系統(tǒng)觸發(fā) oom。

影響調(diào)度過程

在不受用戶影響的情況下，調(diào)度程序在將 Pod 調(diào)度到節(jié)點時執(zhí)行以下步驟：

1. 調(diào)度程序檢測到已創(chuàng)建新的 Pod，但尚未將其分配給節(jié)點；

2. 它檢查 Pod 需求，并相應(yīng)地篩選出所有不合適的節(jié)點；

3. 根據(jù)權(quán)重將剩下的節(jié)點進行排序，權(quán)重最高的排在第一位；

4. 調(diào)度程序選擇排序列表中的第一個節(jié)點，然后將 Pod 分配給它。

通常，我們會讓調(diào)度程序自動選擇合適的節(jié)點（前提是 Pod 配置了資源請求和限制）。但是，有時可能需要通過強制調(diào)度程序選擇特定節(jié)點或手動向多個節(jié)點添加權(quán)重來影響此決策，以使其比其他節(jié)點更適合 Pod 調(diào)度。

讓我們看看我們?nèi)绾巫龅竭@一點：

節(jié)點名稱

在最簡單的節(jié)點選擇配置中，您只需在 .spec.nodeName 中指定其名稱，就可以強制 Pod 在指定節(jié)點上運行。例如，以下 YAML 定義 Pod 強制在 app-prod01 上進行調(diào)度：

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - name: nginx   image: nginx nodeName: app-prod01

請注意，由于以下原因，此方法是最簡單但最不推薦的節(jié)點選擇方法：

• 如果由于某種原因無法找到指定名稱的節(jié)點（例如，更改了主機名），則 Pod 將不會運行。

• 如果該節(jié)點沒有 Pod 運行所需的資源，則 Pod 會運行失敗，并且也不會將該 Pod 調(diào)度到其他節(jié)點。

• 這會導(dǎo)致 Pods 與它們的節(jié)點緊密耦合，這是一種糟糕的設(shè)計實踐。

節(jié)點選擇器

覆蓋調(diào)度程序決策的第一個最簡單的方法是使用 Pod 定義或 Pod 模板（如果使用的是 Deployments 之類的控制器）中的 .spec.nodeSelector 參數(shù)。nodeSelector 接受 一個或多個 鍵-值對標簽，這些 鍵-值對 標簽必須在節(jié)點設(shè)置才能正常的調(diào)度 Pod。假設(shè)您最近購買了兩臺配備 SSD 磁盤的計算機，您希望數(shù)據(jù)庫相關(guān)所有的 Pod 在 SSD 支持的節(jié)點上進行調(diào)度，以獲得最佳的數(shù)據(jù)庫性能。DB Pod 的 Pod YAML 可能如下所示：

apiVersion: v1kind: Podmetadata: name: dbspec: containers: - name: MongoDB   image: mongo nodeSelector:   disktype: ssd

根據(jù)該定義，當調(diào)度程序選擇合適的 Pod 分配節(jié)點時，將僅考慮具有 disktype=ssd 標簽的節(jié)點。

此外，您可以使用自動分配給節(jié)點的任何內(nèi)置標簽來操縱選擇決策。例如，節(jié)點的主機名（kubernetes.io/hostname），體系結(jié)構(gòu)（kubernetes.io/arch），操作系統(tǒng)（kubernetes.io/os）等均可用于節(jié)點選擇。

節(jié)點親和性

當您需要選擇特定的節(jié)點來運行我們的 Pod 時，節(jié)點選擇非常有用。但是選擇節(jié)點的方式是有限的，只有與所有定義的標簽匹配的節(jié)點才被考慮用于 Pod 放置。Node Affinity 通過允許您定義硬節(jié)點和軟節(jié)點需求，為您提供了更大的靈活性。硬性要求必須在要選擇的節(jié)點上匹配。另一方面，軟條件允許您為具有特定標簽的節(jié)點增加更多權(quán)重，以使它們在列表中的位置比對等節(jié)點更高。沒有軟需求標簽的節(jié)點將不被忽略，但它們權(quán)重更小。

讓我們舉個例子：我們的數(shù)據(jù)庫是 I/O 密集型的。我們需要數(shù)據(jù)庫 Pods 始終在 SSD 支持的節(jié)點上運行。此外，如果 Pod 部署在區(qū)域 zone1 或 zone2 中的節(jié)點上，因為它們在物理上更靠近應(yīng)用程序節(jié)點，那么它們的延遲會更短。滿足我們需求的 Pod 定義可能如下所示：

apiVersion: v1kind: Podmetadata: name: dbspec: affinity:   nodeAffinity:     requiredDuringSchedulingIgnoredDuringExecution:       nodeSelectorTerms:       - matchExpressions:         - key: disk-type           operator: In           values:           - ssd     preferredDuringSchedulingIgnoredDuringExecution:     - weight: 1       preference:         matchExpressions:         - key: zone           operator: In           values:           - zone1           - zone2 containers: - name: db   image: mongo

nodeAffinity 節(jié)使用以下參數(shù)來定義硬性要求和軟性要求：

• requiredDuringSchedulingIgnoredDuringExecution：部署 DB Pod 時，節(jié)點必須具有 disk-type=ssd。

• preferredDuringSchedulingIgnoredDuringExecution： 當對節(jié)點進行排序時，調(diào)度器會給予標簽為zone=zone1或zone=zone2的節(jié)點更高的權(quán)重。如果有disk-type=ssd和zone=zone1的節(jié)點，則優(yōu)先選擇 disk-type=ssd 且無 zone 標簽的節(jié)點或指向其他 zone 的節(jié)點。權(quán)重可以是 1 到 100 之間的任意值，權(quán)重號賦予匹配節(jié)點相對于其他節(jié)點更高的權(quán)重。數(shù)字越大，權(quán)值越高。

注意，在進行選擇時，節(jié)點親和性允許您在選擇目標節(jié)點上應(yīng)該存在(或不存在)哪些標簽時擁有更多的自由。在本例中，我們使用 In 操作符定義了多個標簽，目標節(jié)點上存在任何一個標簽即可。其他運算符是 NotIn、Exists、doesnoexistists、Lt(小于)和 Gt(大于)。值得注意的是，NotIn 和 doesnot existist 實現(xiàn)了所謂的節(jié)點反親和性。

節(jié)點親和性和節(jié)點選擇器不是互斥的，它們可以共存于同一個定義文件中。但是，在這種情況下，節(jié)點選擇器和節(jié)點親和性硬要求必須匹配。

Pod 親和性

節(jié)點選擇器和節(jié)點親和性(以及反親和性)幫助我們影響調(diào)度器關(guān)于在何處放置 Pods 的決策。但是，它只允許您基于節(jié)點上的標簽進行選擇。它不關(guān)心 Pod 本身的標簽。您可能需要在以下情況下根據(jù) Pod 標簽進行選擇:

• 需要將所有中間件 Pod 放在同一個物理節(jié)點上，與那些具有 role=front 標簽的 Pod 一起，以減少它們之間的網(wǎng)絡(luò)延遲。

• 作為一種安全最佳實踐，我們不希望中間件 Pod 與處理用戶身份驗證的 Pod 共存(role=auth)。這不是一個嚴格的要求。

如您所見，這些要求不能用節(jié)點選擇器或親和性來滿足，因為在選擇過程中不考慮 Pod 標簽——只考慮節(jié)點標簽。

為了滿足這些需求，我們使用 Pod 親和性和反親和性。本質(zhì)上，它們的工作方式與節(jié)點親和性和反親和性相同。必須滿足硬性要求來選擇目標節(jié)點，而軟條件增加了擁有所選節(jié)點的機會(權(quán)重)，但不是嚴格要求。讓我們舉個例子:

apiVersion: v1kind: Podmetadata: name: middlewarespec: affinity:   podAffinity:     requiredDuringSchedulingIgnoredDuringExecution:     - labelSelector:         matchExpressions:         - key: role           operator: In           values:           - frontend       topologyKey: kubernetes.io/hostname   podAntiAffinity:     preferredDuringSchedulingIgnoredDuringExecution:     - weight: 100       podAffinityTerm:         labelSelector:           matchExpressions:           - key: role             operator: In             values:             - auth         topologyKey: kubernetes.io/hostname containers: - name: middleware   image: redis

在上面的 Pod 定義文件中，我們對硬性要求和軟性要求進行了如下設(shè)置：

requiredDuringSchedulingIgnoredDuringExecution：我們的 Pod 必須在具有標簽為 app-front 的 Pod 節(jié)點上調(diào)度。

preferredDuringSchedulingIgnoredDuringExecution：我們的 Pod 不應(yīng)該(但它可以)被調(diào)度到運行帶有標簽為 role=auth 的 Pod 的節(jié)點上。與節(jié)點親和性一樣，soft requirement 將權(quán)重從 1 設(shè)置為 100，以增加節(jié)點相對于其他節(jié)點的概率。在我們的示例中，軟需求被放置在 poantiaffinity 中，導(dǎo)致運行具有標簽為 role=auth 的 Pod 的節(jié)點在調(diào)度程序做出決定時被選中的可能性更小。

topologyKey 用于對規(guī)則將應(yīng)用于哪個領(lǐng)域做出更細粒度的決策。topologyKey 接受一個標簽鍵，該標簽鍵必須出現(xiàn)在選擇過程中考慮的節(jié)點上。在我們的示例中，我們使用了自動填充的標簽，該標簽在默認情況下自動添加到所有節(jié)點，并引用節(jié)點的主機名。但是您可以使用其他自動填充的標簽，甚至是自定義的標簽。例如，您可能需要只在具有 rack 或 zone 標簽的節(jié)點上應(yīng)用 Pod 親和規(guī)則。

關(guān)于 IgnoredDuringExecution 的注釋

您可能已經(jīng)注意到，硬需求和軟需求都有 IgnoredDuringExecution 后綴。這意味著在做出調(diào)度決策之后，調(diào)度程序?qū)⒉粫L試更改已經(jīng)放置的 Pods，即使條件發(fā)生了變化。例如，根據(jù)節(jié)點親和性規(guī)則，將一個 Pod 調(diào)度到一個具有標簽為 app=prod 的節(jié)點上。如果該標簽被更改為 app=dev, 舊 Pod 不會被終止，并在另一個有 app=prod 標簽的節(jié)點上啟動新的 Pod。這個行為在將來可能會改變，以允許調(diào)度程序在部署后繼續(xù)檢查節(jié)點和 Pod 的關(guān)聯(lián)性(和反關(guān)聯(lián)性)規(guī)則。

污點與容忍

在某些場景中，您可能希望阻止將 Pod 調(diào)度到特定節(jié)點。可能您正在運行測試或掃描此節(jié)點以查找威脅，而您不希望應(yīng)用程序受到影響。節(jié)點反親和性可以實現(xiàn)這一目標。但是，這是一個重大的管理負擔，因為您需要向部署到集群的每個新 Pod 添加反關(guān)聯(lián)規(guī)則。對于這種場景，您應(yīng)該使用污點。

當一個節(jié)點配置了污點時，除非 Pod 能夠容忍這種污點，否則不能對它調(diào)度 Pod。容忍只是一個與污點匹配的鍵-值對。讓我們舉個例子來說明:

需要對主機 web01 進行污染，以使其不接受更多 Pod。taint 命令如下：

kubectl taint nodes web01 locked=true:NoSchedule

上面的命令在名為 web01 的節(jié)點上放置了一個污點，該節(jié)點具有以下屬性:

• 標簽 locked=true，該標簽必須配置在想要運行在該節(jié)點的 Pod 上。

• NoSchedule 的污點類型。污點類型定義了應(yīng)用污點的行為，它有以下幾種可能:

• NoSchedule：此節(jié)點一定不要調(diào)度。

• PreferNoSchedule：盡量不要調(diào)度，類似軟親和性。

• NoExecute：不僅不會調(diào)度，還會驅(qū)逐 Node 上已有的 Pod。

在帶有污點的節(jié)點上，Pod 的定義文件可能如下所示:

apiVersion: v1kind: Podmetadata: name: mypodspec: containers: - name: mycontainer   image: nginx tolerations: - key: "locked"   operator: "Equal"   value: "true"   effect: "NoSchedule"

讓我們仔細看看這個定義的容忍部分:

• 為了具有正確的容忍，我們需要指定鍵（locked），值（true）和運算符。

• 運算符可以是兩個值之一：

• Equal：當使用 equal 操作符時，鍵、值和污染效果必須與節(jié)點的污染匹配。

• Exists：在使用 exists 操作符時，不需要將污點與容忍匹配，只需匹配建即可。

• 如果使用 Exists 運算符，則可以忽略容忍鍵、值和效果。具有這種容忍的 Pod 可以被調(diào)度到具有任何受污點的節(jié)點。

注意，在 Pod 上放置容忍并不能保證它被部署到受污染的節(jié)點上。它只允許行為發(fā)生。如果要強制 Pod 加入受污染的節(jié)點，還必須像前面討論的那樣向其定義添加節(jié)點親和性。

TL; DR

在節(jié)點上自動放置 Pod 是 Kubernetes 誕生的原因之一。作為管理員，只要您對 Pod 需求做出了良好的聲明，您就不用擔心節(jié)點是否有足夠的空閑資源來運行這些 Pod。但是，有時您必須手動干預(yù)和覆蓋系統(tǒng)關(guān)于在何處放置 Pods 的決定。在本文中，我們討論了幾種方法，在決定部署 Pods 時，您可以通過這些方法對特定節(jié)點的調(diào)度器產(chǎn)生更大的影響。讓我們快速回顧一下這些方法:

• 節(jié)點名稱：通過將節(jié)點的主機名添加到 Pod 定義的 .spec.nodeName 參數(shù)中，可以強制此 Pod 在該特定節(jié)點上運行。調(diào)度程序使用的任何選擇算法都將被忽略。不建議使用此方法。

• 節(jié)點選擇器：通過在節(jié)點上放置指定的標簽，Pod 可以使用 nodeelector 參數(shù)指定一個或多個鍵-值標簽，這些標簽必須存在于目標節(jié)點上才能被選中以運行 Pod。推薦使用這種方法，因為它增加了很多靈活性，并建立了松耦合的 node-Pod 關(guān)系。

• 節(jié)點親和性：在選擇應(yīng)該考慮哪個節(jié)點來調(diào)度特定的 Pod 時，這種方法增加了更多的靈活性。使用節(jié)點親和性，Pod 可能嚴格要求在具有特定標簽的節(jié)點上調(diào)度。它還可以通過影響調(diào)度程序為特定節(jié)點賦予更大的權(quán)重來表示對特定節(jié)點的某種程度的偏好。

• Pod 親和性和反親和性：當 Pod 與同一節(jié)點上的其他 Pod 共存(或不共存)時，可以使用此方法。Pod 親和性允許將 Pod 部署在具有特定標簽的 Pod 運行的節(jié)點上。相反，Pod 可能會強制調(diào)度程序不將其調(diào)度到具有特定標簽的 Pod 運行的節(jié)點上。

• 污點和容忍：在這種方法中，您不需要決定將 Pod 調(diào)度到哪些節(jié)點，而是決定哪些節(jié)點是否接受 所有 Pod 調(diào)度，或者只接受選定的 Pod 調(diào)度。通過污染一個節(jié)點，調(diào)度程序?qū)⒉豢紤]將這個節(jié)點作為任何 Pod 的調(diào)度節(jié)點，除非 Pod 配置了容忍。容忍由鍵、值和受染的效果組成。

“影響 Kubernetes 調(diào)度的決策因素是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！