Taint 和 Toleration

節點親和性（詳見這里），是 pod 的一種屬性（偏好或硬性要求），它使 pod 被吸引到一類特定的節點。Taint 則相反，它使 節點 能夠 排斥 一類特定的 pod。

創新互聯主營會同網站建設的網絡公司,主營網站建設方案,app軟件開發公司,會同h5成都小程序開發搭建,會同網站營銷推廣歡迎會同等地區企業咨詢

Taint 和 toleration 相互配合，可以用來避免 pod 被分配到不合適的節點上。每個節點上都可以應用一個或多個 taint ，這表示對于那些不能容忍這些 taint 的 pod，是不會被該節點接受的。如果將 toleration 應用于 pod 上，則表示這些 pod 可以（但不要求）被調度到具有匹配 taint 的節點上。

概念

使用例子

基于 taint 的驅逐

基于節點狀態添加 taint

概念

您可以使用命令 kubectl taint 給節點增加一個 taint。比如，

kubectl taint nodes node1 key=value:NoSchedule

給節點 node1 增加一個 taint，它的 key 是 key，value 是 value，effect 是 NoSchedule。這表示只有擁有和這個 taint 相匹配的 toleration 的 pod 才能夠被分配到 node1 這個節點。您可以在 PodSpec 中定義 pod 的 toleration。下面兩個 toleration 均與上面例子中使用 kubectl taint 命令創建的 taint 相匹配，因此如果一個 pod 擁有其中的任何一個 toleration 都能夠被分配到 node1 ：

想刪除上述命令添加的 taint ，您可以運行：

kubectl taint nodes node1 key:NoSchedule-

您可以在PodSpec中為容器設定容忍標簽。以下兩個容忍標簽都與上面的 kubectl taint 創建的污點“匹配”， 因此具有任一容忍標簽的Pod都可以將其調度到“ node1”上：

tolerations:

- key: "key"

operator: "Equal"

value: "value"

effect: "NoSchedule"

tolerations:

- key: "key"

operator: "Exists"

effect: "NoSchedule"

一個 toleration 和一個 taint 相“匹配”是指它們有一樣的 key 和 effect ，并且：

如果 operator 是 Exists （此時 toleration 不能指定 value），或者

如果 operator 是 Equal ，則它們的 value 應該相等

注意：

存在兩種特殊情況：

如果一個 toleration 的 key 為空且 operator 為 Exists ，表示這個 toleration 與任意的 key 、 value 和 effect 都匹配，即這個 toleration 能容忍任意 taint。

tolerations:

- operator: "Exists"

如果一個 toleration 的 effect 為空，則 key 值與之相同的相匹配 taint 的 effect 可以是任意值。

tolerations:

- key: "key"

operator: "Exists"

上述例子使用到的 effect 的一個值 NoSchedule，您也可以使用另外一個值 PreferNoSchedule。這是“優化”或“軟”版本的 NoSchedule ——系統會*盡量*避免將 pod 調度到存在其不能容忍 taint 的節點上，但這不是強制的。effect 的值還可以設置為 NoExecute ，下文會詳細描述這個值。

您可以給一個節點添加多個 taint ，也可以給一個 pod 添加多個 toleration。Kubernetes 處理多個 taint 和 toleration 的過程就像一個過濾器：從一個節點的所有 taint 開始遍歷，過濾掉那些 pod 中存在與之相匹配的 toleration 的 taint。余下未被過濾的 taint 的 effect 值決定了 pod 是否會被分配到該節點，特別是以下情況：

如果未被過濾的 taint 中存在一個以上 effect 值為 NoSchedule 的 taint，則 Kubernetes 不會將 pod 分配到該節點。

如果未被過濾的 taint 中不存在 effect 值為 NoSchedule 的 taint，但是存在 effect 值為 PreferNoSchedule 的 taint，則 Kubernetes 會*嘗試*將 pod 分配到該節點。

如果未被過濾的 taint 中存在一個以上 effect 值為 NoExecute 的 taint，則 Kubernetes 不會將 pod 分配到該節點（如果 pod 還未在節點上運行），或者將 pod 從該節點驅逐（如果 pod 已經在節點上運行）。

例如，假設您給一個節點添加了如下的 taint

kubectl taint nodes node1 key1=value1:NoSchedule

kubectl taint nodes node1 key1=value1:NoExecute

kubectl taint nodes node1 key2=value2:NoSchedule

然后存在一個 pod，它有兩個 toleration

tolerations:

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoSchedule"

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoExecute"

