k8s集群资源优化解决节点资源溢出导致的节点异常问题一、优化目的本文核心目标是解决k8s集群中因容器资源使用过高、超出节点可用资源导致节点关键组件异常、节点状态变为NotReady甚至节点直接宕机的问题。通过合理的资源配置优化构建“资源预留-阈值管控-OOM保护”的三层防护体系保障集群节点稳定运行将业务故障影响降至最低同时提升集群资源利用率避免资源浪费实现“稳定与高效”的双重目标。二、实验环境构建为简化k8s集群部署流程、降低测试环境搭建成本本次实验采用k3s轻量级k8s发行版替代标准k8s集群进行实操演示。k3s具备部署简单、资源占用低、核心功能与标准k8s一致的特点可快速搭建测试环境且本次优化方案的核心逻辑完全适配标准k8s集群优化配置可直接复用至生产环境的标准k8s集群无需额外修改核心参数。2.1 k3s安装方法国内源规避网络问题国内环境直接安装k3s易出现镜像拉取失败、网络超时等问题以下提供两种国内源安装方式可根据需求选择推荐第二种指定版本阿里云镜像加速稳定性更高适配国内网络环境。2.1.1 国内源在线一键安装默认版本执行以下命令通过 Rancher 国内镜像源一键安装k3s默认安装最新稳定版适用于无需指定版本、快速搭建测试环境的场景注意最新版本可能存在兼容性风险生产测试建议优先选择指定稳定版本curl-sfLhttps://rancher-mirror.rancher.cn/k3s/k3s-install.sh|INSTALL_K3S_MIRRORcnsh-2.1.2 国内源在线一键安装阿里云镜像指定版本若需指定k3s版本或需进一步提升镜像拉取速度可使用阿里云镜像仓库加速以下以v1.34.5k3s1版本稳定版适配多数生产场景为例执行命令版本可根据实际需求替换建议选择官方长期支持版本curl-sfLhttps://rancher-mirror.rancher.cn/k3s/k3s-install.sh|INSTALL_K3S_MIRRORcnINSTALL_K3S_VERSIONv1.34.5k3s1INSTALL_K3S_EXEC--system-default-registryregistry.cn-hangzhou.aliyuncs.comsh-说明–system-default-registry 参数指定阿里云镜像仓库可避免国外镜像拉取超时大幅提升部署效率安装完成后可通过k3s --version命令验证版本是否正确。mkdir-p~/.kubecp/etc/rancher/k3s/k3s.yaml ~/.kube/config kubectl get no三、k8s集群核心痛点分析3.1 核心问题表现在k8s集群日常运行中若集群资源配置不合理、容器资源限制未正确设置极易出现以下连锁问题严重影响集群稳定性和业务可用性资源耗尽单个节点因业务容器资源占用过高耗尽节点CPU、内存、临时存储等核心资源导致节点资源枯竭组件异常节点关键组件如kubelet、containerd因资源不足无法正常运行导致节点状态变为NotReady无法调度新的pod节点宕机极端情况下资源耗尽会导致节点直接卡死、宕机甚至无法通过远程连接进行恢复业务中断节点异常后其上运行的所有容器随之故障若业务容器未做高可用配置如多副本、反亲和性会引发大面积业务中断造成严重损失。3.2 核心解决思路针对上述痛点核心解决思路为资源限制 资源预留 OOM优先级配置三层防护协同作用从“预防-管控-兜底”三个维度保障节点稳定形成闭环管控具体说明如下说明1默认情况下k8s集群核心组件如kube-apiserver、kube-controller-manager的容器已配置集群或节点级优先级本文不再赘述重点讲解节点级资源预留、驱逐阈值及OOM优先级配置保障节点基础运行资源不被侵占。说明2通过配置kubelet、containerd或docker的OOM优先级确保节点资源不足时系统优先驱逐占用资源高的普通业务容器可驱逐至其他节点而非杀死集群关键组件若业务容器已配置多副本且开启pod反亲和性确保副本分布在不同节点则业务几乎不受影响实现故障隔离降低业务中断风险。说明3资源限制需配合业务容器配置resources.requests/limits与节点级管控形成联动从容器层面避免单个容器过度占用资源实现“节点级管控容器级限制”的双重防护。四、k8s集群资源优化配置指导标准k8s环境本章节针对标准k8s集群从kubelet节点核心管理组件、containerd容器运行时两个核心维度给出具体可落地的优化方案所有配置需根据节点实际硬件资源CPU、内存、临时存储灵活调整建议结合后续“注意事项”中的比例进行配置避免盲目套用示例参数。4.1 kubelet配置优化kubelet是节点上的核心组件负责容器的生命周期管理、资源管控是节点资源优化的核心配置对象。通过修改kubelet配置文件默认路径/var/lib/kubelet/config.yaml若路径不一致可通过systemctl cat kubelet查看实际配置路径添加资源预留、驱逐阈值、OOM优先级等配置保障节点资源稳定。在配置文件中添加以下内容注释清晰可直接复制修改需根据节点硬件调整具体数值示例参数适配4核8Gi节点# 资源预留为k8s核心组件和系统本身预留资源避免被业务容器耗尽# kubeReserved给k8s核心组件kubelet、containerd、kube-proxy等预留的资源kubeReserved:cpu:500m# 预留500毫核CPU1核1000m根据节点总CPU调整建议预留总CPU的10%-20%memory:1Gi# 预留1Gi内存根据节点总内存调整建议预留总内存的20%-30%ephemeral-storage:10Gi# 预留10Gi临时存储用于容器日志、临时文件等建议预留总临时存储的20%-30%# systemReserved给操作系统本身如系统进程、内核服务预留的资源systemReserved:cpu:200m# 预留200毫核CPU补充系统运行所需资源memory:512Mi# 预留512Mi内存保障系统基础服务稳定ephemeral-storage:10Gi# 预留10Gi临时存储避免系统临时文件耗尽存储# 强制节点可分配资源管控仅允许pod使用“节点总资源 - 预留资源”的剩余部分防止资源超配enforceNodeAllocatable:-pods# 硬驱逐阈值当节点资源低于该阈值时强制驱逐pod不可恢复优先保障节点存活# 数值需结合节点总资源调整避免设置过低导致频繁驱逐过高无法起到保护作用evictionHard:memory.available:1Gi# 节点可用内存低于1Gi时强制驱逐podnodefs.available:10%# 节点根目录可用空间低于10%时强制驱逐podimagefs.available:15%# 容器镜像存储目录可用空间低于15%时强制驱逐pod# 软驱逐阈值可选配置当节点资源低于该阈值时等待指定时间后再驱逐pod给业务留缓冲时间evictionSoft:memory.available:1.5Gi# 节点可用内存低于1.5Gi时触发软驱逐evictionSoftGracePeriod:memory.available:1m30s# 软驱逐缓冲时间1分30秒后执行驱逐可根据业务容忍度调整建议1-5分钟# OOM优先级配置设置kubelet进程OOM分数为-999最低确保资源不足时kubelet不被系统杀死OOMScoreAdjust:-999配置完成后执行以下命令重启kubelet生效重启前建议确认业务低峰期避免影响运行中的业务systemctl daemon-reload systemctl restart kubelet验证重启后执行systemctl status kubelet确认kubelet服务正常运行无报错同时执行kubectl get nodes确认节点状态为Ready说明配置生效若出现报错可通过journalctl -u kubelet查看日志排查配置错误。4.2 containerd.service配置优化containerd是k8s默认的容器运行时负责容器的创建、运行和销毁其稳定性直接影响容器运行需配置其OOM优先级确保其不被系统优先杀死保障容器运行时稳定与kubelet形成协同防护。配置文件路径通常为 /usr/lib/systemd/system/containerd.service 或 /etc/systemd/system/containerd.service具体以节点实际路径为准可通过find / -name containerd.service命令快速查找。配置内容编辑配置文件在[Service]段添加以下一行设置containerd的OOM优先级与kubelet一致均设为-999确保核心组件不被系统杀死OOMScoreAdjust-999配置完成后执行以下命令重启containerd生效systemctl daemon-reload systemctl restart containerd验证重启后执行systemctl status containerd确认服务正常运行无报错若使用docker作为容器运行时配置逻辑一致修改docker.service文件添加相同的OOM优先级配置即可。五、k3s集群资源优化演示实操验证本次实验环境为k3s集群k3s与标准k8s存在一个核心区别k3s将kubelet、apiserver、controller-manager等核心组件打包整合统一以k3s-server进程运行因此无需分别配置各个组件仅需修改k3s的系统服务配置文件/etc/systemd/system/k3s.service即可实现所有资源优化配置简化操作流程适配测试环境快速验证需求。5.1 k3s资源优化配置步骤5.1.1 修改k3s.service配置文件编辑 /etc/systemd/system/k3s.service 文件若文件不存在可通过systemctl cat k3s查看实际路径在[Service]段添加OOM优先级配置并在ExecStart命令中添加kubelet相关参数对应标准k8s的kubelet配置核心添加内容如下可直接复制到对应位置参数适配2Gi内存虚拟机实际需根据节点硬件调整# OOM优先级配置确保k3s-server进程包含所有核心组件不被系统杀死 OOMScoreAdjust-999 # kubelet参数配置对应标准k8s的资源预留、驱逐阈值等与4.1章节逻辑一致 --kubelet-argkube-reservedcpu500m,memory1Gi,ephemeral-storage10Gi --kubelet-argsystem-reservedcpu200m,memory512Mi,ephemeral-storage10Gi --kubelet-argenforce-node-allocatablepods --kubelet-argeviction-hardmemory.available300Mi,nodefs.available10%,imagefs.available15%,nodefs.inodesFree5%说明eviction-hard 中 memory.available300Mi 是结合本次演示节点2Gi内存虚拟机调整的实际需根据节点总内存灵活修改。5.1.2 修改后的完整配置示例以下为修改后的k3s.service完整配置资源预留大小已适配2Gi内存虚拟机实际部署时需根据节点硬件调整若节点内存为4Gi可将memory预留调整为1Gi-1.2Gi[Unit] DescriptionLightweight Kubernetes Documentationhttps://k3s.io Wantsnetwork-online.target Afternetwork-online.target [Install] WantedBymulti-user.target [Service] Typenotify EnvironmentFile-/etc/default/%N EnvironmentFile-/etc/sysconfig/%N EnvironmentFile-/etc/systemd/system/k3s.service.env KillModeprocess Delegateyes Userroot # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE1048576 LimitNPROCinfinity LimitCOREinfinity TasksMaxinfinity TimeoutStartSec0 # 新增OOM优先级配置保障k3s核心进程不被OOM杀死 OOMScoreAdjust-999 Restartalways RestartSec5s ExecStartPre-/sbin/modprobe br_netfilter ExecStartPre-/sbin/modprobe overlay # 新增kubelet参数配置实现资源预留、驱逐阈值管控临时存储预留同步改为10Gi ExecStart/usr/local/bin/k3s \ server \ --system-default-registryregistry.cn-hangzhou.aliyuncs.com \ --kubelet-argkube-reservedcpu500m,memory512Mi,ephemeral-storage10Gi \ --kubelet-argsystem-reservedcpu200m,memory512Mi,ephemeral-storage10Gi \ --kubelet-argenforce-node-allocatablepods \ --kubelet-argeviction-hardmemory.available300Mi,nodefs.available10%,imagefs.available15%,nodefs.inodesFree5%5.1.3 重启k3s生效配置配置修改完成后执行以下命令重载系统服务配置并重启k3s使优化配置生效重启过程中集群核心组件会暂时重启建议在业务低峰期操作避免影响业务运行systemctl daemon-reload systemctl restart k3s验证重启后执行systemctl status k3s确认k3s-server服务正常运行无报错再执行kubectl get nodes确认节点状态为Ready核心组件coredns、metrics-server等运行正常说明配置已生效若重启失败可通过journalctl -u k3s查看日志排查配置错误常见错误为参数拼写错误、格式错误。5.2 实操验证新建容器资源溢出场景测试本次演示使用2Gi内存的虚拟机部署k3s模拟生产中“新建高资源占用容器导致节点资源溢出”的场景若不配置资源限制运行大内存容器会直接导致虚拟机k3s节点资源耗尽、卡死无法执行任何命令配置资源优化后节点会拒绝创建超出资源限制的容器或驱逐已占用过高资源的容器保障节点和k3s集群正常运行验证优化配置的有效性。5.2.1 节点初始资源状态查看节点当前内存、临时存储使用情况确认初始资源充足为后续测试做对比测试前需确保节点无其他高资源占用进程[rootVM-12-10-centos ~]# free -htotal usedfreeshared buff/cache available Mem:2.0G1.0G 97M1.4M 839M 779M Swap: 0B 0B 0B# 查看临时存储使用情况默认对应/var/lib/containerd目录容器临时文件、日志均存储于此[rootVM-12-10-centos ~]# df -h /var/lib/containerdFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 12G 28G30% /5.2.2 集群初始状态查看k3s集群pod运行状态确认核心组件正常运行无异常pod若有异常pod需先排查解决避免影响测试结果[rootVM-12-10-centos n9e]# kubectl get po -ANAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-76f4bf7558-zw5vw1/1 Running04m47s kube-system local-path-provisioner-75f7bc6c87-7rsn91/1 Running04m47s kube-system metrics-server-56b58dfd89-5q5w51/1 Running04m47s kube-system svclb-traefik-599c1f00-8mz4n2/2 Running04m46s kube-system traefik-5868cb565d-r7q9k1/1 Running04m47s5.2.3 创建高资源占用pod验证优化效果部署多个高内存、高临时存储占用的业务pod如mysql、nightingale、redis可自行选择大内存镜像模拟资源溢出场景执行部署命令提前准备好对应yaml配置文件确保pod资源请求/限制超出节点可分配资源示例中mysql请求内存1Gi超出节点可分配内存[rootVM-12-10-centos n9e]# kubectl apply -f .configmap/mysql-config created statefulset.apps/mysql created service/mysql-headless created service/mysql created configmap/nightingale-config created deployment.apps/nightingale created service/nightingale created service/nightingale-nodeport created statefulset.apps/redis created service/redis-headless created service/redis created补充说明yaml配置文件中需为pod配置resources.requests和resources.limits示例如下mysql的资源配置可根据测试需求调整resources:requests:cpu:500mmemory:1Giephemeral-storage:5Gilimits:cpu:1000mmemory:2Giephemeral-storage:8Gi5.2.4 验证结果分析部署完成后通过以下命令查看节点、pod状态验证优化配置的有效性重点关注节点状态、pod状态、驱逐原因及临时存储使用情况节点状态验证查看节点状态确认节点仍处于Ready状态未出现NotReady或宕机情况可正常执行所有系统命令如free、df、kubectl等说明资源预留和OOM保护生效节点核心资源未被耗尽[rootVM-12-10-centos manifests]# kubectl get noNAME STATUS ROLES AGE VERSION vm-12-10-centos Ready control-plane 14d v1.34.5k3s1pod状态验证查看pod运行状态可见高资源占用的pod出现Pending无法调度因节点资源不足或Evicted被驱逐因超出资源阈值状态未导致节点卡死说明驱逐阈值配置生效节点主动管控资源占用[rootVM-12-10-centos]# kubectl get po -ANAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-76f4bf7558-pgkdw1/1 Running09m50s kube-system local-path-provisioner-75f7bc6c87-l2v851/1 Running09m50s kube-system metrics-server-56b58dfd89-pkctd1/1 Running09m50s kube-system svclb-traefik-599c1f00-2v9x22/2 Running09m49s kube-system traefik-5868cb565d-kh6jv1/1 Running09m50s nightingale mysql-00/1 Pending086s nightingale nightingale-6bc8bcf766-945c70/1 Pending091s nightingale nightingale-6bc8bcf766-jz6hq0/1 ContainerStatusUnknown1(99s ago)6m47s nightingale nightingale-6bc8bcf766-r2cxm0/1 Evicted06m48s nightingale nightingale-6bc8bcf766-tn6xz0/1 Evicted092s nightingale redis-00/1 Pending089s驱逐原因验证查看被驱逐pod的详情确认驱逐原因是节点内存压力MemoryPressure与我们配置的驱逐阈值一致验证驱逐机制有效节点可主动清理高资源占用pod[rootVM-12-10-centos]# kubectl -n nightingale describe po nightingale-6bc8bcf766-r2cxmName: nightingale-6bc8bcf766-r2cxm Namespace: nightingale Priority:0Service Account: default Node: vm-12-10-centos/ Start Time: Thu,26Mar202611:28:58 0800 Labels:appnightingale pod-template-hash6bc8bcf766 Annotations:noneStatus: Failed Reason: Evicted Message: Pod was rejected: Thenodehad condition:[MemoryPressure]临时存储验证查看临时存储使用情况确认使用占比未超出预留阈值本次演示中临时存储使用率38%低于预留阈值节点未出现存储压力说明临时存储预留配置生效[rootVM-12-10-centos]# df -h /var/lib/containerdFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 15G 25G38% /5.3 实操验证已运行容器突然资源高场景为进一步验证OOM优先级和驱逐机制的有效性部署一个未配置内存限制的pod模拟生产中“已运行业务容器突然出现资源飙升”的场景观察节点是否会优先杀死该pod或者pod里资源高的进程而非核心组件验证兜底防护效果。# 部署未配置内存限制的测试pod不设置resources.limits模拟业务容器未配置资源限制的场景[rootVM-12-10-centos ~]# kubectl run test --imageswr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/library/busybox:1.28 -- sleep 99dpod/test created# 确认pod正常运行[rootVM-12-10-centos ~]# kubectl get poNAME READY STATUS RESTARTS AGEtest1/1 Running03s# 进入pod内部执行命令让容器内存飙升模拟业务异常如程序内存泄漏[rootVM-12-10-centos ~]# kubectl exec -it test -- sh/# dd if/dev/zero of/dev/null bs1024G count100Killed /#结果分析执行内存飙升命令后容器被系统快速杀死Killed而k3s节点仍处于Ready状态核心组件coredns、metrics-server等正常运行未出现节点卡死或宕机情况。这说明OOM优先级配置生效系统优先杀死资源占用过高的普通业务pod而非k3s核心进程保障了节点核心组件的安全与预期优化效果一致同时验证了“兜底防护”的有效性即使业务容器未配置资源限制节点也能通过OOM优先级保护自身安全。六、优化效果总结通过本次资源优化配置资源预留、驱逐阈值、OOM优先级构建了“预防-管控-兜底”的三层防护体系彻底解决节点资源溢出导致的异常问题同时实现资源利用率与集群稳定性的平衡核心优化效果如下节点稳定性显著提升即使部署超出节点资源限制的容器或已运行容器突然出现资源飙升节点也不会出现卡死、宕机或NotReady状态k3s/k8s集群核心组件始终正常运行可正常执行所有系统和集群命令彻底解决节点资源溢出导致的异常问题。资源管控精准有效通过资源预留CPU、内存、临时存储各维度保障了k8s核心组件和操作系统的基础运行资源避免被业务容器耗尽通过驱逐机制主动清理高资源占用的普通容器将资源占用控制在合理范围本次演示节点内存使用率控制在85%以内临时存储使用率控制在40%以内避免资源超配和浪费。业务影响最小化高资源占用的pod被驱逐或无法调度仅影响该业务本身不会影响集群核心组件和其他正常运行的业务若业务pod配置多副本pod反亲和性可实现业务无感知切换彻底避免大面积业务故障降低业务损失提升业务可用性。资源利用率优化合理的资源预留配置避免了资源过度预留导致的浪费同时通过驱逐机制确保节点资源被高效利用提升集群整体资源利用率实现“资源不浪费、业务不中断”的目标。配置可复用性强本次优化方案的核心逻辑同时适配标准k8s和k3s集群配置参数可根据节点硬件灵活调整无需额外修改核心逻辑可直接复用至生产环境降低部署和维护成本。七、注意事项资源预留值需根据节点实际硬件配置调整避免预留过多导致资源浪费或预留不足无法保障核心组件运行建议CPU预留节点总CPU的10%-20%内存预留节点总内存的20%-30%临时存储预留节点总临时存储的20%-30%本次统一预留10Gi需结合节点实际存储大小调整若节点临时存储为30Gi预留10Gi合理若为50Gi可适当提升至15Gi。驱逐阈值需结合节点资源大小合理设置硬驱逐阈值不宜设置过低避免频繁驱逐pod影响业务稳定性软驱逐阈值可根据业务需求选择是否配置给业务留足缓冲时间建议软驱逐内存阈值比硬驱逐高0.5-1Gi缓冲时间设置1-5分钟适配不同业务的容忍度。标准k8s集群需分别配置kubelet和containerd两者的OOM优先级需保持一致均设为-999避免出现核心组件优先级不一致导致的异常k3s集群仅需配置k3s.service即可配置时需注意文件路径的正确性避免配置错误导致集群无法启动修改前建议备份原配置文件如cp /etc/systemd/system/k3s.service /etc/systemd/system/k3s.service.bak。配置修改后需执行systemctl daemon-reload重载系统服务配置再重启对应组件kubelet、containerd、k3s确保配置生效重启后建议检查组件状态和pod运行状态确认无异常后再恢复业务运行建议在业务低峰期操作避免影响运行中的业务。业务容器建议配置资源请求resources.requests和资源限制resources.limits进一步配合节点资源管控避免单个容器占用过多资源资源请求建议设置为容器正常运行所需的最小资源资源限制设置为容器可占用的最大资源两者配合实现精细化资源管控降低资源溢出风险。临时存储预留需结合容器日志、临时文件的生成量调整若业务容器会产生大量日志或临时文件如日志采集、数据处理类容器需适当提高临时存储预留值同时建议配置日志轮转策略避免因临时存储耗尽导致节点异常。生产环境中建议对节点资源使用情况进行持续监控如通过PrometheusGrafana实时关注资源使用率、驱逐事件等设置资源告警阈值如内存使用率超过80%告警及时调整资源配置避免出现资源溢出风险同时定期检查配置有效性根据业务变化调整参数。若集群节点数量较多建议通过Ansible、Kustomize等工具批量配置避免手动配置导致的遗漏和错误提升配置效率和一致性配置完成后建议在测试环境验证无误后再推广至生产环境。
k8s集群资源优化（解决节点资源溢出导致的异常问题）
发布时间：2026/5/19 14:11:17
k8s集群资源优化解决节点资源溢出导致的节点异常问题一、优化目的本文核心目标是解决k8s集群中因容器资源使用过高、超出节点可用资源导致节点关键组件异常、节点状态变为NotReady甚至节点直接宕机的问题。通过合理的资源配置优化构建“资源预留-阈值管控-OOM保护”的三层防护体系保障集群节点稳定运行将业务故障影响降至最低同时提升集群资源利用率避免资源浪费实现“稳定与高效”的双重目标。二、实验环境构建为简化k8s集群部署流程、降低测试环境搭建成本本次实验采用k3s轻量级k8s发行版替代标准k8s集群进行实操演示。k3s具备部署简单、资源占用低、核心功能与标准k8s一致的特点可快速搭建测试环境且本次优化方案的核心逻辑完全适配标准k8s集群优化配置可直接复用至生产环境的标准k8s集群无需额外修改核心参数。2.1 k3s安装方法国内源规避网络问题国内环境直接安装k3s易出现镜像拉取失败、网络超时等问题以下提供两种国内源安装方式可根据需求选择推荐第二种指定版本阿里云镜像加速稳定性更高适配国内网络环境。2.1.1 国内源在线一键安装默认版本执行以下命令通过 Rancher 国内镜像源一键安装k3s默认安装最新稳定版适用于无需指定版本、快速搭建测试环境的场景注意最新版本可能存在兼容性风险生产测试建议优先选择指定稳定版本curl-sfLhttps://rancher-mirror.rancher.cn/k3s/k3s-install.sh|INSTALL_K3S_MIRRORcnsh-2.1.2 国内源在线一键安装阿里云镜像指定版本若需指定k3s版本或需进一步提升镜像拉取速度可使用阿里云镜像仓库加速以下以v1.34.5k3s1版本稳定版适配多数生产场景为例执行命令版本可根据实际需求替换建议选择官方长期支持版本curl-sfLhttps://rancher-mirror.rancher.cn/k3s/k3s-install.sh|INSTALL_K3S_MIRRORcnINSTALL_K3S_VERSIONv1.34.5k3s1INSTALL_K3S_EXEC--system-default-registryregistry.cn-hangzhou.aliyuncs.comsh-说明–system-default-registry 参数指定阿里云镜像仓库可避免国外镜像拉取超时大幅提升部署效率安装完成后可通过k3s --version命令验证版本是否正确。mkdir-p~/.kubecp/etc/rancher/k3s/k3s.yaml ~/.kube/config kubectl get no三、k8s集群核心痛点分析3.1 核心问题表现在k8s集群日常运行中若集群资源配置不合理、容器资源限制未正确设置极易出现以下连锁问题严重影响集群稳定性和业务可用性资源耗尽单个节点因业务容器资源占用过高耗尽节点CPU、内存、临时存储等核心资源导致节点资源枯竭组件异常节点关键组件如kubelet、containerd因资源不足无法正常运行导致节点状态变为NotReady无法调度新的pod节点宕机极端情况下资源耗尽会导致节点直接卡死、宕机甚至无法通过远程连接进行恢复业务中断节点异常后其上运行的所有容器随之故障若业务容器未做高可用配置如多副本、反亲和性会引发大面积业务中断造成严重损失。3.2 核心解决思路针对上述痛点核心解决思路为资源限制 资源预留 OOM优先级配置三层防护协同作用从“预防-管控-兜底”三个维度保障节点稳定形成闭环管控具体说明如下说明1默认情况下k8s集群核心组件如kube-apiserver、kube-controller-manager的容器已配置集群或节点级优先级本文不再赘述重点讲解节点级资源预留、驱逐阈值及OOM优先级配置保障节点基础运行资源不被侵占。说明2通过配置kubelet、containerd或docker的OOM优先级确保节点资源不足时系统优先驱逐占用资源高的普通业务容器可驱逐至其他节点而非杀死集群关键组件若业务容器已配置多副本且开启pod反亲和性确保副本分布在不同节点则业务几乎不受影响实现故障隔离降低业务中断风险。说明3资源限制需配合业务容器配置resources.requests/limits与节点级管控形成联动从容器层面避免单个容器过度占用资源实现“节点级管控容器级限制”的双重防护。四、k8s集群资源优化配置指导标准k8s环境本章节针对标准k8s集群从kubelet节点核心管理组件、containerd容器运行时两个核心维度给出具体可落地的优化方案所有配置需根据节点实际硬件资源CPU、内存、临时存储灵活调整建议结合后续“注意事项”中的比例进行配置避免盲目套用示例参数。4.1 kubelet配置优化kubelet是节点上的核心组件负责容器的生命周期管理、资源管控是节点资源优化的核心配置对象。通过修改kubelet配置文件默认路径/var/lib/kubelet/config.yaml若路径不一致可通过systemctl cat kubelet查看实际配置路径添加资源预留、驱逐阈值、OOM优先级等配置保障节点资源稳定。在配置文件中添加以下内容注释清晰可直接复制修改需根据节点硬件调整具体数值示例参数适配4核8Gi节点# 资源预留为k8s核心组件和系统本身预留资源避免被业务容器耗尽# kubeReserved给k8s核心组件kubelet、containerd、kube-proxy等预留的资源kubeReserved:cpu:500m# 预留500毫核CPU1核1000m根据节点总CPU调整建议预留总CPU的10%-20%memory:1Gi# 预留1Gi内存根据节点总内存调整建议预留总内存的20%-30%ephemeral-storage:10Gi# 预留10Gi临时存储用于容器日志、临时文件等建议预留总临时存储的20%-30%# systemReserved给操作系统本身如系统进程、内核服务预留的资源systemReserved:cpu:200m# 预留200毫核CPU补充系统运行所需资源memory:512Mi# 预留512Mi内存保障系统基础服务稳定ephemeral-storage:10Gi# 预留10Gi临时存储避免系统临时文件耗尽存储# 强制节点可分配资源管控仅允许pod使用“节点总资源 - 预留资源”的剩余部分防止资源超配enforceNodeAllocatable:-pods# 硬驱逐阈值当节点资源低于该阈值时强制驱逐pod不可恢复优先保障节点存活# 数值需结合节点总资源调整避免设置过低导致频繁驱逐过高无法起到保护作用evictionHard:memory.available:1Gi# 节点可用内存低于1Gi时强制驱逐podnodefs.available:10%# 节点根目录可用空间低于10%时强制驱逐podimagefs.available:15%# 容器镜像存储目录可用空间低于15%时强制驱逐pod# 软驱逐阈值可选配置当节点资源低于该阈值时等待指定时间后再驱逐pod给业务留缓冲时间evictionSoft:memory.available:1.5Gi# 节点可用内存低于1.5Gi时触发软驱逐evictionSoftGracePeriod:memory.available:1m30s# 软驱逐缓冲时间1分30秒后执行驱逐可根据业务容忍度调整建议1-5分钟# OOM优先级配置设置kubelet进程OOM分数为-999最低确保资源不足时kubelet不被系统杀死OOMScoreAdjust:-999配置完成后执行以下命令重启kubelet生效重启前建议确认业务低峰期避免影响运行中的业务systemctl daemon-reload systemctl restart kubelet验证重启后执行systemctl status kubelet确认kubelet服务正常运行无报错同时执行kubectl get nodes确认节点状态为Ready说明配置生效若出现报错可通过journalctl -u kubelet查看日志排查配置错误。4.2 containerd.service配置优化containerd是k8s默认的容器运行时负责容器的创建、运行和销毁其稳定性直接影响容器运行需配置其OOM优先级确保其不被系统优先杀死保障容器运行时稳定与kubelet形成协同防护。配置文件路径通常为 /usr/lib/systemd/system/containerd.service 或 /etc/systemd/system/containerd.service具体以节点实际路径为准可通过find / -name containerd.service命令快速查找。配置内容编辑配置文件在[Service]段添加以下一行设置containerd的OOM优先级与kubelet一致均设为-999确保核心组件不被系统杀死OOMScoreAdjust-999配置完成后执行以下命令重启containerd生效systemctl daemon-reload systemctl restart containerd验证重启后执行systemctl status containerd确认服务正常运行无报错若使用docker作为容器运行时配置逻辑一致修改docker.service文件添加相同的OOM优先级配置即可。五、k3s集群资源优化演示实操验证本次实验环境为k3s集群k3s与标准k8s存在一个核心区别k3s将kubelet、apiserver、controller-manager等核心组件打包整合统一以k3s-server进程运行因此无需分别配置各个组件仅需修改k3s的系统服务配置文件/etc/systemd/system/k3s.service即可实现所有资源优化配置简化操作流程适配测试环境快速验证需求。5.1 k3s资源优化配置步骤5.1.1 修改k3s.service配置文件编辑 /etc/systemd/system/k3s.service 文件若文件不存在可通过systemctl cat k3s查看实际路径在[Service]段添加OOM优先级配置并在ExecStart命令中添加kubelet相关参数对应标准k8s的kubelet配置核心添加内容如下可直接复制到对应位置参数适配2Gi内存虚拟机实际需根据节点硬件调整# OOM优先级配置确保k3s-server进程包含所有核心组件不被系统杀死 OOMScoreAdjust-999 # kubelet参数配置对应标准k8s的资源预留、驱逐阈值等与4.1章节逻辑一致 --kubelet-argkube-reservedcpu500m,memory1Gi,ephemeral-storage10Gi --kubelet-argsystem-reservedcpu200m,memory512Mi,ephemeral-storage10Gi --kubelet-argenforce-node-allocatablepods --kubelet-argeviction-hardmemory.available300Mi,nodefs.available10%,imagefs.available15%,nodefs.inodesFree5%说明eviction-hard 中 memory.available300Mi 是结合本次演示节点2Gi内存虚拟机调整的实际需根据节点总内存灵活修改。5.1.2 修改后的完整配置示例以下为修改后的k3s.service完整配置资源预留大小已适配2Gi内存虚拟机实际部署时需根据节点硬件调整若节点内存为4Gi可将memory预留调整为1Gi-1.2Gi[Unit] DescriptionLightweight Kubernetes Documentationhttps://k3s.io Wantsnetwork-online.target Afternetwork-online.target [Install] WantedBymulti-user.target [Service] Typenotify EnvironmentFile-/etc/default/%N EnvironmentFile-/etc/sysconfig/%N EnvironmentFile-/etc/systemd/system/k3s.service.env KillModeprocess Delegateyes Userroot # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE1048576 LimitNPROCinfinity LimitCOREinfinity TasksMaxinfinity TimeoutStartSec0 # 新增OOM优先级配置保障k3s核心进程不被OOM杀死 OOMScoreAdjust-999 Restartalways RestartSec5s ExecStartPre-/sbin/modprobe br_netfilter ExecStartPre-/sbin/modprobe overlay # 新增kubelet参数配置实现资源预留、驱逐阈值管控临时存储预留同步改为10Gi ExecStart/usr/local/bin/k3s \ server \ --system-default-registryregistry.cn-hangzhou.aliyuncs.com \ --kubelet-argkube-reservedcpu500m,memory512Mi,ephemeral-storage10Gi \ --kubelet-argsystem-reservedcpu200m,memory512Mi,ephemeral-storage10Gi \ --kubelet-argenforce-node-allocatablepods \ --kubelet-argeviction-hardmemory.available300Mi,nodefs.available10%,imagefs.available15%,nodefs.inodesFree5%5.1.3 重启k3s生效配置配置修改完成后执行以下命令重载系统服务配置并重启k3s使优化配置生效重启过程中集群核心组件会暂时重启建议在业务低峰期操作避免影响业务运行systemctl daemon-reload systemctl restart k3s验证重启后执行systemctl status k3s确认k3s-server服务正常运行无报错再执行kubectl get nodes确认节点状态为Ready核心组件coredns、metrics-server等运行正常说明配置已生效若重启失败可通过journalctl -u k3s查看日志排查配置错误常见错误为参数拼写错误、格式错误。5.2 实操验证新建容器资源溢出场景测试本次演示使用2Gi内存的虚拟机部署k3s模拟生产中“新建高资源占用容器导致节点资源溢出”的场景若不配置资源限制运行大内存容器会直接导致虚拟机k3s节点资源耗尽、卡死无法执行任何命令配置资源优化后节点会拒绝创建超出资源限制的容器或驱逐已占用过高资源的容器保障节点和k3s集群正常运行验证优化配置的有效性。5.2.1 节点初始资源状态查看节点当前内存、临时存储使用情况确认初始资源充足为后续测试做对比测试前需确保节点无其他高资源占用进程[rootVM-12-10-centos ~]# free -htotal usedfreeshared buff/cache available Mem:2.0G1.0G 97M1.4M 839M 779M Swap: 0B 0B 0B# 查看临时存储使用情况默认对应/var/lib/containerd目录容器临时文件、日志均存储于此[rootVM-12-10-centos ~]# df -h /var/lib/containerdFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 12G 28G30% /5.2.2 集群初始状态查看k3s集群pod运行状态确认核心组件正常运行无异常pod若有异常pod需先排查解决避免影响测试结果[rootVM-12-10-centos n9e]# kubectl get po -ANAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-76f4bf7558-zw5vw1/1 Running04m47s kube-system local-path-provisioner-75f7bc6c87-7rsn91/1 Running04m47s kube-system metrics-server-56b58dfd89-5q5w51/1 Running04m47s kube-system svclb-traefik-599c1f00-8mz4n2/2 Running04m46s kube-system traefik-5868cb565d-r7q9k1/1 Running04m47s5.2.3 创建高资源占用pod验证优化效果部署多个高内存、高临时存储占用的业务pod如mysql、nightingale、redis可自行选择大内存镜像模拟资源溢出场景执行部署命令提前准备好对应yaml配置文件确保pod资源请求/限制超出节点可分配资源示例中mysql请求内存1Gi超出节点可分配内存[rootVM-12-10-centos n9e]# kubectl apply -f .configmap/mysql-config created statefulset.apps/mysql created service/mysql-headless created service/mysql created configmap/nightingale-config created deployment.apps/nightingale created service/nightingale created service/nightingale-nodeport created statefulset.apps/redis created service/redis-headless created service/redis created补充说明yaml配置文件中需为pod配置resources.requests和resources.limits示例如下mysql的资源配置可根据测试需求调整resources:requests:cpu:500mmemory:1Giephemeral-storage:5Gilimits:cpu:1000mmemory:2Giephemeral-storage:8Gi5.2.4 验证结果分析部署完成后通过以下命令查看节点、pod状态验证优化配置的有效性重点关注节点状态、pod状态、驱逐原因及临时存储使用情况节点状态验证查看节点状态确认节点仍处于Ready状态未出现NotReady或宕机情况可正常执行所有系统命令如free、df、kubectl等说明资源预留和OOM保护生效节点核心资源未被耗尽[rootVM-12-10-centos manifests]# kubectl get noNAME STATUS ROLES AGE VERSION vm-12-10-centos Ready control-plane 14d v1.34.5k3s1pod状态验证查看pod运行状态可见高资源占用的pod出现Pending无法调度因节点资源不足或Evicted被驱逐因超出资源阈值状态未导致节点卡死说明驱逐阈值配置生效节点主动管控资源占用[rootVM-12-10-centos]# kubectl get po -ANAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-76f4bf7558-pgkdw1/1 Running09m50s kube-system local-path-provisioner-75f7bc6c87-l2v851/1 Running09m50s kube-system metrics-server-56b58dfd89-pkctd1/1 Running09m50s kube-system svclb-traefik-599c1f00-2v9x22/2 Running09m49s kube-system traefik-5868cb565d-kh6jv1/1 Running09m50s nightingale mysql-00/1 Pending086s nightingale nightingale-6bc8bcf766-945c70/1 Pending091s nightingale nightingale-6bc8bcf766-jz6hq0/1 ContainerStatusUnknown1(99s ago)6m47s nightingale nightingale-6bc8bcf766-r2cxm0/1 Evicted06m48s nightingale nightingale-6bc8bcf766-tn6xz0/1 Evicted092s nightingale redis-00/1 Pending089s驱逐原因验证查看被驱逐pod的详情确认驱逐原因是节点内存压力MemoryPressure与我们配置的驱逐阈值一致验证驱逐机制有效节点可主动清理高资源占用pod[rootVM-12-10-centos]# kubectl -n nightingale describe po nightingale-6bc8bcf766-r2cxmName: nightingale-6bc8bcf766-r2cxm Namespace: nightingale Priority:0Service Account: default Node: vm-12-10-centos/ Start Time: Thu,26Mar202611:28:58 0800 Labels:appnightingale pod-template-hash6bc8bcf766 Annotations:noneStatus: Failed Reason: Evicted Message: Pod was rejected: Thenodehad condition:[MemoryPressure]临时存储验证查看临时存储使用情况确认使用占比未超出预留阈值本次演示中临时存储使用率38%低于预留阈值节点未出现存储压力说明临时存储预留配置生效[rootVM-12-10-centos]# df -h /var/lib/containerdFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 15G 25G38% /5.3 实操验证已运行容器突然资源高场景为进一步验证OOM优先级和驱逐机制的有效性部署一个未配置内存限制的pod模拟生产中“已运行业务容器突然出现资源飙升”的场景观察节点是否会优先杀死该pod或者pod里资源高的进程而非核心组件验证兜底防护效果。# 部署未配置内存限制的测试pod不设置resources.limits模拟业务容器未配置资源限制的场景[rootVM-12-10-centos ~]# kubectl run test --imageswr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/library/busybox:1.28 -- sleep 99dpod/test created# 确认pod正常运行[rootVM-12-10-centos ~]# kubectl get poNAME READY STATUS RESTARTS AGEtest1/1 Running03s# 进入pod内部执行命令让容器内存飙升模拟业务异常如程序内存泄漏[rootVM-12-10-centos ~]# kubectl exec -it test -- sh/# dd if/dev/zero of/dev/null bs1024G count100Killed /#结果分析执行内存飙升命令后容器被系统快速杀死Killed而k3s节点仍处于Ready状态核心组件coredns、metrics-server等正常运行未出现节点卡死或宕机情况。这说明OOM优先级配置生效系统优先杀死资源占用过高的普通业务pod而非k3s核心进程保障了节点核心组件的安全与预期优化效果一致同时验证了“兜底防护”的有效性即使业务容器未配置资源限制节点也能通过OOM优先级保护自身安全。六、优化效果总结通过本次资源优化配置资源预留、驱逐阈值、OOM优先级构建了“预防-管控-兜底”的三层防护体系彻底解决节点资源溢出导致的异常问题同时实现资源利用率与集群稳定性的平衡核心优化效果如下节点稳定性显著提升即使部署超出节点资源限制的容器或已运行容器突然出现资源飙升节点也不会出现卡死、宕机或NotReady状态k3s/k8s集群核心组件始终正常运行可正常执行所有系统和集群命令彻底解决节点资源溢出导致的异常问题。资源管控精准有效通过资源预留CPU、内存、临时存储各维度保障了k8s核心组件和操作系统的基础运行资源避免被业务容器耗尽通过驱逐机制主动清理高资源占用的普通容器将资源占用控制在合理范围本次演示节点内存使用率控制在85%以内临时存储使用率控制在40%以内避免资源超配和浪费。业务影响最小化高资源占用的pod被驱逐或无法调度仅影响该业务本身不会影响集群核心组件和其他正常运行的业务若业务pod配置多副本pod反亲和性可实现业务无感知切换彻底避免大面积业务故障降低业务损失提升业务可用性。资源利用率优化合理的资源预留配置避免了资源过度预留导致的浪费同时通过驱逐机制确保节点资源被高效利用提升集群整体资源利用率实现“资源不浪费、业务不中断”的目标。配置可复用性强本次优化方案的核心逻辑同时适配标准k8s和k3s集群配置参数可根据节点硬件灵活调整无需额外修改核心逻辑可直接复用至生产环境降低部署和维护成本。七、注意事项资源预留值需根据节点实际硬件配置调整避免预留过多导致资源浪费或预留不足无法保障核心组件运行建议CPU预留节点总CPU的10%-20%内存预留节点总内存的20%-30%临时存储预留节点总临时存储的20%-30%本次统一预留10Gi需结合节点实际存储大小调整若节点临时存储为30Gi预留10Gi合理若为50Gi可适当提升至15Gi。驱逐阈值需结合节点资源大小合理设置硬驱逐阈值不宜设置过低避免频繁驱逐pod影响业务稳定性软驱逐阈值可根据业务需求选择是否配置给业务留足缓冲时间建议软驱逐内存阈值比硬驱逐高0.5-1Gi缓冲时间设置1-5分钟适配不同业务的容忍度。标准k8s集群需分别配置kubelet和containerd两者的OOM优先级需保持一致均设为-999避免出现核心组件优先级不一致导致的异常k3s集群仅需配置k3s.service即可配置时需注意文件路径的正确性避免配置错误导致集群无法启动修改前建议备份原配置文件如cp /etc/systemd/system/k3s.service /etc/systemd/system/k3s.service.bak。配置修改后需执行systemctl daemon-reload重载系统服务配置再重启对应组件kubelet、containerd、k3s确保配置生效重启后建议检查组件状态和pod运行状态确认无异常后再恢复业务运行建议在业务低峰期操作避免影响运行中的业务。业务容器建议配置资源请求resources.requests和资源限制resources.limits进一步配合节点资源管控避免单个容器占用过多资源资源请求建议设置为容器正常运行所需的最小资源资源限制设置为容器可占用的最大资源两者配合实现精细化资源管控降低资源溢出风险。临时存储预留需结合容器日志、临时文件的生成量调整若业务容器会产生大量日志或临时文件如日志采集、数据处理类容器需适当提高临时存储预留值同时建议配置日志轮转策略避免因临时存储耗尽导致节点异常。生产环境中建议对节点资源使用情况进行持续监控如通过PrometheusGrafana实时关注资源使用率、驱逐事件等设置资源告警阈值如内存使用率超过80%告警及时调整资源配置避免出现资源溢出风险同时定期检查配置有效性根据业务变化调整参数。若集群节点数量较多建议通过Ansible、Kustomize等工具批量配置避免手动配置导致的遗漏和错误提升配置效率和一致性配置完成后建议在测试环境验证无误后再推广至生产环境。
