Kubernetes集群調(diào)度詳解(節(jié)點親和性、Pod親和性、Taint與Toleration)
引導：現(xiàn)在發(fā)覺每次pod調(diào)度都是隨機事件，不知道pod會被調(diào)度到哪一個節(jié)點
一、簡介
Scheduler 是 kubernetes 的調(diào)度器，主要的任務是把定義的 pod 分配到集群的節(jié)點上。聽起來非常簡單，但有很多要考慮的問題：
- 公平：如何保證每個節(jié)點都能被分配資源
- 資源高效利用：集群所有資源最大化被使用
- 效率：調(diào)度的性能要好，能夠盡快地對大批量的 pod 完成調(diào)度工作
- 靈活：允許用戶根據(jù)自己的需求控制調(diào)度的邏輯
Scheduler 是作為單獨的程序運行的，啟動之后會一直堅挺 API Server，獲取PodSpec.NodeName為空的 pod，對每個 pod 都會創(chuàng)建一個 binding（必須遵守的），表明該 pod 應該放到哪個節(jié)點上
二、調(diào)度過程
調(diào)度分為幾個部分：
- 首先是過濾掉不滿足條件的節(jié)點，這個過程稱為predicate（預選）；
- 然后對通過的節(jié)點按照優(yōu)先級排序，這個是priority（優(yōu)選）；
- 最后從中選擇優(yōu)先級最高的節(jié)點。如果中間任何一步驟有錯誤，就直接返回錯誤（先預選，后優(yōu)選）
Predicate（預選）有一系列的算法可以使用：
- PodFitsResources：節(jié)點上剩余的資源是否大于 pod 請求的資源
- PodFitsHost：如果 pod 指定了 NodeName，檢查節(jié)點名稱是否和 NodeName 匹配
- PodFitsHostPorts：節(jié)點上已經(jīng)使用的 port 是否和 pod 申請的 port 沖突
- PodSelectorMatches：過濾掉和 pod 指定的 label 不匹配的節(jié)點
- NoDiskConflict：已經(jīng) mount 的 volume 和 pod 指定的 volume 不沖突，除非它們都是只讀
如果在 predicate 過程中沒有合適的節(jié)點，pod 會一直在pending狀態(tài)（pending：等待），不斷重試調(diào)度，直到有節(jié)點滿足條件。經(jīng)過這個步驟，如果有多個節(jié)點滿足條件，就繼續(xù) priorities 過程：按照優(yōu)先級大小對節(jié)點排序
優(yōu)先級由一系列鍵值對組成，鍵是該優(yōu)先級項的名稱，值是它的權重（該項的重要性）。這些優(yōu)先級選項包括：
- LeastRequestedPriority：通過計算 CPU 和 Memory 的使用率來決定權重，使用率越低權重越高。換句話說，這個優(yōu)先級指標傾向于資源使用比例更低的節(jié)點
- BalancedResourceAllocation：節(jié)點上 CPU 和 Memory 使用率越接近，權重越高。這個應該和上面的一起使用，不應該單獨使用
- ImageLocalityPriority：傾向于已經(jīng)有要使用鏡像的節(jié)點，鏡像總大小值越大，權重越高
通過算法對所有的優(yōu)先級項目和權重進行計算，得出最終的結(jié)果
三、自定義調(diào)度器
除了 kubernetes 自帶的調(diào)度器，你也可以編寫自己的調(diào)度器。通過spec:schedulername參數(shù)指定調(diào)度器的名字，可以為 pod 選擇某個調(diào)度器進行調(diào)度。
比如下面的 pod 選擇my-scheduler進行調(diào)度，而不是默認的default-scheduler：
四、節(jié)點親和性（pod與node的親和性）
pod.spec.nodeAffinity
- preferredDuringSchedulingIgnoredDuringExecution（優(yōu)先執(zhí)行計劃）：軟策略
- requiredDuringSchedulingIgnoredDuringExecution（要求執(zhí)行計劃）：硬策略
- preferred：首選，較喜歡
- required：需要，必修
鍵值運算關系
- In：label 的值在某個列表中
- NotIn：label 的值不在某個列表中
- Gt：label 的值大于某個值
- Lt：label 的值小于某個值
- Exists：某個 label 存在
- DoesNotExist：某個 label 不存在
1、硬策略：requiredDuringSchedulingIgnoredDuringExecution
#節(jié)點硬策略。排除node02，只能在node01上運行
apiVersion: v1
kind: Pod
metadata:
name: affinity
labels:
app: node-affinity-pod
spec:
containers:
- name: with-node-affinity
image: hub.atguigu.com/library/myapp:v1
affinity: #親和性
nodeAffinity: #node親和性
# 硬親和性限制
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname # 標簽鍵名
operator: NotIn #鍵值運算關系 ，NotIn:label的值不在某個列表中。 表示不是node02節(jié)點就可運行
values:
- k8s-node02 # 標簽鍵值
kubectl get node --show-labels mkdir affi cd affi vim pod1.yaml kubectl create -f pod1.yaml kubectl get pod -o wide
kubectl delete pod --all && kubectl create -f pod1.yaml && kubectl get pod -o wide
把pod1.yaml改為In node3
然而實際并沒有node3節(jié)點，因此一直處于Pending狀態(tài)，這就是硬策略
2、軟策略：preferredDuringSchedulingIgnoredDuringExecution
如果有的話就在上面運行，沒有的話就算了
vim pod2.yaml
#軟策略
apiVersion: v1
kind: Pod
metadata:
name: affinity2
labels:
app: node-affinity-pod
spec:
containers:
- name: with-node-affinity
image: hub.atguigu.com/library/myapp:v1
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1 #權重，權重越大越親和(多個軟策略的情況)
preference:
matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- k8s-node03 # 期望是node03
查看：kubectl get node --show-labels
3、軟硬策略（先滿足硬策略再滿足軟策略）
#軟硬合體
apiVersion: v1
kind: Pod
metadata:
name: affinity2
labels:
app: node-affinity-pod
spec:
containers:
- name: with-node-affinity
image: hub.atguigu.com/library/myapp:v1
affinity:
nodeAffinity: #node親和性
# 硬親和性限制
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname # 標簽鍵名
operator: NotIn #鍵值運算關系 ，NotIn:label的值不在某個列表中。 表示不是node02節(jié)點就可運行
values:
- k8s-node02 # 標簽鍵值
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1 #權重，權重越大越親和(多個軟策略的情況)
preference:
matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- k8s-node03 # 期望是node03
五、Pod親和性（pod與pod之間的親和性）
pod.spec.affinity.podAffinity/podAntiAffinity
- preferredDuringSchedulingIgnoredDuringExecution：軟策略
- requiredDuringSchedulingIgnoredDuringExecution：硬策略
親和性/反親和性調(diào)度策略比較如下：
kubectl get pod --show-labels
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-3
labels:
app: pod-3
spec:
containers:
- name: pod-3
image: hub.atguigu.com/library/myapp:v1
affinity:
#想讓兩個pod運行在同一個node上
podAffinity:
#硬策略
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector: #標簽選擇
matchExpressions:
- key: app #當app存在node-affinity-pod時就選擇
operator: In
values:
- node-affinity-pod
topologyKey: kubernetes.io/hostname
#hostname判斷是否在同一個pod，唯一
發(fā)覺處于同一個拓撲域topologyKey
vim pod4.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-4
labels:
app: pod-4
spec:
containers:
- name: pod-4
image: hub.atguigu.com/library/myapp:v1
affinity:
#不想讓兩個pod運行在同一個node上
#匹配標簽如果app=pod-2，那么則不運行在這個節(jié)點
podAntiAffinity:
#軟策略
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app #匹配app=node-affinity-pod
operator: In
values:
- node-affinity-pod
topologyKey: kubernetes.io/hostname
補充：如果標簽不滿足的情況，改標簽的話就能滿足
kubectl label pod podname app=label --overwrite=true
六、Taint 和 Toleration
節(jié)點親和性，是pod的一種屬性（偏好或硬性要求），它使pod被吸引到一類特定的節(jié)點。Taint 則相反，它使節(jié)點能夠排斥一類特定的 pod
Taint 和 toleration 相互配合，可以用來避免 pod 被分配到不合適的節(jié)點上。每個節(jié)點上都可以應用一個或多個taint ，這表示對于那些不能容忍這些 taint 的 pod，是不會被該節(jié)點接受的。如果將 toleration 應用于 pod上，則表示這些 pod 可以（但不要求）被調(diào)度到具有匹配 taint 的節(jié)點上
污點 (Taint)
1、污點 ( Taint ) 的組成
使用kubectl taint命令可以給某個 Node 節(jié)點設置污點，Node 被設置上污點之后就和 Pod 之間存在了一種相斥的關系，可以讓 Node 拒絕 Pod 的調(diào)度執(zhí)行，甚至將 Node 已經(jīng)存在的 Pod 驅(qū)逐出去每個污點的組成如下：
key=value:effect
每個污點有一個 key 和 value 作為污點的標簽，其中 value 可以為空，effect 描述污點的作用。
當前 taint effect 支持如下三個選項：
- NoSchedule：表示k8s將不會將Pod調(diào)度到具有該污點的Node上（K8Snode添加這個effecf類型污點，新的不能容忍的pod不能再調(diào)度過來，但是老的運行在node上不受影響）
- PreferNoSchedule：表示k8s將不會將Pod調(diào)度到具有該污點的Node上，同時會將Node上已經(jīng)存在的Pod驅(qū)逐出去（pod會嘗試將pod分配到該節(jié)點）
- NoExecute：表示k8s將盡量避免將Pod調(diào)度到具有該污點的Node上（K8Snode添加這個effecf類型污點，新的不能容忍的pod不能調(diào)度過來，老的pod也會被驅(qū)逐）
這也是為什么生成的pod不會分配到master的原因（因為天生就打了這個污點NoSchedule）
2、污點的設置、查看和去除
#查看節(jié)點污點 模板：kubectl describe node node-name kubectl describe node k8s-node01 # 設置污點 模板：kubectl taint nodes node1 key1=value1:NoSchedule kubectl taint nodes k8s-node01 check=guozige:NoExecute 因為pod是自主式pod，沒有控制器控制的pod。去除后就不存在了 如果是Deployment和StatefullSet，它就會在node02上創(chuàng)建，維持副本數(shù) # 節(jié)點說明中，查找 Taints 字段 kubectl describe node k8s-node01 # 去除污點 模板：kubectl taint nodes node1 key1=value1:NoSchedule- kubectl taint nodes k8s-node01 check=guozige:NoExecute-
設置污點測試
容忍(Tolerations)
設置了污點的 Node 將根據(jù) taint 的 effect：NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之間產(chǎn)生互斥的關系，Pod 將在一定程度上不會被調(diào)度到 Node 上。但我們可以在 Pod 上設置容忍 ( Toleration ) ，意思是設置了容忍的 Pod 將可以容忍污點的存在，可以被調(diào)度到存在污點的 Node 上
pod.spec.tolerations
tolerations: #containers同級 - key: "check" #能容忍的污點key operator: "Equal" #Equal等于表示key=value ， Exists不等于，表示當值不等于下面value正常 value: "guozige" #值 effect: "NoExecute" #effect策略 tolerationSeconds: 3600 #原始的pod多久驅(qū)逐，注意只有effect: "NoExecute"才能設置，不然報錯
- 其中 key, vaule, effect 要與 Node 上設置的 taint 保持一致
- operator 的值為 Exists 將會忽略 value 值
- tolerationSeconds 用于描述當 Pod 需要被驅(qū)逐時可以在 Pod 上繼續(xù)保留運行的時間
vim pod3.yaml
kubectl apply -f pod3.yaml kubectl get pod -o wide
容忍污點
1、當不指定 key 值時，表示容忍所有的污點 key：
tolerations: - operator: "Exists"
2、當不指定 effect 值時，表示容忍所有的污點作用
tolerations: - key: "key" operator: "Exists"
3、有多個 Master 存在時，防止資源浪費，可以如下設置
kubectl taint nodes Node-Name node-role.kubernetes.io/master=:PreferNoSchedule PreferNoSchedule 盡可能不在該節(jié)點上運行，只有當節(jié)點資源不夠用才運行
配置節(jié)點故障后Pod重新調(diào)度的時間
例如下面的配置文件，對于notReady和unreachable狀態(tài)的節(jié)點，其上的Pod等待300秒，如果仍未恢復，則會停止執(zhí)行。
八、指定調(diào)度節(jié)點
親和性和污點，容忍都比較含蓄。
指定調(diào)度節(jié)點是絕對指定目標，就要這個
1、Pod.spec.nodeName 將 Pod 直接調(diào)度到指定的 Node 節(jié)點上，會跳過 Scheduler 的調(diào)度策略，該匹配規(guī)則是強制匹配
vim pod5.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: myweb
spec:
replicas: 7
template:
metadata:
labels:
app: myweb
spec:
nodeName: k8s-node01 #指定全在node01
containers:
- name: myweb
image: hub.atguigu.com/library/myapp:v1
ports:
- containerPort: 80
2、Pod.spec.nodeSelector：通過 kubernetes 的 label-selector 機制選擇節(jié)點，由調(diào)度器調(diào)度策略匹配 label，而后調(diào)度 Pod 到目標節(jié)點，該匹配規(guī)則屬于強制約束
vim pod6.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: myweb66
spec:
replicas: 2
template:
metadata:
labels:
app: myweb66
spec:
nodeSelector:
disk: ssd #硬盤必須是ssd類型才運行
#type: backEndNode1 #標簽名，標簽值
containers:
- name: myweb66
image: hub.atguigu.com/library/myapp:v1
ports:
- containerPort: 80
測試驗證
kubectl label node k8s-node01 disk=ssd kubectl label node k8s-node02 disk=ssd kubectl edit deployment myweb66 增加副本數(shù)目 kubectl get pod 發(fā)現(xiàn)有些在node02上了
總結(jié)
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
這篇文章主要介紹了使用sealos快速搭建K8s集群環(huán)境,主要包括sealos安裝方法，虛擬機設置方法，本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-09-09
Kubernetes?安裝flannel組件的過程(本地?kube-flannel.yml?文件)
文章介紹了如何在無法直接訪問raw.githubusercontent.com的情況下,通過科學上網(wǎng)或下載kube-flannel.yml文件源碼來部署Flannel網(wǎng)絡插件的方法,感興趣的朋友一起看看吧2025-03-03
文章介紹了如何規(guī)劃和部署一個Kubernetes高可用集群,包括環(huán)境準備、節(jié)點配置、Docker安裝、Kubernetes組件安裝和配置、高可用組件部署以及私有倉庫Harbor的安裝2026-03-03
secret用于加密pod訪問數(shù)據(jù)庫的用戶憑證，這篇文章主要介紹了k8s中secret的用法詳解，本文通過實例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-04-04
Kubernetes的Pod默認調(diào)度由kube-scheduler負責,通過過濾和打分兩個階段,將Pod公平、高效地分配到集群節(jié)點上,默認調(diào)度策略包括資源檢查、節(jié)點標簽、污點容忍、親和性等規(guī)則,默認調(diào)度器實現(xiàn)了負載均衡和高可用性,但在特定場景下可能需要自定義調(diào)度策略2026-02-02
文章詳細介紹了keepalived高可用模式下`nopreempt`非搶占模式的應用場景,并探討了不同配置下的VIP故障轉(zhuǎn)移行為,同時,文章還解釋了`notify`腳本的作用,包括觸發(fā)時機和典型用途2026-01-01
區(qū)塊鏈是一項新技術。之所以快速吸引人們的關注，是因為比特幣在2017年的暴漲，迅速吸引了大眾的視線。而比特幣的底層技術，主要是區(qū)塊鏈技術2018-03-03
文章介紹了如何在Kubernetes環(huán)境中通過DNS獲取POD的IP,并將其用于注冊到Consul,通過修改服務啟動腳本和Kubernetes樣本文件,使得微服務能夠獲取POD信息并使用該IP注冊到Consul,從而實現(xiàn)服務間的發(fā)現(xiàn)和通信2026-02-02
Centos?8.2?升級內(nèi)核通過elrepo源的方法
這篇文章主要介紹了Centos?8.2?升級內(nèi)核通過elrepo源,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-10-10
有時間還是多學習知識比較好，這篇文章主要介紹了Spark三種屬性配置方式詳解，具有一定參考價值，需要的朋友可以了解下。2017-10-10