背景

Kubernetes中的排程是將待處理的pod繫結到節點的過程，由Kubernetes的一個名為kube-scheduler的元件執行。排程程式的決定，無論是否可以或不能排程容器，都由其可配置策略指導，該策略包括一組規則，稱為謂詞和優先順序。排程程式的決定受到其在第一次排程時出現新pod時的Kubernetes叢集檢視的影響。由於Kubernetes叢集非常動態且狀態隨時間而變化，因此可能需要將已經執行的pod移動到其他節點，原因如下：

• 一些節點不足或過度使用。
• 原始排程決策不再適用，因為在節點中新增或刪除了汙點或標籤，不再滿足pod / node親和性要求。
• 某些節點發生故障，其pod已移至其他節點。
• 新節點將新增到群集中。

因此，可能會在群集中不太理想的節點上安排多個pod。Descheduler根據其政策，發現可以移動並移除它們的pod。請注意，在當前的實現中，descheduler不會安排更換被驅逐的pod，而是依賴於預設的排程程式。

Descheduler二次排程

GitHub地址：https://github.com/kubernetes-sigs/descheduler

下面是重要的配置

• configmap.yaml

---

apiVersion: v1

kind: ConfigMap

metadata:

  name: descheduler-policy-configmap

  namespace: kube-system
 

data:

  policy.yaml: |

    apiVersion: "descheduler/v1alpha1"

    kind: "DeschedulerPolicy"

    strategies:

      "RemoveDuplicates":

         enabled: true

      "RemovePodsViolatingInterPodAntiAffinity":

         enabled: true

      "LowNodeUtilization":

         enabled: true

         params:

           nodeResourceUtilizationThresholds:
 

             thresholds:

               "cpu" :

               "memory":

               "pods":

             targetThresholds:

               "cpu" :

               "memory":

               "pods": 

RemoveDuplicates策略

該策略發現未充分利用的節點，並且如果可能的話，從其他節點驅逐pod，希望在這些未充分利用的節點上安排被驅逐的pod的重新建立。此策略的引數配置在nodeResourceUtilizationThresholds。

節點的利用率低是由可配置的閾值決定的thresholds。thresholds可以按百分比為cpu，記憶體和pod數量配置閾值 。如果節點的使用率低於所有（cpu，記憶體和pod數）的閾值，則該節點被視為未充分利用。目前，pods的請求資源需求被考慮用於計算節點資源利用率。

還有另一個可配置的閾值，targetThresholds用於計算可以驅逐pod的潛在節點。任何節點，所述閾值之間，thresholds並且targetThresholds被視為適當地利用，並且不考慮驅逐。閾值targetThresholds也可以按百分比配置為cpu，記憶體和pod數量。

簡單的說：thresholds是沒有達到資源使用的node視為資源使用率低可以分配，targetThresholds是已經滿足這個條件的node資源緊張要把上面的pod遷移。

• cronjob.yaml

---

apiVersion: batch/v1beta1

kind: CronJob

metadata:

  name: descheduler-cronjob

  namespace: kube-system

spec:
　　#定時任務時間可調

  schedule: "*/10 * * * *"

  concurrencyPolicy: "Forbid"

  jobTemplate:

    spec:

      template:

        metadata:

          name: descheduler-pod

        spec:

          priorityClassName: system-cluster-critical

          containers:

          - name: descheduler

            image: aveshagarwal/descheduler

            #image: us.gcr.io/k8s-artifacts-prod/descheduler:v0.10.0

            volumeMounts:

            - mountPath: /policy-dir

              name: policy-volume

            command:

              - "/bin/descheduler"

            args:

              - "--policy-config-file"

              - "/policy-dir/policy.yaml"

              - "--v"

              - ""

          restartPolicy: "Never"

          serviceAccountName: descheduler-sa

          volumes:

          - name: policy-volume

            configMap:

              name: descheduler-policy-configmap

• rbac.yaml

---

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: descheduler-cluster-role

  namespace: kube-system

rules:

- apiGroups: [""]

  resources: ["events"]

  verbs: ["create", "update"]

- apiGroups: [""]

  resources: ["nodes"]

  verbs: ["get", "watch", "list"]

- apiGroups: [""]

  resources: ["pods"]

  verbs: ["get", "watch", "list", "delete"]

- apiGroups: [""]

  resources: ["pods/eviction"]

  verbs: ["create"]

---

apiVersion: v1

kind: ServiceAccount

metadata:

  name: descheduler-sa

  namespace: kube-system

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: descheduler-cluster-role-binding

  namespace: kube-system

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: descheduler-cluster-role

subjects:

  - name: descheduler-sa

    kind: ServiceAccount

    namespace: kube-system

kubectl apply -f 執行上面三個檔案,檢視日誌如有滿足再次排程條件的會重新發起二次排程均衡node資源。