kubernetes调度重平衡工具 Descheduler测试

1.工具简介

Descheduler 的出现就是为了解决 Kubernetes 自身调度（一次性调度）不足的问题。它以定时任务方式运行，根据已实现的策略，重新去平衡 pod 在集群中的分布。

2.github项目地址：

https://github.com/kubernetes-sigs/descheduler

3.兼容性列表

下面的兼容性矩阵显示了k8s客户端包(client-go, apimachery等)的版本，用来编译去调度程序。 此时，去调度程序对特定的k8s版本没有硬依赖关系。 然而，特定的去调度程序版本仅针对三个最新的k8s小版本进行了测试。 例如，去调度程序v0.18应该与k8s v1.18、v1.17和v1.16一起工作。

从解调度器v0.18开始，解调度器的小版本与编译它的k8s客户端包的小版本相匹配。

4.工具下载

https://github.com/kubernetes-sigs/descheduler/archive/refs/tags/v0.18.0.zip

0.18版本只有job,以及cronjob，job一次性任务，实际环境中使用cronjob

镜像：直接使用19版本的dockerfile构建

https://github.com/kubernetes-sigs/descheduler/archive/refs/tags/v0.19.0.zip

unzip v0.19.0.zip
cd descheduler-0.19
就是当前路径构建镜
docker build -t xxxxxxxx/bus/descheduler:v0.19
5.部署
rbac.yam

---
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

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" : 35
               "memory": 35
               "pods": 45
             targetThresholds:
               "cpu" : 70
               "memory": 70
               "pods": 60
      "RemovePodsViolatingNodeAffinity":
         enabled: true
         params:
           nodeAffinityType:
           - requiredDuringSchedulingIgnoredDuringExecution

cronjob.yaml

为尽快看到实现效果，配置较短的间隔时间

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler-cronjob
  namespace: kube-system
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: "Forbid"
  jobTemplate:
    spec:
      template:
        metadata:
          name: descheduler-pod
        spec:
          priorityClassName: system-cluster-critical
          containers:
          - name: descheduler
            image: xxxxxxxx/bus/descheduler:v0.19 
            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

kubectl get cronjobs.batch -n kube-system

------------------------------------------------------------------------------------------------------

NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE

descheduler-cronjob */5 * * * * False 0 <none> 3m20s

6.测试调度策略

RemoveDuplicates

• 移除重复 pod，此策略确保每个副本集(RS)、副本控制器(RC)、部署(Deployment)或任务(Job)只有一个 pod 被分配到同一台 node 节点上。如果有多个则会被驱逐到其它节点以便更好的在集群内分散 pod。
  LowNodeUtilization
• 节点低度使用，cpu,内存资源，pod数量等使用率在thresholds与targetThresholds之前都节点都认为是正常使用的节点，一旦有节点使用率高于targetThresholds，则会把符合调度的pod驱逐到使用率低于thresholds的节点，如果节点配置了污点，pod没有设置污点容忍则该pod不会被驱逐。
  RemovePodsViolatingInterPodAntiAffinity
• 移除违反pod反亲和性的 pod，可能是因为反亲和是后面加上去的
  RemovePodsViolatingNodeAffinity
• 找到违反 Node Affinity 规则的 Pods 进行驱逐，可能是因为 Node 后面修改了 Label

6.1"RemoveDuplicates"

日志显示有同一个deployments的pod已经被驱逐另一个node，系统级的pod不会驱逐，如coredns,允许驱逐的参数：evictSystemCriticalPods在2.1版本后出现，（根据”特定的去调度程序版本仅针对三个最新的k8s小版本进行了测试“这一说明情况，不适用目前的集群版本）

6.2 “LowNodeUtilization”

测试：根据目前集群的情况调整descheduler-policy-configmap参数来达到测试效果

使用stress，cpu数量根据节点的cpu数量来配置

stressyaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: stresstest
  name: stresstest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stresstest
  template:
    metadata:
      labels:
        app: stresstest
    spec:
      containers:
      - image: polinux/stress
        name: stress
        command: ['sh', '-c', 'tail -f /dev/null']
        resources:
          requests:
            cpu: 2

在stress pod执行压测命令：

stress --cpu 2 --timeout 1600 #cpu数量根据节点的cpu数量来配置

LowNodeUtilization策略已生效，从使用率高的节点迁移pod到使用率低的节点，注意：使用率的评估是使用pod的 resources 中的request来评估，如果单纯是在宿主机执行压测命令，该调度不能识别出节点的使用率

6.3 RemovePodsViolatingInterPodAntiAffinity

（这一策略确保了违反荚间反亲和关系的荚被从节点中移除。 例如，如果某个节点上有podA，而podB和podC(运行在同一节点上)具有禁止它们运行在同一节点上的反相关性规则，那么podA将从该节点中移除，以便podB和podC能够运行。 当podB和podC的反关联规则已经在节点上运行时创建时，可能会发生这个问题）

待测

6.4 RemovePodsViolatingNodeAffinity

找到违反 Node Affinity 规则的 Pods 进行驱逐

测试yaml，设置节点亲和性

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: labeltest
  name: labeltest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: labeltest
  template:
    metadata:
      labels:
        app: labeltest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-type
                operator: In
                values:
                - test
      containers:
      - image: polinux/stress
        name: stress
        command: ['sh', '-c', 'tail -f /dev/null']

先给节点打上标签
kubectl label nodes k3 node-type=test

在部署完deployments后更改node标签

kubectl label nodes k3 node-type-
kubectl label nodes k2 node-type=test

一段时间后查看日志，确认已驱逐pod