Kubernetes-15：一文詳解Pod、Node排程規則(親和性、汙點、容忍、固定節點)

Running的菜鳥發表於2020-09-03

Kubernetes Pod排程說明

簡介

Scheduler 是 Kubernetes 的排程器，主要任務是把定義的Pod分配到叢集的節點上，聽起來非常簡單，但要考慮需要方面的問題：

  • 公平：如何保證每個節點都能被分配到資源
  • 資源高效利用：叢集所有資源最大化被使用
  • 效率：排程效能要好，能夠儘快的對大批量的Pod完成排程工作
  • 靈活：允許使用者根據自己的需求控制排程的流程

Scheduler 是作為單獨的服務執行的，啟動之後會一直監聽API Server，獲取 podSpec.NodeName為空的Pod，對每個Pod都會建立一個buiding，表明該Pod應該放在哪個節點上

 

排程過程

排程流程：首先過濾掉不滿足條件的節點，這個過程稱為predicate；然後對通過的節點按照優先順序的順序，這個是priority；最後從中選擇優先順序最高的節點。如果中間有任何一步報錯，則直接返回錯誤資訊。

 
Predicate有一系列的演算法可以使用：
  • PodFitsResources：節點上剩餘的資源是否大於 Pod 請求的資源
  • PodFitsHost：如果Pod指定了nodeName，檢查節點名稱是否和nodeName匹配
  • PodFitsHostPort：節點上已經使用的port是否和Pod申請的port衝突
  • PodSelectorMatches：過濾和Pod指定的 label 不匹配的節點
  • NoDiskConflict：已經 mount 的 volume 和 Pod 指定的volume不衝突，除非他們都是隻讀

如果在predicate過程中沒有適合的節點，Pod會一直處於Pending狀態，不斷重新排程，直到有節點滿足條件，經過這個步驟，如果多個節點滿足條件，就會進入priority過程：按照優先順序大小對節點排序，優先順序由一系列鍵值對組成，鍵是該優先順序的名稱，值是它的權重，這些優先順序選項包括：

  • LeastRequestedPriority：通過計算CPU和Memory的使用率來決定權重，使用率越低權重越高，換句話說，這個優先順序傾向於資源使用率低的節點
  • BalanceResourceAllocation：節點上CPU和Memory使用率非常及接近，權重就越高，這個要和上邊的一起使用，不可單獨使用
  • ImageLocalityPriority：傾向於已經要使用映象的節點，映象的總大小值越大，權重越高

通過演算法對所有的優先順序專案和權重進行計算，得出最終的結果

 

自定義排程器

除了Kubernetes自帶的排程器，也可以編寫自己的排程器，通過spec.schedulername引數指定排程器的名字，可以為Pod選擇某個排程器進行排程，比如下邊的Pod選擇my-scheduler進行排程，而不是預設的default-scheduler

apiVersion: v1
kind: Pod
metadata:
  name: scheduler-test
  labels:
    name: example-scheduler
spec:
  schedulername: my-scheduler
  containers:
  - name: Pod-test
    image: nginx:v1

 

下邊開始正式介紹Pod的各種排程方法！！！

 

一、親和性

注意，以下所有的測試都是1Master、1Node的情況下：

[root@Centos8 scheduler]# kubectl get node
NAME          STATUS   ROLES    AGE    VERSION
centos8       Ready    master   134d   v1.15.1
testcentos7   Ready    <none>   133d   v1.15.1

 

1、節點親和性

pod.spec.affinity.nodeAffinity

  • preferredDuringSchedulingIgnoredDuringExecution：軟策略
    • 軟策略是偏向於，更想(不)落在某個節點上，但如果實在沒有，落在其他節點也可以
  • requiredDuringSchedulingIgnoredDuringExecution：硬策略
    • 硬策略是必須(不)落在指定的節點上，如果不符合條件，則一直處於Pending狀態
requiredDuringSchedulingIgnoredDuringExecution硬策略

vim node-affinity-required.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity-required
  labels:
      app: node-affinity-pod
spec:
  containers:
  - name: with-node-required
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname    #節點名稱
            operator: NotIn        #不是
            values:
            - testcentos7          #node節點
[root@Centos8 ~]# kubectl get node --show-labels    #檢視node節點標籤
NAME          STATUS   ROLES    AGE    VERSION   LABELS
centos8       Ready    master   133d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=centos8,kubernetes.io/os=linux,node-role.kubernetes.io/master=

