k8s预留资源与pod驱逐
节点资源的配置一般分为 2 种:
- 资源预留:为系统进程和 k8s 进程预留资源
- 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
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求