在這個例子中，上述 pod 不會被分配到上述節點，因為其沒有 toleration 和第三個 taint 相匹配。但是如果在給節點添加 上述 taint 之前，該 pod 已經在上述節點運行，那么它還可以繼續運行在該節點上，因為第三個 taint 是三個 taint 中唯一不能被這個 pod 容忍的。

通常情況下，如果給一個節點添加了一個 effect 值為 NoExecute 的 taint，則任何不能忍受這個 taint 的 pod 都會馬上被驅逐，任何可以忍受這個 taint 的 pod 都不會被驅逐。但是，如果 pod 存在一個 effect 值為 NoExecute 的 toleration 指定了可選屬性 tolerationSeconds 的值，則表示在給節點添加了上述 taint 之后，pod 還能繼續在節點上運行的時間。例如，

tolerations:

- key: "key1"

operator: "Equal"

value: "value1"

effect: "NoExecute"

tolerationSeconds: 3600

這表示如果這個 pod 正在運行，然后一個匹配的 taint 被添加到其所在的節點，那么 pod 還將繼續在節點上運行 3600 秒，然后被驅逐。如果在此之前上述 taint 被刪除了，則 pod 不會被驅逐。

使用例子

通過 taint 和 toleration ，可以靈活地讓 pod *避開*某些節點或者將 pod 從某些節點驅逐。下面是幾個使用例子：

專用節點：如果您想將某些節點專門分配給特定的一組用戶使用，您可以給這些節點添加一個 taint（即， kubectl taint nodes nodename dedicated=groupName:NoSchedule），然后給這組用戶的 pod 添加一個相對應的 toleration（通過編寫一個自定義的admission controller，很容易就能做到）。擁有上述 toleration 的 pod 就能夠被分配到上述專用節點，同時也能夠被分配到集群中的其它節點。如果您希望這些 pod 只能被分配到上述專用節點，那么您還需要給這些專用節點另外添加一個和上述 taint 類似的 label （例如：dedicated=groupName），同時 還要在上述 admission controller 中給 pod 增加節點親和性要求上述 pod 只能被分配到添加了 dedicated=groupName 標簽的節點上。

配備了特殊硬件的節點：在部分節點配備了特殊硬件（比如 GPU）的集群中，我們希望不需要這類硬件的 pod 不要被分配到這些特殊節點，以便為后繼需要這類硬件的 pod 保留資源。要達到這個目的，可以先給配備了特殊硬件的節點添加 taint（例如 kubectl taint nodes nodename special=true:NoSchedule or kubectl taint nodes nodename special=true:PreferNoSchedule)，然后給使用了這類特殊硬件的 pod 添加一個相匹配的 toleration。和專用節點的例子類似，添加這個 toleration 的最簡單的方法是使用自定義 admission controller。比如，我們推薦使用 Extended Resources 來表示特殊硬件，給配置了特殊硬件的節點添加 taint 時包含 extended resource 名稱，然后運行一個 ExtendedResourceToleration admission controller。此時，因為節點已經被 taint 了，沒有對應 toleration 的 Pod 會被調度到這些節點。但當你創建一個使用了 extended resource 的 Pod 時，ExtendedResourceToleration admission controller 會自動給 Pod 加上正確的 toleration ，這樣 Pod 就會被自動調度到這些配置了特殊硬件件的節點上。這樣就能夠確保這些配置了特殊硬件的節點專門用于運行 需要使用這些硬件的 Pod，并且您無需手動給這些 Pod 添加 toleration。

基于 taint 的驅逐 （beta 特性）: 這是在每個 pod 中配置的在節點出現問題時的驅逐行為，接下來的章節會描述這個特性

基于 taint 的驅逐

前文我們提到過 taint 的 effect 值 NoExecute ，它會影響已經在節點上運行的 pod * 如果 pod 不能忍受effect 值為 NoExecute 的 taint，那么 pod 將馬上被驅逐 * 如果 pod 能夠忍受effect 值為 NoExecute 的 taint，但是在 toleration 定義中沒有指定 tolerationSeconds，則 pod 還會一直在這個節點上運行。 * 如果 pod 能夠忍受effect 值為 NoExecute 的 taint，而且指定了 tolerationSeconds，則 pod 還能在這個節點上繼續運行這個指定的時間長度。

此外，Kubernetes 1.6 已經支持（alpha階段）節點問題的表示。換句話說，當某種條件為真時，node controller會自動給節點添加一個 taint。當前內置的 taint 包括：

node.kubernetes.io/not-ready：節點未準備好。這相當于節點狀態 Ready 的值為 “False“。