testcentos7   Ready    <none>   133d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=testcentos7,kubernetes.io/os=linux

## 目前只有兩個節點，一個master 一個node，策略中表示此Pod必須不在testcentos7這個節點上
## Pod建立之後，因為除去testcentos7節點已再無其他node，Master節點又不能被排程，所以一直處於Pending狀態

[root@Centos8 scheduler]# kubectl create -f node-affinity-required.yaml 
pod/affinity-required created
[root@Centos8 scheduler]# kubectl get pod 
NAME                READY   STATUS    RESTARTS   AGE
affinity-required   0/1     Pending   0          4s

[root@Centos8 scheduler]# kubectl describe pod affinity-required
default-scheduler  0/2 nodes are available: 1 node(s) didn't match node selector, 1 node(s) had taints that the pod didn't tolerate.

將yaml檔案中，NotIn改為In

affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname    #節點名稱
            operator: In        #是，存在
            values:
            - testcentos7            #node節點

再次建立，已經落在指定node節點中

[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE     
affinity-required   1/1     Running   0          11s  10.244.3.219  testcentos7

 

preferredDuringSchedulingIgnoredDuringExecution軟策略

vim node-affinity-preferred.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity-preferred
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-preferred
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1    #權重為1,軟策略中權重越高匹配到的機會越大
        preference:  #更偏向於
          matchExpressions:
          - key: kubernetes.io/hostname #node名稱
            operator: In  #等於，為
            values:
            - testcentos7   #node真實名稱
## 更想落在node節點名稱為testcentos7的node中
[root@Centos8 scheduler]# kubectl create -f node-affinity-prefered.yaml 
pod/affinity-prefered created

[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE     
affinity-prefered   1/1     Running   0          9s    10.244.3.220 testcentos7

更改一下策略，將node節點名稱隨便更改為不存在的node名稱，例如kube-node2

affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1    #權重為1,軟策略中權重越高匹配到的機會越大
        preference:  #更偏向於
          matchExpressions:
          - key: kubernetes.io/hostname #node名稱
            operator: In  #等於，為
            values:
            - kube-node2   #node真實名稱
[root@Centos8 scheduler]# kubectl create -f node-affinity-prefered.yaml 
pod/affinity-prefered created

##建立後，同樣是落在了testcentos7節點上，雖然它更想落在kube-node2節點上，但沒有，只好落在testcentos7節點中
[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE     
affinity-prefered   1/1     Running   0          17s   10.244.3.221 testcentos7

 

軟硬策略合體

vim node-affinity-common.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity-node
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-affinity-node
    image: nginx:v1
    imagePullPulicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - k8s-node2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1 
        preference:
        matchExpressions:
        - key: source
          operator: In
          values:
           - hello

軟硬結合達到一個更為準確的node選擇，以上檔案意思為此Pod必須不存在k8s-node2節點中，其他的節點都可以，但最好落在label中source的值為hello的節點中

 
鍵值運算關係
  • In：label 的值在某個列表裡
  • NotIn：label 的值不在某個列表中
  • Gt：label 的值大於某個值
  • Lt：label 的值小於某個值
  • Exists：某個 label 存在
  • DoesNotExist：某個 label 不存在

如果nodeSelectorTerms下面有多個選項，滿足任何一個條件就可以了；如果matchExpressions有多個選項，則必須滿足這些條件才能正常排程

 

2、Pod親和性

pod.spec.affinity.podAffinity/podAntiAffinity

  • preferedDuringSchedulingIgnoredDuringExecution：軟策略
    • 軟策略是偏向於，更想(不)落在某個節點上，但如果實在沒有，落在其他節點也可以
  • requiredDuringSchedulingIgnoredDuringExecution：硬策略
    • 硬策略是必須(不)落在指定的節點上，如果不符合條件，則一直處於Pending狀態
先建立一個測試Pod

vim pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    app: nginx
    type: web
spec:
  containers:
  - name: pod-1
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: web
      containerPort: 80
[root@Centos8 scheduler]# kubectl create -f pod.yaml 
pod/pod-1 created

[root@Centos8 scheduler]# kubectl get pod --show-labels
NAME    READY   STATUS    RESTARTS   AGE   LABELS
pod-1   1/1     Running   0          4s    app=nginx,type=web
 
requiredDuringSchedulingIgnoredDuringExecution Pod硬策略

vim pod-affinity-required.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity-required
  labels:
    app: pod-3
spec:
  containers:
  - name: with-pod-required
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
  affinity:
    podAffinity:   #在同一域下
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app    #標籤key
            operator: In
            values:
            - nginx     #標籤value
        topologyKey: kubernetes.io/hostname #域的標準為node節點的名稱

以上檔案策略為：此必須要和有label種app：nginx的pod在同一node下

建立測試:
[root@Centos8 scheduler]# kubectl create -f pod-affinity-required.yaml 
pod/affinity-required created

[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE  
affinity-required   1/1     Running   0          43s   10.244.3.224 testcentos7
pod-1               1/1     Running   0          10m   10.244.3.223 testcentos7

# 和此標籤Pod在同一node節點下

 

將podAffinity改為podAnitAffinity，使它們不在用於node節點下

apiVersion: v1
kind: Pod
metadata:
  name: required-pod2
  labels:
    app: pod-3
spec:
  containers:
  - name: with-pod-required
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
  affinity:
    podAntiAffinity:   
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app    #標籤key
            operator: In
            values:
            - nginx     #標籤value
        topologyKey: kubernetes.io/hostname #域的標準為node節點的名稱

此策略表示，必須要和label為app:nginx的pod在不用的node節點上

建立測試：
[root@Centos8 scheduler]# kubectl create -f pod-affinity-required.yaml 
pod/required-pod2 created

[root@Centos8 scheduler]# kubectl get pod 
NAME                READY   STATUS    RESTARTS   AGE
affinity-required   1/1     Running   0          9m40s
pod-1               1/1     Running   0          19m
required-pod2       0/1     Pending   0          51s

## 由於我這裡只有一個節點，所以required-pod2只能處於Pending狀態

 

preferedDuringSchedulingIgnoredDuringExecution Pod軟策略
vim pod-affinity-prefered.yaml
...
apiVersion: v1
kind: Pod
metadata:
  name: affinity-prefered
  labels:
    app: pod-3
spec:
  containers:
  - name: with-pod-prefered
    image: nginx:v1
    imagePullPolicy: IfNotPresent
  affinity:
    podAntiAffinity:    #不在同一個域下
      preferedDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - pod-2
          topologyKey: kubernetes.io/hostname
...

軟策略和硬策略的方法基本類似，只是新增了權重，表示更喜歡而已，也可以接受其他，在此就不再演示

親和性/反親和性排程策略比較如下：
排程策略匹配標籤操作符拓撲域支援排程目標
nodeAffinity 主機 In,NotIn,Exists,DoesNotExists,Gt,Lt 否 指定主機
podAffinity Pod In,NotIn,Exists,DoesNotExists,Gt,Lt 是 pod與指定pod在一拓撲域
podAnitAffinity Pod In,NotIn,Exists,DoesNotExists,Gt,Lt 是 pod與指定pod不在一拓撲域

 

二、汙點(Taint)和容忍(Toleration)

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

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

注意，以下所有的測試都是1Master、1Node的情況下：

[root@Centos8 scheduler]# kubectl get node
NAME          STATUS   ROLES    AGE    VERSION
centos8       Ready    master   134d   v1.15.1
testcentos7   Ready    <none>   133d   v1.15.1

 

1、汙點（Taint）

（1）汙點的組成

使用kubectl taint 命令可以給某個node節點設定汙點，Node被設定上汙點之後就和Pod之間存在了一種相斥的關係，可以讓Node拒絕Pod的排程執行，甚至將已經存在得Pod驅逐出去

每個汙點的組成如下：

key=value:effect

每個汙點有一個 key 和 value 作為汙點標籤，其中 value 可以為空，effect描述汙點的作用，當前 taint effect 支援如下三個選項：

  • NoSchedule：表示 k8s 不會將Pod排程到具有該汙點的Node上
  • PreferNoSchedule：表示 k8s 將盡量避免將Pod排程到具有該汙點的Node上
  • NoExecute：表示 k8s 將不會將Pod排程到具有該汙點的Node上，同時會將Node上已有的Pod驅逐出去
 
（2）汙點的設定、檢視和去除

k8s的master節點本身就帶有汙點，這也是為什麼k8s在排程Pod時，不會排程到master節點的原因，具體檢視如下：

[root@Centos8 scheduler]# kubectl describe node centos8
Taints:             node-role.kubernetes.io/master:NoSchedule
## 設定汙點
kubectl taint nodes [node name] key1=value:NoSchedule

## 節點說明中，檢視Taint欄位
kubectl describe node [node name]

## 去除汙點
kubectl taint nodes [node name] key1:NoSchedule-

 

測試效果：

## 檢視當前節點所擁有Pod，都在testcentos7中
[root@Centos8 scheduler]# kubectl get pod -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE     
affinity-required   1/1     Running   0          68m   10.244.3.224 testcentos7
pod-1               1/1     Running   0          78m   10.244.3.223 testcentos7
required-pod2       0/1     Pending   0          59m   <none>         <none>   

## 給testcentos7設定NoExecute汙點
[root@Centos8 scheduler]# kubectl taint nodes testcentos7 check=vfan:NoExecute
node/testcentos7 tainted

## 檢視Pod有沒被驅逐出去
[root@Centos8 scheduler]# kubectl get pod 
NAME            READY   STATUS    RESTARTS   AGE
required-pod2   0/1     Pending   0          62m

## 只剩一個Pending狀態的Pod，因為他還沒建立，所以還未分配Node

檢視 testcentos7 節點資訊

[root@Centos8 scheduler]# kubectl describe node  testcentos7
Taints:             check=vfan:NoExecute

 

目前所有的節點都被打上了汙點，新建Pod測試下效果：

[root@Centos8 scheduler]# kubectl create -f pod.yaml 
pod/pod-1 created

[root@Centos8 scheduler]# kubectl get pod 
NAME            READY   STATUS    RESTARTS   AGE
pod-1           0/1     Pending   0          4s
required-pod2   0/1     Pending   0          7h18m

新建的Pod會一直處於Pending狀態，因為沒有可用的Node節點，這時候就可以使用容忍(Toleration)了

 

2、容忍(Toleration)

設定了汙點的Node將根據 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute和Pod之間產生互斥的關係，Pod將在一定程度上不會被排程到 Node 上。但我們可以在 Pod 上設定容忍(Toleration)，意思是設定了容忍的 Pod 將可以容忍汙點的存在，可以被排程到存在汙點的Node上

Pod.spec.tolerations

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
  tolerationSeconds: 3600
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "key2"
  operator: "Exists"
  effect: "NoSchedule"
  • 其中 key、value、effect 要與Node中的 taint 保持一致
  • operator 的值為 Exists 將會忽略 value 的值
  • tolerationSeconds 用於描述當Pod需要驅逐時可以在Node上繼續保留執行的時間

（1）當不指定key時，表示容忍所有汙點的key：

tolerations：
- operator: "Exists"

例如：

vim pod3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    app: nginx
    type: web
spec:
  containers:
  - name: pod-3
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: web
      containerPort: 80
  tolerations:
  - operator: "Exists"
    effect: "NoSchedule"
[root@Centos8 scheduler]# kubectl create -f pod3.yaml 
pod/pod-3 created

[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE          NOMINATED NODE   READINESS GATES
pod-1   0/1     Pending   0          14m   <none>         <none>        
pod-2   1/1     Running   0          11m   10.244.3.229   testcentos7  
pod-3   1/1     Running   0          9s    10.244.0.107   centos8

yaml策略為：可以容忍所有為NoSchedule的汙點，因為centos8為master節點，汙點預設為NoSchedule，所以Pod-3被排程到master節點

 

（2）當不指定 offect 值時，表示容忍所有的汙點型別

tolerations:
- key: "key1"
  value: "value1"
  operator: "Exists"

 

（3）Pod容忍測試用例：

vim pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    app: nginx
    type: web
spec:
  containers:
  - name: pod-2
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: web
      containerPort: 80
  tolerations:
  - key: "check"
    operator: "Equal"
    value: "vfan"
    effect: "NoExecute"
[root@Centos8 scheduler]# kubectl create -f pod2.yaml 
pod/pod-2 created

[root@Centos8 scheduler]# kubectl get pod 
NAME    READY   STATUS    RESTARTS   AGE
pod-1   0/1     Pending   0          3m25s
pod-2   1/1     Running   0          4s

設定容忍的Pod，可以正常排程到Node節點，而沒有設定容忍的，還一直處於Pending狀態

 

最後將Node汙點去除：

kubectl taint nodes testcentos7 check=vfan:NoExecute-

去除node汙點僅需在建立命令的最後加一個 - 即可

 

 

三、指定排程節點

注意，以下所有的測試都是1Master、1Node的情況下：

[root@Centos8 scheduler]# kubectl get node
NAME          STATUS   ROLES    AGE    VERSION
centos8       Ready    master   134d   v1.15.1
testcentos7   Ready    <none>   133d   v1.15.1

 

1、Pod.spec.nodeName 將 Pod 直接排程到指定的 Node 節點上，會跳過 Schedule 的排程策略，該匹配規則是強制匹配

vim nodeName1.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nodename-1
  labels:
    app: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web
    spec:
      nodeName: testcentos7
      containers:
      - name: nodename-1
        image: nginx:1.2.1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
[root@Centos8 scheduler]# kubectl apply -f nodeName1.yaml 
deployment.extensions/nodename-1 created

[root@Centos8 scheduler]# kubectl get pod -o wide 
NAME                 READY   STATUS    RESTARTS   AGE   IP             NODE
nodename-1-7f4c7db4d4-hdcjv   1/1  Running   0   92s   10.244.3.240 testcentos7
nodename-1-7f4c7db4d4-xxrj8   1/1  Running   0   93s   10.244.3.238 testcentos7
nodename-1-7f4c7db4d4-zkt2c   1/1  Running   0   92s   10.244.3.239 testcentos7

以上策略表示，所有Deployment所有的副本，均要排程到testcentos7節點上

為了對比效果，修改yaml檔案中Node節點為centos8

nodeName: centos8

再次建立測試

[root@Centos8 scheduler]# kubectl delete -f nodeName1.yaml 

[root@Centos8 scheduler]# kubectl apply -f nodeName1.yaml 
deployment.extensions/nodename-1 created

NAME                          READY   STATUS    RESTARTS   AGE    IP     NODE
nodename-1-7d49bd7849-ct9w5   1/1     Running   0  2m2s   10.244.0.112  centos8
nodename-1-7d49bd7849-qk9mm   1/1     Running   0  2m2s   10.244.0.113  centos8
nodename-1-7d49bd7849-zdphd   1/1     Running   0  2m2s   10.244.0.111  centos8

全部落在了centos8節點中

 

2、Pod.spec.nodeSelector：通過 kubernetes 的 label-selector 機制選擇節點，由排程策略匹配 label，而後排程 Pod 到目標節點，該匹配規則屬於強制約束

vim nodeSelect1.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: node-1
  labels: 
    app: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myweb
    spec:
      nodeSelector:
        type: ssd    # Node包含的標籤
      containers:
      - name: myweb
        image: nginx:1.2.1
        ports:
        - containerPort: 80
[root@Centos8 scheduler]# kubectl apply -f nodeSelect1.yaml 
deployment.extensions/node-1 created

[root@Centos8 scheduler]# kubectl get pod 
NAME                      READY   STATUS    RESTARTS   AGE
node-1-684b6cc685-9lzbn   0/1     Pending   0          3s
node-1-684b6cc685-lwzrm   0/1     Pending   0          3s
node-1-684b6cc685-qlgjq   0/1     Pending   0          3s

[root@Centos8 scheduler]# kubectl get node --show-labels
NAME          STATUS   ROLES    AGE    VERSION   LABELS
centos8       Ready    master   135d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=centos8,kubernetes.io/os=linux,node-role.kubernetes.io/master=
testcentos7   Ready    <none>   134d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=testcentos7,kubernetes.io/os=linux

以上策略表示：將Deployment的三個副本全部排程到標籤為type:ssd的Node節點上，因為沒有Node節點有此標籤，所以一直處於Pending狀態

下面我們將testcentos7節點打上標籤type:ssd

[root@Centos8 scheduler]# kubectl label node testcentos7 type=ssd
node/testcentos7 labeled

[root@Centos8 scheduler]# kubectl get pod
NAME                      READY   STATUS    RESTARTS   AGE
node-1-684b6cc685-9lzbn   1/1     Running   0          4m30s
node-1-684b6cc685-lwzrm   1/1     Running   0          4m30s
node-1-684b6cc685-qlgjq   1/1     Running   0          4m30s

打上標籤後，Pod恢復Running狀態

 

文中有不足之處歡迎指出，不勝感激！

相關文章