k8s集群资源优化（解决节点资源溢出导致的异常问题）

k8s集群资源优化（解决节点资源溢出导致的节点异常问题）

一、优化目的

本文核心目标是解决k8s集群中，因容器资源使用过高、超出节点可用资源，导致节点关键组件异常、节点状态变为NotReady，甚至节点直接宕机的问题。通过合理的资源配置优化，构建"资源预留-阈值管控-OOM保护"的三层防护体系，保障集群节点稳定运行，将业务故障影响降至最低，同时提升集群资源利用率，避免资源浪费，实现"稳定与高效"的双重目标。

二、实验环境构建

为简化k8s集群部署流程、降低测试环境搭建成本，本次实验采用k3s（轻量级k8s发行版）替代标准k8s集群进行实操演示。k3s具备部署简单、资源占用低、核心功能与标准k8s一致的特点，可快速搭建测试环境，且本次优化方案的核心逻辑完全适配标准k8s集群，优化配置可直接复用至生产环境的标准k8s集群，无需额外修改核心参数。

2.1 k3s安装方法（国内源，规避网络问题）

国内环境直接安装k3s易出现镜像拉取失败、网络超时等问题，以下提供两种国内源安装方式，可根据需求选择（推荐第二种指定版本+阿里云镜像加速，稳定性更高，适配国内网络环境）。

2.1.1 国内源在线一键安装（默认版本）

执行以下命令，通过 Rancher 国内镜像源一键安装k3s，默认安装最新稳定版，适用于无需指定版本、快速搭建测试环境的场景（注意：最新版本可能存在兼容性风险，生产测试建议优先选择指定稳定版本）：

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -

2.1.2 国内源在线一键安装（阿里云镜像+指定版本）

若需指定k3s版本，或需进一步提升镜像拉取速度，可使用阿里云镜像仓库加速，以下以v1.34.5+k3s1版本（稳定版，适配多数生产场景）为例，执行命令（版本可根据实际需求替换，建议选择官方长期支持版本）：

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_VERSION=v1.34.5+k3s1 INSTALL_K3S_EXEC="--system-default-registry=registry.cn-hangzhou.aliyuncs.com" sh -

说明：--system-default-registry 参数指定阿里云镜像仓库，可避免国外镜像拉取超时，大幅提升部署效率；安装完成后，可通过 k3s --version 命令验证版本是否正确。

mkdir -p ~/.kube
cp /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毫核CPU（1核=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时，强制驱逐pod
  nodefs.available: "10%"       # 节点根目录可用空间低于10%时，强制驱逐pod
  imagefs.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-arg=kube-reserved=cpu=500m,memory=1Gi,ephemeral-storage=10Gi' 
'--kubelet-arg=system-reserved=cpu=200m,memory=512Mi,ephemeral-storage=10Gi' 
'--kubelet-arg=enforce-node-allocatable=pods' 
'--kubelet-arg=eviction-hard=memory.available<300Mi,nodefs.available<10%,imagefs.available<15%,nodefs.inodesFree<5%'

说明：eviction-hard 中 memory.available<300Mi 是结合本次演示节点（2Gi内存虚拟机）调整的，实际需根据节点总内存灵活修改。

5.1.2 修改后的完整配置示例

以下为修改后的k3s.service完整配置（资源预留大小已适配2Gi内存虚拟机，实际部署时需根据节点硬件调整，若节点内存为4Gi，可将memory预留调整为1Gi-1.2Gi）：

