k8s预留资源与pod驱逐

节点资源的配置一般分为 2 种:

  1. 资源预留:为系统进程和 k8s 进程预留资源
  2. pod 驱逐:节点资源到达一定使用量,开始驱逐 pod

一.资源预留

  k8s需要预留是资源主要有两种:

  1.kube-reserved:给kube组件预留的资源:kubelet,kube-proxy以及docker等;

  2.system-reserved:给system进程预留的资源。

预留出这两种资源从而保证当节点出现满负荷时也能保证Kube和System进程有足够的资源。

  可以预留的资源有5种:cpu, memory,ephemeral-storage,pods,hugepages。其中ephemeral-storage主要是用于对本地临时存储使用空间大小的限制,是根目录/root下的空间,如对pod的empty dir、/var/lib/kubelet、日志、容器可读写层的使用大小的限制,生产环境不建议使用。其中常用的为cpu和memory。

  不同方法安装的k8s集群的配置文件在不同的地方进行修改,本次只针对kubeoperator安装的k8s集群与rancher安装的k8s集群。

  对于kubeoperator安装的集群,其kubelet的配置文件在/var/lib/kubelet/config.yaml。配置文件中原本有kubeReserved字段,可以修改,再添加systemReserved字段。此配置文件中的字段是用驼峰命名法的。

  

复制代码
systemReserved:
  cpu: "300m"
  memory: "500Mi"
kubeReserved:
  cpu: "300m"
  memory: "500Mi"

然后重启kubelet
systemctl restart kubelet
查看是否重启成功
systemctl status kubelet

查看资源是否预留成功

kubectl describe nodes kubernetes-dev-worker-2
可以看到
Capacity:
cpu: 40
ephemeral-storage: 307050Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 131438180Ki
pods: 110
Allocatable:
cpu: 39400m
ephemeral-storage: 288768734241
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 133487838720
pods: 110


对比Capacity与Allocatable的cpu 内存,磁盘都已经预留好了

复制代码

  对于rancher rke安装的集群,其kube的配置文件在web控制台进行修改,首先进去集群管理-选择需要修改配置的集群-点击修改配置-点击Edit as YAML。如图修改配置文件cluster.yml

 

 

   cluster.yml 文件示例中内置了一些常用的 Kubernetes 服务配置项,可以直接修改。如果内置的参数选项不包含你要修改的 Kubernetes 服务参数,我们可以在每个 Kubernetes 服务的extra_args:下面添加对应的 Kubernetes 参数选项,此处需要修改kubelet,要在kubelet下添加extra_args:,注意与kuberoperator安装的k8s集群的配置文件config.yaml不同的是:字段名不再使用驼峰命名如systemReserved而是使用短中线"-"来连接,如 kube-reserved。

复制代码
在kubelet下添加
extra_args:
        kube-reserved: 'cpu=100m,memory=200Mi,ephemeral-storage=300Mi'
        system-reserved: 'cpu=100m,memory=200Mi,ephemeral-storage=300Mi'

然后重启kubelet
systemctl restart kubelet
查看是否重启成功
systemctl status kubelet


查看资源是否预留成功


kubectl describe node  k8s-test
可以看到

Capacity:
cpu: 4
ephemeral-storage: 46110724Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 7990288Ki
pods: 110
Allocatable:
cpu: 3800m
ephemeral-storage: 42495643169
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 7478288Ki
pods: 110



对比Capacity与Allocatable的cpu 内存,磁盘都已经预留好了

 
复制代码

二.pod驱逐

  pod驱逐就是k8s的业务节点在某些资源(磁盘空间,内存)快要耗尽时 提前按照服务优先级驱逐某些pod以达到释放相关资源保证集群稳定性的目的。设pod驱逐的阈值只支持内存和磁盘两个参数。

     kubelet 默认的关于节点存储的驱逐触发条件:

   1.nodefs.available<10%(容器 volume 使用的文件系统的可用空间,包括文件系统剩余大小和 inode 数量)

   2.imagefs.available<15%(容器镜像使用的文件系统的可用空间,包括文件系统剩余大小和 inode 数量) 

  nodefs是kubelet目录所在分区,默认在/var/lib/kubelet/目录;imagefs是docker安装目录所在的分区,默认在/var/lib/docker,自定义如/data/docker目录。

  当系统满足触发条件时:如果 nodefs 文件系统满足驱逐条件,kubelet 垃圾收集死亡 Pod 和容器。如果 imagefs 文件系统满足驱逐条件,kubelet 将删除所有未使用的镜像。如果 kubelet 回收节点级资源的尝试没有使驱逐信号低于条件, 则 kubelet 开始驱逐最终用户 Pod。kubelet 驱逐 Pod 的过程中不会参考 Pod 的 QoS,只是根据 Pod 的 nodefs 使用量来进行排名,并选取使用量最多的 Pod 进行驱逐。

       

  kubelet 默认的关于节点内存资源的驱逐触发条件:

    memory.available<100Mi

  当内存使用量超过阈值时,kubelet 就会向 API Server 注册一个 MemoryPressure condition,此时 kubelet 不会接受新的 QoS 等级为 Best Effort 的              Pod 在该节点上运行,并按照以下顺序来驱逐 Pod:

       Pod 的内存使用量是否超过了 request 指定的值

  根据 priority 排序,优先级低的 Pod 最先被驱逐

  比较它们的内存使用量与 request 指定的值之差。

按照这个顺序,可以确保 QoS 等级为 Guaranteed 的 Pod 不会在 QoS 等级为 Best Effort 的 Pod 之前被驱逐,但不能保证它不会在 QoS 等级为 Burstable 的 Pod 之前被驱逐。DaemonSet中的pod始终会建到同一个node中

    所以kubelet不应该驱逐DaemonSet的pod DaemonSet的pod的Qos一定要设置为Guaranteed类别

当内存资源不足时,kubelet 在驱逐 Pod 时只会考虑 requests 和 Pod 的内存使用量,不会考虑 limits。

 

 

参考链接:

1.https://blog.csdn.net/yujia_666/article/details/108806068

2.https://www.modb.pro/db/157497

  

 

posted @   潇潇暮鱼鱼  阅读(2301)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
点击右上角即可分享
微信分享提示