前述文章介紹了Kubernetes基本介紹，搭建Kubernetes集群所需要的工具，如何安裝，如何搭建應用，本篇介紹怎么使用Kubernetes進行資源調度，

Kubernetes作為一個容器編排調度引擎，資源調度是它的最基本也是最重要的功能，當開發者部署一個應用時它運行在哪個節點？這個節點滿不滿足開發的運行要求？Kubernetes又是如何進行資源調度的呢？

▌通過本文可了解到以下資訊：

資源請求及限制對pod調度的影響
查看調度事件events
了解label選擇器對pod調度的影響
了解節點親和性和Pod親和性對調度的影響
不使用調度器，手動調度一個pod
了解Daemonset的角色
了解如何配置Kubernetes scheduler

在Kubernetes中有一個kube-scheduler組件，該組件運行在master節點上，它主要負責pod的調度，Kube-scheduler監聽kube-apiserver中是否有還未調度到node上的pod（即Spec.NodeName為空的Pod），再通過特定的演算法為pod指定分派node運行，如果分配失敗，則將該pod放置調度佇列尾部以重新調度，調度主要分為幾個部分：首先是預選程序，過濾不滿足Pod要求的節點，然后是優選程序，對通過要求的節點進行優先級排序，最后選擇優先級最高的節點分配，其中涉及到的兩個關鍵點是過濾和優先級評定的演算法，調度器使用一組規則過濾不符合要求的節點，其中包括設定了資源的request和指定了Nodename或者其他親和性設定等等，優先級評定將過濾得到的節點串列進行打分，調度器考慮一些整體的優化策略，比如將Deployment控制的多個副本集分配到不同節點上等，

資源請求及限制對pod調度的影響

在部署應用時，開發者會考慮到使這個應用運行起來需要多少的記憶體和CPU資源的使用量，這樣才能判斷應將他運行在哪個節點上，在部署檔案resource屬性中添加requests欄位用于說明運行該容器所需的最少資源，當調度器開始調度該Pod時，調度程式確保對于每種資源型別，計劃容器的資源請求總和必須小于節點的容量才能分配該節點運行Pod，resource屬性中添加limits欄位用于限制容器運行時所獲得的最大資源，如果該容器超出其記憶體限制，則可能被終止，如果該容器可以重新啟動，kubelet會將它重新啟動，如果調度器找不到合適的節點運行Pod時，就會產生調度失敗事件，調度器會將Pod放置調度佇列以回圈調度，直到調度完成，

在下面例子中，運行一個nginx Pod，資源請求了256Mi的記憶體和100m的CPU，調度器將判斷哪個節點還剩余這么多的資源，尋找到了之后就會將這個Pod調度上去，同時也設定了512Mi的記憶體和300m的CPU的使用限制，如果該Pod運行之后超出了這一限制就將被重啟甚至被驅逐，

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "300m"

參考檔案：

Assign CPU Resources to Containers and Pods
Assign Memory Resources to Containers and Pods

查看調度事件events

在部署應用后，可以使用 kubectl describe 命令進行查看Pod的調度事件，下面是一個coredns被成功調度到node3運行的事件記錄，

$ kubectl describe po coredns-5679d9cd77-d6jp6 -n kube-system
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  29s   default-scheduler  Successfully assigned kube-system/coredns-5679d9cd77-d6jp6 to node3
  Normal  Pulled     28s   kubelet, node3     Container image "grc.io/kubernetes/coredns:1.2.2" already present on machine
  Normal  Created    28s   kubelet, node3     Created container
  Normal  Started    28s   kubelet, node3     Started container

下面是一個coredns被調度失敗的事件記錄，根據記錄顯示不可調度的原因是沒有節點滿足該Pod的記憶體請求，

$ kubectl describe po coredns-8447874846-5hpmz -n kube-system
...
Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  22s (x3 over 24s)  default-scheduler  0/3 nodes are available: 3 Insufficient memory.

label選擇器對pod調度的影響

例如開發者需要部署一個ES集群，由于ES對磁盤有較高的要求，而集群中只有一部分節點有SSD磁盤，那么就需要將標記一下帶有SSD磁盤的節點即給這些節點打上Lable，讓ES的pod只能運行在帶這些標記的節點上，

Lable是附著在K8S物件（如Pod、Service等）上的鍵值對，它可以在創建物件的時候指定，也可以在物件創建后隨時指定，Kubernetes最終將對labels最終索引和反向索參考來優化查詢和watch，在UI和命令列中會對它們排序，通俗的說，就是為K8S物件打上各種標簽，方便選擇和調度，

查看節點資訊，