[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
User=root
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
# 新增：OOM优先级配置，保障k3s核心进程不被OOM杀死
OOMScoreAdjust=-999
Restart=always
RestartSec=5s
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
# 新增：kubelet参数配置，实现资源预留、驱逐阈值管控（临时存储预留同步改为10Gi）
ExecStart=/usr/local/bin/k3s \
    server \
        '--system-default-registry=registry.cn-hangzhou.aliyuncs.com' \
        '--kubelet-arg=kube-reserved=cpu=500m,memory=512Mi,ephemeral-storage=10Gi' \
        '--kubelet-arg=system-reserved=cpu=200m,memory=512Mi,ephemeral-storage=10Gi' \
        '--kubelet-arg=enforce-node-allocatable=pods' \
        '--kubelet-arg=eviction-hard=memory.available<300Mi,nodefs.available<10%,imagefs.available<15%,nodefs.inodesFree<5%'

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 节点初始资源状态

查看节点当前内存、临时存储使用情况，确认初始资源充足，为后续测试做对比（测试前需确保节点无其他高资源占用进程）：

[root@VM-12-10-centos ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           2.0G        1.0G         97M        1.4M        839M        779M
Swap:            0B          0B          0B

# 查看临时存储使用情况（默认对应/var/lib/containerd目录，容器临时文件、日志均存储于此）
[root@VM-12-10-centos ~]# df -h /var/lib/containerd
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   12G   28G  30% /

5.2.2 集群初始状态

查看k3s集群pod运行状态，确认核心组件正常运行，无异常pod（若有异常pod，需先排查解决，避免影响测试结果）：

[root@VM-12-10-centos n9e]# kubectl get po -A
NAMESPACE     NAME                                      READY   STATUS    RESTARTS   AGE
kube-system   coredns-76f4bf7558-zw5vw                  1/1     Running   0          4m47s
kube-system   local-path-provisioner-75f7bc6c87-7rsn9   1/1     Running   0          4m47s
kube-system   metrics-server-56b58dfd89-5q5w5           1/1     Running   0          4m47s
kube-system   svclb-traefik-599c1f00-8mz4n              2/2     Running   0          4m46s
kube-system   traefik-5868cb565d-r7q9k                  1/1     Running   0          4m47s

5.2.3 创建高资源占用pod，验证优化效果

部署多个高内存、高临时存储占用的业务pod（如mysql、nightingale、redis，可自行选择大内存镜像），模拟资源溢出场景，执行部署命令（提前准备好对应yaml配置文件，确保pod资源请求/限制超出节点可分配资源，示例中mysql请求内存1Gi，超出节点可分配内存）：

[root@VM-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: 500m
    memory: 1Gi
    ephemeral-storage: 5Gi
  limits:
    cpu: 1000m
    memory: 2Gi
    ephemeral-storage: 8Gi

5.2.4 验证结果分析

部署完成后，通过以下命令查看节点、pod状态，验证优化配置的有效性，重点关注节点状态、pod状态、驱逐原因及临时存储使用情况：

1. 节点状态验证：查看节点状态，确认节点仍处于Ready状态，未出现NotReady或宕机情况，可正常执行所有系统命令（如free、df、kubectl等），说明资源预留和OOM保护生效，节点核心资源未被耗尽：

   [root@VM-12-10-centos manifests]# kubectl get no
   NAME              STATUS   ROLES           AGE   VERSION
   vm-12-10-centos   Ready    control-plane   14d   v1.34.5+k3s1

2. pod状态验证：查看pod运行状态，可见高资源占用的pod出现Pending（无法调度，因节点资源不足）或Evicted（被驱逐，因超出资源阈值）状态，未导致节点卡死，说明驱逐阈值配置生效，节点主动管控资源占用：

   [root@VM-12-10-centos ]# kubectl get po -A
   NAMESPACE     NAME                                      READY   STATUS                   RESTARTS      AGE
   kube-system   coredns-76f4bf7558-pgkdw                  1/1     Running                  0             9m50s
   kube-system   local-path-provisioner-75f7bc6c87-l2v85   1/1     Running                  0             9m50s
   kube-system   metrics-server-56b58dfd89-pkctd           1/1     Running                  0             9m50s
   kube-system   svclb-traefik-599c1f00-2v9x2              2/2     Running                  0             9m49s
   kube-system   traefik-5868cb565d-kh6jv                  1/1     Running                  0             9m50s
   nightingale   mysql-0                                   0/1     Pending                  0             86s
   nightingale   nightingale-6bc8bcf766-945c7              0/1     Pending                  0             91s
   nightingale   nightingale-6bc8bcf766-jz6hq              0/1     ContainerStatusUnknown   1 (99s ago)   6m47s
   nightingale   nightingale-6bc8bcf766-r2cxm              0/1     Evicted                  0             6m48s
   nightingale   nightingale-6bc8bcf766-tn6xz              0/1     Evicted                  0             92s
   nightingale   redis-0                                   0/1     Pending                  0             89s

3. 驱逐原因验证：查看被驱逐pod的详情，确认驱逐原因是节点内存压力（MemoryPressure），与我们配置的驱逐阈值一致，验证驱逐机制有效，节点可主动清理高资源占用pod：

   [root@VM-12-10-centos ]# kubectl -n nightingale describe po nightingale-6bc8bcf766-r2cxm
   Name:             nightingale-6bc8bcf766-r2cxm
   Namespace:        nightingale
   Priority:         0
   Service Account:  default
   Node:             vm-12-10-centos/
   Start Time:       Thu, 26 Mar 2026 11:28:58 +0800
   Labels:           app=nightingale
                 pod-template-hash=6bc8bcf766
   Annotations:      <none>
   Status:           Failed
   Reason:           Evicted
   Message:          Pod was rejected: The node had condition: [MemoryPressure]

4. 临时存储验证：查看临时存储使用情况，确认使用占比未超出预留阈值（本次演示中临时存储使用率38%，低于预留阈值），节点未出现存储压力，说明临时存储预留配置生效：

   [root@VM-12-10-centos ]# df -h /var/lib/containerd
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/vda1        40G   15G   25G  38% /

5.3 实操验证（已运行容器突然资源高场景）

为进一步验证OOM优先级和驱逐机制的有效性，部署一个未配置内存限制的pod，模拟生产中"已运行业务容器突然出现资源飙升"的场景，观察节点是否会优先杀死该pod或者pod里资源高的进程，而非核心组件，验证兜底防护效果。

# 部署未配置内存限制的测试pod（不设置resources.limits，模拟业务容器未配置资源限制的场景）
[root@VM-12-10-centos ~]# kubectl run test --image=swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/library/busybox:1.28 -- sleep 99d
pod/test created

# 确认pod正常运行
[root@VM-12-10-centos ~]# kubectl get po
NAME   READY   STATUS    RESTARTS   AGE
test   1/1     Running   0          3s

# 进入pod内部，执行命令让容器内存飙升（模拟业务异常，如程序内存泄漏）
[root@VM-12-10-centos ~]# kubectl  exec -it test  -- sh
/ #  dd if=/dev/zero of=/dev/null bs=1024G count=100
Killed
/ #

结果分析：执行内存飙升命令后，容器被系统快速杀死（Killed），而k3s节点仍处于Ready状态，核心组件（coredns、metrics-server等）正常运行，未出现节点卡死或宕机情况。这说明OOM优先级配置生效，系统优先杀死资源占用过高的普通业务pod，而非k3s核心进程，保障了节点核心组件的安全，与预期优化效果一致；同时验证了"兜底防护"的有效性，即使业务容器未配置资源限制，节点也能通过OOM优先级保护自身安全。

六、优化效果总结

通过本次资源优化配置（资源预留、驱逐阈值、OOM优先级），构建了"预防-管控-兜底"的三层防护体系，彻底解决节点资源溢出导致的异常问题，同时实现资源利用率与集群稳定性的平衡，核心优化效果如下：

1. 节点稳定性显著提升：即使部署超出节点资源限制的容器，或已运行容器突然出现资源飙升，节点也不会出现卡死、宕机或NotReady状态，k3s/k8s集群核心组件始终正常运行，可正常执行所有系统和集群命令，彻底解决节点资源溢出导致的异常问题。

2. 资源管控精准有效：通过资源预留（CPU、内存、临时存储各维度），保障了k8s核心组件和操作系统的基础运行资源，避免被业务容器耗尽；通过驱逐机制，主动清理高资源占用的普通容器，将资源占用控制在合理范围（本次演示节点内存使用率控制在85%以内，临时存储使用率控制在40%以内），避免资源超配和浪费。

3. 业务影响最小化：高资源占用的pod被驱逐或无法调度，仅影响该业务本身，不会影响集群核心组件和其他正常运行的业务；若业务pod配置多副本+pod反亲和性，可实现业务无感知切换，彻底避免大面积业务故障，降低业务损失，提升业务可用性。

4. 资源利用率优化：合理的资源预留配置，避免了资源过度预留导致的浪费，同时通过驱逐机制，确保节点资源被高效利用，提升集群整体资源利用率，实现"资源不浪费、业务不中断"的目标。

5. 配置可复用性强：本次优化方案的核心逻辑同时适配标准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），进一步配合节点资源管控，避免单个容器占用过多资源；资源请求建议设置为容器正常运行所需的最小资源，资源限制设置为容器可占用的最大资源，两者配合实现精细化资源管控，降低资源溢出风险。

• 临时存储预留需结合容器日志、临时文件的生成量调整，若业务容器会产生大量日志或临时文件（如日志采集、数据处理类容器），需适当提高临时存储预留值，同时建议配置日志轮转策略，避免因临时存储耗尽导致节点异常。

• 生产环境中，建议对节点资源使用情况进行持续监控（如通过Prometheus+Grafana），实时关注资源使用率、驱逐事件等，设置资源告警阈值（如内存使用率超过80%告警），及时调整资源配置，避免出现资源溢出风险；同时定期检查配置有效性，根据业务变化调整参数。

• 若集群节点数量较多，建议通过Ansible、Kustomize等工具批量配置，避免手动配置导致的遗漏和错误，提升配置效率和一致性；配置完成后，建议在测试环境验证无误后，再推广至生产环境。