背景

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" : 30
               "memory": 40
               "pods": 50
             targetThresholds:
               "cpu" : 20
               "memory": 25
               "pods": 15

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"
              - "3"
          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資源。

 

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?