概述
什麼是 kube-scheduler ?
Kubernetes 集羣的核心組件之一，它負責爲新創建的 Pods 分配節點。它根據多種因素進行決策，包括：
- 資源需求和限制：考慮每個 Pod 請求的資源量（如 CPU 和內存）以及節點上可用的資源。
- 親和性和反親和性規則：根據 Pod 的親和性設置選擇最適合的節點。
- 健康檢查：確保選擇的節點健康且能夠運行 Pod。
- 負載均衡：儘量平衡集羣中各個節點的負載。
使用
limits 和 reuqests
在部署對象中的 spec 中常常會見到關於 limits 和 requests 的聲明 ，例如：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: 1Gi
cpu: 1
requests:
memory: 256Mi
cpu: 100m
這裏的 limits 和 requests 是與 Pod 容器資源管理相關的兩個關鍵概念：
- Limits：指定容器運行時能夠使用的最大資源量
- Requests：指定容器啓動時最低需要的資源量
limits 和 requests 跟 scheduler 有什麼關係 ？
在集羣中 kube-scheduler 一直是默默無聞的幕後工作者，它主要工作內容如下：
- 當你創建一個 Deployment，如這個
nginx，是由 kube-scheduler 決策將其調度到哪個 Node 上運行的 - kube-scheduler 會監聽 apiserver 獲取集羣全局視圖，然後根據 Pod 的資源請求（requests 和 limits）分析
- 最終 kube-scheduler 會結合資源請求和集羣的實際情況來調度 Pod
總之，kube-scheduler 會保證 Pod 會調度到滿足其運行資源需求的 Node 節點上。
LimitRange
描述
LimitRange 是資源描述對象，主要用於限制命名空間內資源的使用。它可以設置默認的資源請求和限制，以及資源使用的最大和最小值。它可以確保每個 Pod 或容器在資源使用上遵循特定的策略，從而避免單個 Pod 或容器佔用過多資源。使用示例如下：
創建一個 YAML 文件保存 LimitRange 內容，例如：mem-limit-range.yaml：
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
應用到集羣：
$ kubectl apply -f mem-limit-range.yaml
查看創建的 LimitRange 對象：
$ kubectl describe limitrange mem-limit-range
輸出：
Name: mem-limit-range
Namespace: default
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory - - 256Mi 512Mi -
說明：
- Kind：設置爲 LimitRange，用於限制命名空間內資源的使用。
- Metadata：設置資源的名稱
- Spec：
- Limits：
- default：指定沒有明確資源限制的容器的默認內存限制爲 512Mi
- defaultRequest：指定沒有明確資源請求的容器的默認內存請求。這裏設置爲 256Mi
- type：應用這些限制的資源類型，在這裏是
Container
驗證
定義一個沒有聲明資源請求的部署對象，文件命名爲： nginx-without-resource.yaml ，如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
應用部署到集羣：
$ kubectl apply -f nginx-without-resource.yaml
等 Pod 創建後，可以通過檢查它們的配置來確認 LimitRange 是否生效。
$ kubectl describe pod [POD_NAME]
輸出：
Containers:
#.. ignore
Limits:
memory: 512Mi
Requests:
memory: 256Mi
initContainers
initContainers 用於在主應用容器啓動之前執行一些預備任務。常見於以下場景：
- 準備工作：設置需要的配置文件、數據庫遷移、等待其他服務就緒等。
- 安全性：權限提升操作，如改變文件權限或者執行特定的安全檢查。
- 服務依賴性：等待其他服務或數據庫可用。
initContainers 在執行完其任務後會停止，且必須成功完成才能啓動主容器。非常適合用於啓動前的初始化任務。
示例：
在部署對象中聲明 initContainers 屬性：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 10']
containers:
- name: nginx
image: nginx
將部署對象應用到集羣：
$ kubectl apply -f init-container.yaml
當 Pod 啓動後，可以通過查看事件日誌驗證容器的加載順序：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m20s default-scheduler Successfully assigned default/nginx-deployment-6445f86ddc-fmmzw to docker-desktop
Normal Pulling 2m20s kubelet Pulling image "busybox:1.28"
Normal Pulled 116s kubelet Successfully pulled image "busybox:1.28" in 23.099396719s (23.099404677s including waiting)
Normal Created 116s kubelet Created container init-myservice
Normal Started 116s kubelet Started container init-myservice
Normal Pulling 106s kubelet Pulling image "nginx"
Normal Pulled 88s kubelet Successfully pulled image "nginx" in 18.382000675s (18.382006008s including waiting)
Normal Created 88s kubelet Created container nginx
Normal Started 88s kubelet Started container nginx
可以看到 initContainers 聲明的容器已經加載，然後查看特定的日誌，來檢查 Pod 日誌輸出：
$ kubectl logs [POD_NAME] -c init-myservice
輸出：
The app is running!
驗證完成。
initContainers 和 kube-scheduler 的關係 ？
如果 initContainers 沒有聲明資源需求，默認也會使用 LimitRange 聲明的默認資源，這也意味着，initContainers 也是由 kube-scheduler 來調度創建的。所以在 initContainers 中加上資源需求也會影響着 kube-scheduler 的調度決策。
nodeSelector
在部署對象中，nodeSelector 屬性的作用是用於把指定 Pod 調度到具有特定標籤的節點上。如果沒有滿足要求的 Node 節點，則 Pod 會持續等待，示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
disktype: ssd
在這個例子中 nodeSelector 屬性值爲：disktype: ssd 。這表明這個 Pod 應該被調度到標籤爲 disktype=ssd 的 Node 節點上。kube-scheduler 在調度時，會選擇合適的節點以運行這個 Pod 時。
先將部署對象應用到集羣中：
$ kubectl apply -f node-selector.yaml
然後查看 Pod 狀態：
$ kubectl get pod
輸出：
NAME READY STATUS RESTARTS AGE
nginx-deployment-f5bc98d57-pmq9v 0/1 Pending 0 2m17s
可以看到創建的 Pod 一直保持在 "Pending" 狀態。通過事件日誌查看具體原因：
$ kubectl describe pod [POD_NAME]
輸出：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 4m38s default-scheduler 0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
從事件日誌可以看出，這個 Pod 不能被調度，因爲沒有節點滿足其設定的節點選擇條件。因爲我的集羣中確實沒有任何標記爲 disktype: ssd 的節點在運行。
Affinity 親和性
NodeSelector 的演進版本，提供了更復雜的選擇規則。除了簡單的匹配，它們還支持更豐富的條件表達式，如 "存在"、"不等於"、"在集合中" 等，並且支持對 Pod 之間（Pod Affinity/Anti-Affinity）以及 Pod 與節點之間（Node Affinity）的親和性/反親和性設置。在 Kubernetes 後續版本中 Affinity 也逐漸替代了 NodeSelector。
podAffinity
podAffinity 用於定義 Pods 之間的親和性。使得某個 Pod 被調度到與其他特定標籤的 Pod 相同的節點上。
使用場景：當希望一組服務緊密地協同工作時，比如一個應用的不同組件需要低延遲通訊。
示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-anti
spec:
replicas: 2
selector:
matchLabels:
app: anti-nginx
template:
metadata:
labels:
app: anti-nginx
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: a
operator: In
values:
- b
topologyKey: kubernetes.io/hostname
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- anti-nginx
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: nginx
部署文件展示親和性（Affinity）設置：
- PodAffinity：要求調度的 Pod 必須與具有特定標籤（鍵
a，值b）的 Pod 在相同的節點上。 - PodAntiAffinity：要求調度的 Pod 不能與具有相同標籤（鍵
app，值anti-nginx）的 Pod 在相同的節點上。
將上面部署文件應用到集羣后，查看 Pods 的分佈情況：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-anti-5656fcbb98-62mds 0/1 Pending 0 5s <none> <none> <none> <none>
nginx-anti-5656fcbb98-wxphs 0/1 Pending 0 5s <none> <none> <none> <none>
可以 Pod 因爲親和性規則無法調度一直處於等待狀態，查看特定 Pod 的事件日誌可以驗證：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 27s default-scheduler 0/1 nodes are available: 1 node(s) didn't match pod affinity rules. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
利用 Pod 親和性和反親和性規則來控制 Pod 的調度位置，以實現特定的調度需求和負載分佈。
nodeAffinity
用於定義 Pod 與節點之間的親和性。控制 Pod 被調度到具有特定標籤或屬性的節點上。
適用場景：當您需要根據硬件特性（如 GPU、高性能存儲）或其他自定義標籤（如環境標籤）調度 Pod 時。
示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
部署文件的親和性（Affinity）設置：
nodeAffinity被設置爲要求 Pod 被調度到具有disktype: ssd標籤的節點上。
將上面部署文件應用到集羣后，查看 Pod 的運行情況：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-565d7797dc-jf5nk 0/1 Pending 0 14s <none> <none> <none> <none>
可以 Pod 因爲親和性規則無法調度一直處於等待狀態，查看特定 Pod 的事件日誌可以驗證：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 89s default-scheduler 0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
preferredDuringSchedulingIgnoredDuringExecution
和之前的 requiredDuringScheduling 調度類型不同，preferredDuringScheduling 表明其是一個偏好性的調度，調度器會根據偏好優先選擇滿足對應規則的節點來調度Pod。但如果找不到滿足規則的節點，調度器則會選擇其他節點來調度Pod。
示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
配置說明：這裏使用的是 preferredDuringSchedulingIgnoredDuringExecution 類型，這意味着調度器會盡量但不強制將 Pod 調度到具有 disktype: ssd 標籤的節點上。
將上面部署文件應用到集羣后，查看 Pod 的運行情況：
NAME READY STATUS RESTARTS AGE
nginx-deployment-69c654d896-7qh8t 1/1 Running 0 28s
可以看到雖然我本地沒有滿足親和性規則的 Node 節點，但是 Pod 依然可以調度起來了。
總結：
podAffinity關注的是 Pod 之間的關係不同nodeAffinity更關注 Pod 與節點特性之間的關係- requiredDuringScheduling：硬親和，強制型調度規則，必須滿足親和性設置，否則不能調度
- preferredDuringScheduling：軟親和，偏好型調度規則，首先找到滿足設置的節點，沒有則會調度到其他節點
Taints 污點
Taints 和 Tolerations 是 Kubernetes 中用於控制 Pod 調度到特定節點的一種機制，相比 Affinity 親和性 **相似性 **的機制，Taints 的規則是屬於 排斥性 的機制，用來“排斥”不滿足特定條件的 Pod。
Taints 有三種效果：
NoSchedule（不會調度新 Pod）PreferNoSchedule（儘量避免調度新 Pod）NoExecute（新 Pod 不會調度且已存在 Pod 可能會被遷移）
Taints 常見的應用場景：
- 對於集羣中不想共享的 Node，可以加上 Taints 標籤表示獨享
- 用於多租戶 Kubernetes 計算資源隔離
- Kubernetes 本身使用 Taints 機制驅除不可用的 Node
使用示例：
給節點添加 Taint，防止所有 Pod 自動調度到該節點，除非它們具有匹配的 Tolerations：
$ kubectl taint nodes docker-desktop for-special-user=cadmin:NoSchedule
先定義一個沒有任何 Tolerations 的 Pod 來驗證：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
將它應用到集羣，查看 Pod 狀態會一直處於 Pending：
NAME READY STATUS RESTARTS AGE
nginx-deployment-77b4fdf86c-wm5f9 0/1 Pending 0 23s
從事件日誌可以看到是 Taints 在發揮作用：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 56s default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {for-special-user: cadmin}. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
然後再 Pod 定義中添加 Tolerations，允許它被調度到帶有特定 Taint 的節點上：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
tolerations:
- key: "for-special-user"
operator: "Equal"
value: "docker-desktop"
effect: "NoSchedule"
這個部署文件設置了一個 容忍度 (Tolerations) 規則：允許 Pod 被調度到標記爲 for-special-user=docker-desktop 並且具有 NoSchedule 效果的節點上。
將它應用到集羣，查看 Pod 狀態：
NAME READY STATUS RESTARTS AGE
nginx-deployment-dd7d69c9c-77qlf 1/1 Running 0 31s
Pod 已經正常調度，這也是 Taints 發揮作用。
如果節點不在需要 Tanints 作爲排除，可以移除 ：
$ kubectl taint nodes docker-desktop for-special-user=cadmin:NoSchedule-
輸出：
node/docker-desktop untainted
PriorityClass
PriorityClass 用於定義 Pod 的調度優先級。常見的場景包括：
- 確保關鍵服務優先調度：對於關鍵組件，如數據庫、核心應用服務，可以設置更高的優先級。
- 管理資源爭用：在資源有限的環境中，通過設置不同的優先級，管理不同 Pod 的調度順序。
使用 PriorityClass 的步驟：
-
創建 PriorityClass：
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "This priority class should be used for XYZ service pods only."
說明：
- value：這是一個整數，表示該 PriorityClass 的優先級。較高的數值表示更高的優先級。
- globalDefault：表示爲集羣中所有沒有指定優先級的 Pod 的默認優先級。
- 在 Pod 中指定 PriorityClass：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
priorityClassName: high-priority
containers:
- name: mycontainer
image: myimage
通過 priorityClassName 應用剛纔創建的 PriorityClass，從而確保該 Pod 具有更高的調度優先級。
自定義 scheduler
默認的調度器是面向通用的使用場景設計的，如果默認的 Kubernetes 調度器無法滿足需求，也可以通過自定義的調度器來滿足更加個性化的需求，示例：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
schedulerName: my-custom-scheduler
containers:
- name: mycontainer
image: myimage
社區也有很多成熟開源的自定義調度器，例如：
- 騰訊 TKE 的調度器
- 華爲 volcano 調度器
另外也可以參考 kube-scheduler 源碼實現一個自己的調度器。