node.kubernetes.io/unreachable：node controller 訪問不到節點. 這相當于節點狀態 Ready 的值為 “Unknown“。

node.kubernetes.io/out-of-disk：節點磁盤耗盡。

node.kubernetes.io/memory-pressure：節點存在內存壓力。

node.kubernetes.io/disk-pressure：節點存在磁盤壓力。

node.kubernetes.io/network-unavailable：節點網絡不可用。

node.kubernetes.io/unschedulable: 節點不可調度。

node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 啟動時指定了一個 “外部” cloud provider，它將給當前節點添加一個 taint 將其標志為不可用。在 cloud-controller-manager 的一個 controller 初始化這個節點后，kubelet 將刪除這個 taint。

在版本1.13中，TaintBasedEvictions 功能已升級為Beta，并且默認啟用，因此污點會自動給節點添加這類 taint，上述基于節點狀態 Ready 對 pod 進行驅逐的邏輯會被禁用。

注意：

注意：為了保證由于節點問題引起的 pod 驅逐rate limiting行為正常，系統實際上會以 rate-limited 的方式添加 taint。在像 master 和 node 通訊中斷等場景下，這避免了 pod 被大量驅逐。

使用這個 beta 功能特性，結合 tolerationSeconds ，pod 就可以指定當節點出現一個或全部上述問題時還將在這個節點上運行多長的時間。

比如，一個使用了很多本地狀態的應用程序在網絡斷開時，仍然希望停留在當前節點上運行一段較長的時間，愿意等待網絡恢復以避免被驅逐。在這種情況下，pod 的 toleration 可能是下面這樣的：

tolerations:

- key: "node.kubernetes.io/unreachable"

operator: "Exists"

effect: "NoExecute"

tolerationSeconds: 6000

注意，Kubernetes 會自動給 pod 添加一個 key 為 node.kubernetes.io/not-ready 的 toleration 并配置 tolerationSeconds=300，除非用戶提供的 pod 配置中已經已存在了 key 為 node.kubernetes.io/not-ready 的 toleration。同樣，Kubernetes 會給 pod 添加一個 key 為 node.kubernetes.io/unreachable 的 toleration 并配置 tolerationSeconds=300，除非用戶提供的 pod 配置中已經已存在了 key 為 node.kubernetes.io/unreachable 的 toleration。

這種自動添加 toleration 機制保證了在其中一種問題被檢測到時 pod 默認能夠繼續停留在當前節點運行 5 分鐘。這兩個默認 toleration 是由 DefaultTolerationSeconds admission controller添加的。

DaemonSet 中的 pod 被創建時，針對以下 taint 自動添加的 NoExecute 的 toleration 將不會指定 tolerationSeconds：

node.kubernetes.io/unreachable

node.kubernetes.io/not-ready

這保證了出現上述問題時 DaemonSet 中的 pod 永遠不會被驅逐，這和 TaintBasedEvictions 這個特性被禁用后的行為是一樣的。

基于節點狀態添加 taint

在版本1.12中，TaintNodesByCondition 功能已升級為Beta，因此節點生命周期控制器會自動創建與Node條件相對應的污點。 同樣，調度程序不檢查節點條件。 而是調度程序檢查污點。 這確保了節點條件不會影響調度到節點上的內容。 用戶可以通過添加適當的 Pod 容忍來選擇忽略某些Node的問題(表示為 Node 的調度條件)。 注意，TaintNodesByCondition 只會污染具有 NoSchedule 設定的節點。 NoExecute 效應由 TaintBasedEviction 控制， TaintBasedEviction 是 Beta 版功能，自1.13版起默認啟用。

node.kubernetes.io/memory-pressure

node.kubernetes.io/disk-pressure

node.kubernetes.io/out-of-disk (只適合 critical pod)

node.kubernetes.io/unschedulable (1.10 或更高版本)

node.kubernetes.io/network-unavailable (只適合 host network)

添加上述 toleration 確保了向后兼容，您也可以選擇自由的向 DaemonSet 添加 toleration。

文檔來源:

https://kubernetes.io/zh/docs/concepts/configuration/taint-and-toleration/

另外有需要云服務器可以了解下創新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

網站名稱：K8S之Taints(污點)和Tolerations（容忍）--初探;-創新互聯
文章網址：http://www.yijiale78.com/article26/phijg.html

成都網站建設公司_創新互聯，為您提供外貿建站、全網營銷推廣、品牌網站建設、面包屑導航、網站排名、網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