Kubernetes组件_Scheduler_02_二次调度

news2024/12/25 2:08:56

文章目录

一、前言
二、二次调度/运行期间调度Descheduler
- 2.1 机器上安装helm
- 2.2 每个机器都要准备好镜像
- 2.3 使用helm部署
三、Descheduler需要注意的点(相关理论知识)
- 3.1 descheduler 调度策略
- 3.2 descheduler 有哪些不足
- - 3.2.1 基于 Request 计算节点负载并不能反映真实情况
  - 3.2.2 驱逐 Pod 导致应用不稳定
  - 3.2.3 依赖于 Kubernetes 的调度策略
- 3.3 descheduler 有哪些适用场景
三、尾声

一、前言

在这里插入图片描述
Descheduler所有资料：https://www.syjshare.com/res/V2RS2PUM

二、二次调度/运行期间调度Descheduler

2.1 机器上安装helm

在这里插入图片描述

小结精简命令：

1.helm包下载地址:

wget https://get.helm.sh/helm-v3.7.1-linux-amd64.tar.gz

2.解压 && 移动到 /usr/bin 目录下:

tar -xvf helm-v3.7.1-linux-amd64.tar.gz && cd linux-amd64/ && mv helm /usr/bin

3.执行 helm 显示如下说明安装成功：

#查看版本
helm version

2.2 每个机器都要准备好镜像

每个机器都要准备好镜像
在这里插入图片描述

这里笔者将镜像放到自己的阿里云镜像仓库，并公开权限，读者只需要下载就好了

vi /etc/hosts
47.95.181.38 registry.cn-beijing.aliyuncs.com
docker pull  registry.cn-beijing.aliyuncs.com/dadfdafsd/descheduler:v0.25.0
docker tag registry.cn-beijing.aliyuncs.com/dadfdafsd/descheduler:v0.25.0 registry.k8s.io/descheduler/descheduler:v0.25.0
docker images | grep descheduler

在这里插入图片描述

2.3 使用helm部署

descheduler-master的源代码也有，需要的那个上面提供了，镜像无法修改源代码，这里打成这个镜像的压缩包也有
在这里插入图片描述

在这里插入图片描述

helm install releaseName mychartName
helm install descheduler descheduler （第一个 descheduler 是helm对象名，第二个descheduler 是mychart名称，也就是目录名）

在这里插入图片描述

kubectl get all -A
kubectl get configmap -A
kubectl get clusterrole -A
kubectl get clusterrolebinding -A

查询kubectl get all -A，如下：

在这里插入图片描述

k8s中，查看机器硬件使用情况的两条命令

# 查看集群所有机器的硬件资源使用情况 （这个top命令必须安装metrics-server才能使用）
kubectl top nodes  
# 查看集群内指定机器的硬件资源使用情况 (一般还是使用这个，describe node命令没有限制)
kubectl describe node xxx

三、Descheduler需要注意的点(相关理论知识)

3.1 descheduler 调度策略

descheduler 调度策略：为了方便理解，可以类比apiserver的审计策略，表示哪些日志应该打印，这里表示那种情况需要被重调度。

查看官方仓库推荐的默认策略配置：

cat kubernetes/base/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" : 20
               "memory": 20
               "pods": 20
             targetThresholds:
               "cpu" : 50
               "memory": 50
               "pods": 50

默认开启了 RemoveDuplicates、RemovePodsViolatingInterPodAntiAffinity、LowNodeUtilization 策略。我们可以根据实际场景需要进行配置。

descheduler 目前提供了如下几种调度策略:

RemoveDuplicates
驱逐同一个节点上的多 Pod
LowNodeUtilization
查找低负载节点，从其他节点上驱逐 Pod
HighNodeUtilization
查找高负载节点，驱逐上面的 Pod
RemovePodsViolatingInterPodAntiAffinity
驱逐违反 Pod 反亲和性的 Pod
RemovePodsViolatingNodeAffinity
驱逐违反 Node 反亲和性的 Pod
RemovePodsViolatingNodeTaints
违反 NoSchedule 污点的 Pod
RemovePodsViolatingTopologySpreadConstraint
驱逐违反拓扑域的 Pod
RemovePodsHavingTooManyRestarts
驱逐重启次数太多的 Pod
PodLifeTime
驱逐运行时间超过指定时间的 Pod
RemoveFailedPods
驱逐失败状态的 Pod

3.2 descheduler 有哪些不足

3.2.1 基于 Request 计算节点负载并不能反映真实情况

在源码 https://github.com/kubernetes-sigs/descheduler/blob/028f205e8ccc49440bd52940eb78a737f8f5b824/pkg/descheduler/node/node.go#L253 中可以看到，descheduler 是通过合计 Node 上 Pod 的 Request 值来计算使用情况的。

这种方式可能并不太适合真实场景。如果能直接拿 metrics-server 或者 Prometheus 中的数据，会更有意义，因为很多情况下 Request、Limit 设置都不准确。有时，为了节约成本提高部署密度，Request 甚至会设置为 50m，甚至 10m。

3.2.2 驱逐 Pod 导致应用不稳定

descheduler 通过策略计算出一系列符合要求的 Pod，进行驱逐。好的方面是，descheduler 不会驱逐没有副本控制器的 Pod，不会驱逐带本地存储的 Pod 等，保障在驱逐时，不会导致应用故障。但是使用 client.PolicyV1beta1().Evictions 驱逐 Pod 时，会先删掉 Pod 再重新启动，而不是滚动更新。

在一个短暂的时间内，在集群上可能没有 Pod 就绪，或者因为故障新的 Pod 起不来，服务就会报错，有很多细节参数需要调整。