$ kubectl get nodes
NAME    STATUS   ROLES            AGE    VERSION
node1   Ready    etcd,master      128m   v1.12.4
node2   Ready    etcd,lb,master   126m   v1.12.4
node3   Ready    etcd,lb,worker   126m   v1.12.4

選擇出有SSD磁盤的節點，并給這個節點打上標記（label），

$ kubectl label nodes <your-node-name> disktype=ssd
node/<your-node-name> labeled

驗證節點上是否有成功打上對應label，

$ kubectl get nodes --show-labels
NAME    STATUS   ROLES            AGE    VERSION   LABELS
node1   Ready    etcd,master      139m   v1.12.4   ...disktype=ssd,kubernetes.io/hostname=node1...
node2   Ready    etcd,lb,master   137m   v1.12.4   ...kubernetes.io/hostname=node2...
node3   Ready    etcd,lb,worker   137m   v1.12.4   ...kubernetes.io/hostname=node3...

創建一個ES的pod，調度到有SSD磁盤標記的節點上，在pod的配置里，要指定nodeSelector屬性值為disktype：ssd，這意味著pod啟動后會調度到打上了disktype=ssd標簽的node上，
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: es
    spec:
      containers:
      - name: es
        image: es
      nodeSelector:
        disktype: ssd
```

驗證pod啟動后是否調度到指定節點上，

$ kubectl get pods -o wide
NAMESPACE  NAME                   READY   STATUS    RESTARTS   AGE    IP              NODE    NOMINATED NODE
default    es-5679d9cd77-sbmcx    1/1     Running   0          134m   10.244.2.3      node1   <none>

參考檔案：

Assign Pods to Nodes

節點親和性和Pod親和性對調度的影響

上小節講述的nodeSelector提供了一種非常簡單的方法，可以將pod限制為具有特定標簽的節點，而更為強大的表達約束型別則可以由Affinity和Anti-affinity來配置，即親和性與反親和性的設定，親和性和反親和性包括兩種型別：節點（反）親和性與Pod（反）親和性，

Node affinity與NodeSelector很相似，它允許你根據節點上的標簽限制你的pod可以在哪些節點上進行調度，目前有兩種型別的節點關聯，稱為required During Scheduling Ignored During Execution和 preferred During Scheduling Ignored During Execution，可以將它們分別視為“硬規則”和“軟規則”，前者指定了要將 pod調度到節點上必須滿足的規則，而后者指定調度程式將嘗試強制但不保證的首選項，名稱中的“Ignored During Execution”部分意味著，類似于nodeSelector作業方式，如果節點上的標簽在運行時更改，不再滿足pod上的關聯性規則，pod仍將繼續在該節點上運行，Pod affinity強調的是同一個節點中Pod之間的親和力，可以根據已在節點上運行的pod上的標簽來約束pod可以調度哪些節點上，比如希望運行該Pod到某個已經運行了Pod標簽為app=webserver的節點上，就可以使用Pod affinity來表達這一需求，

目前有兩種型別Pod親和力和反親和力，稱為required During Scheduling Ignored During Execution以及 preferred During Scheduling Ignored During Execution，其中表示“硬規則”與“軟規則”的要求，類似于Node affinity，IgnoredDuringExecution部分表示如果在Pod運行期間改變了Pod標簽導致親和性不滿足以上規則，則pod仍將繼續在該節點上運行，無論是Selector還是Affinity，都是基于Pod或者Node的標簽來表達約束型別，從而讓調度器按照約束規則來調度Pod運行在合理的節點上，

節點親和性如下所示，其中親和性定義為：該pod只能放置在一個含有鍵為kubernetes.io/hostname并且值為node1或者node2標簽的節點上，此外，在滿足該標準的節點中，具有其鍵為app且值為webserver的標簽的節點應該是優選的，

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node1
            - node2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: app
            operator: In
            values:
            - webserver
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

Pod反親和性如下所示，其中反親和性定義為：在此拓撲域（相當于以topologyKey的值進行的節點分組）中，命名空間為default下有標簽鍵為app，標簽值為redis的Pod時不在此Node上運行，

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - redis
        namespaces:
        - default
        topologyKey: kubernetes.io/hostname
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

不使用調度器，手動調度一個pod

Scheduling程序的本質其實就是給Pod賦予nodeName屬性合適的值，那么在開發者進行Pod部署時就直接指定這個值是否可行呢？答案是肯定的，如下配置，將nginx直接分配到node1上運行，

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: node1

還有一種指定節點的部署方式——static pod，就像它名稱一樣，他是一個“靜態”的Pod，它不通過apiserver，直接由kubelet進行托管，在kubelet的啟動引數中–pod-manifest-path=DIR，這里的DIR就是放置static pod的編排檔案的目錄，把static pod的編排檔案放到此目錄下，kubelet就可以監聽到變化，并根據編排檔案創建pod，還有一個啟動引數–manifest-url=URL，kubelet會從這個URL下載編排檔案，并創建pod，static pod有一個特性是我們使用docker或kubectl洗掉static pod后， static pod還能被kubelet行程拉起，通過這種方式保證了應用的可用性，有點相當于systemd的功能，但比systemd好的一點是， static pod的鏡像資訊會在apiserver中注冊，這樣的話，我們就可以統一對部署資訊進行可視化管理，此外static pod是容器，無需拷貝二進制檔案到主機上，應用封裝在鏡像里也保證了環境的一致性，無論是應用的編排檔案還是應用的鏡像都方便進行版本管理和分發，

在使用kubeadm部署kubernetes集群時，static pod得到了大量的應用，比如 etcd、kube-scheduler、kube-controller-manager、kube-apiserver 等都是使用 static pod的方式運行的，

使用static pod部署出來的pod名稱與其他pod有很大的不同點，名稱中沒有“亂碼”，只是簡單的將pod的name屬性值與它運行在的node的name屬性值相連接而成，如下所示，coredns是通過Deployment部署出來的名稱中就有部分“亂碼”，而etcd，kube-apiserver這種Pod就是static pod，

$ kubectl get po --all-namespaces
NAMESPACE       NAME                          READY   STATUS    RESTARTS   AGE
kube-system   coredns-5679d9cd77-d6jp6        1/1     Running   0          6m59s
kube-system   etcd-node1                      1/1     Running   0          6m58s
kube-system   etcd-node2                      1/1     Running   0          6m58s
kube-system   etcd-node3                      1/1     Running   0          6m54s
kube-system   kube-proxy-nxj5d                1/1     Running   0          6m52s
kube-system   kube-proxy-tz264                1/1     Running   0          6m56s
kube-system   kube-proxy-zxgxc                1/1     Running   0          6m57s

了解Daemonset角色

DaemonSet是一種控制器，它確保在一些或全部Node上都運行一個指定的Pod，這些Pod就相當于守護行程一樣不期望被終止，當有Node加入集群時，也會為他們新增一個Pod，當有Node從集群移除時，對應的Pod也會被回收，當洗掉DaemonSet時將會洗掉它創建的所有Pod，一般情況下，Pod運行在哪個節點上是由Kubernates調度器選擇的，但是在Kubernates 1.11版本之前由DaemonSet Controller創建的Pod在創建時已經確定了在哪個節點上運行（pod在創建的時候.spec.nodeName欄位就指定了，因此會被scheduler忽略），所以即使調度器沒有啟動DaemonSet Controller創建的Pod仍然也可以被分配node，直到Kubernates 1.11版本，DaemonSet的pod由scheduler調度才作為alpha特性引入，在上小節中kube-proxy就是以DaemonSet的方式進行運行的，

配置Kubernetes scheduler

如果需要配置一些高級的調度策略以滿足我們的需要，可以修改默認調度程式的組態檔，kube-scheduler在啟動的時候可以通過–policy-config-file引數來指定調度策略檔案，開發者可以根據自己的需要來組裝Predicates和Priority函式，選擇不同的過濾函式和優先級函式，調整控制優先級函式的權重和過濾函式的順序都會影響調度結果，

官方的Policy檔案如下：

kind: Policy
apiVersion: v1
predicates:
- {name: PodFitsHostPorts}
- {name: PodFitsResources}
- {name: NoDiskConflict}
- {name: NoVolumeZoneConflict}
- {name: MatchNodeSelector}
- {name: HostName}
priorities:
- {name: LeastRequestedPriority, weight: 1}
- {name: BalancedResourceAllocation, weight: 1}
- {name: ServiceSpreadingPriority, weight: 1}
- {name: EqualPriority, weight: 1}

其中predicates區域是調度的預選階段所需要的過濾演算法，priorities區域是優選階段的評分演算法，

總結

再來回顧一下調度的主要構成部分：首先是預選程序，過濾掉不滿足Pod要求的節點，然后是優選程序，對通過要求的節點進行優先級排序，最后選擇優先級最高的節點進行分配，當調度器不作業時或有臨時需求可以手動指定nodeName屬性的值，讓其不通過調度器進行調度直接運行在指定的節點上，

本文由豬齒魚技術團隊原創，轉載請注明出處

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/343945.html

標籤：其他

上一篇：LeetCode(力扣) 題庫第1題 Two Sum(兩數之和) java新手清晰解題程序

下一篇：Springboot第一次訪問慢，自身缺陷問題？

從0到1使用Kubernetes系列（五）：Kubernetes Scheduling