RKE1 + Kubernetes 1.16.3 节点 UPDATE 事件频繁排查文档

一、问题描述

在 RKE1 + Kubernetes 1.16.3 集群中，审计/告警平台频繁上报 Node 资源的 UPDATE 事件，原因未知，需要排查和解决。

事件样例（来自告警平台）

项目	内容
集群	苏州集群（云平台 SZB 集群）
节点	szb13036
状态	resolved
资源类型	Node
操作用户	system:serviceaccount:kube-system:node-controller
操作	UPDATE
执行内容	无数据
时间	2026-07-22 21:40:45 / 21:40:48（间隔仅 3 秒）

关键特征：发起方是 kube-system 命名空间下的 node-controller ServiceAccount，操作对象是 Node 资源，频率高（秒级）。

---

二、原理分析：node-controller 为什么会更新 Node

node-controller 是 kube-controller-manager 中的核心控制器，负责节点生命周期管理。它会周期性地更新 Node 对象，常见的更新内容包括：

1. Node Status 心跳更新

   • kubelet 定期上报节点状态（node.status.conditions），node-controller 参与处理与确认。
   • 默认情况下节点状态更新有 10 分钟租约（Lease）机制，K8s 1.14+ 心跳主要由 Lease 对象承担，Node 对象本身不应被频繁全量更新。

2. Node 污点（Taint）管理

   • 当节点 NotReady / Unreachable 时，node-controller 会给节点打/删 node.kubernetes.io/not-ready、node.kubernetes.io/unreachable 等污点。
   • 如果节点网络不稳定、kubelet 频繁在 Ready/NotReady 之间抖动，node-controller 会反复打删污点，表现为对 Node 的频繁 UPDATE。

3. Pod Eviction（驱逐）

   • 节点失联超过 --pod-eviction-timeout（默认 5 分钟）后，node-controller 驱逐该节点上的 Pod，也会伴随 Node 更新。

4. CIDR / IPAM 相关更新

   • 分配或回收 PodCIDR 时更新 Node spec。

5. 云厂商控制器（cloud-controller）联动

   • 云平台集群（本例为 SZB 云平台集群）中，云控制器可能频繁回写 Node 的 addresses、labels、annotations（如实例 ID、内外网 IP 变化）。

---

三、排查步骤

1. 确认事件的实际更新内容

开启/查看 API Server 审计日志（audit log），确认 UPDATE 到底改了什么字段：

# 在 API Server 审计日志中过滤该节点、该用户的请求
grep 'szb13036' /var/log/kubernetes/audit.log | \
  grep 'node-controller' | grep '"verb":"update"' | head -20

重点查看 requestObject / responseObject 中变化的字段：

• 若是 status.conditions 反复变化 → 节点状态抖动（见第 2 步）
• 若是 spec.taints 反复增删 → 污点抖动
• 若是 metadata.annotations/labels 变化 → 云控制器或其他组件回写

2. 检查节点是否状态抖动（最常见原因）

# 查看节点当前状态
kubectl get node szb13036 -o wide

# 查看节点事件，观察是否有 Ready/NotReady 反复
kubectl describe node szb13036 | tail -40

# 查看该节点的 Lease 心跳是否正常
kubectl get lease szb13036 -n kube-node-lease -o yaml

# 查看集群事件中的 NodeNotReady/NodeReady 记录
kubectl get events -A --field-selector involvedObject.name=szb13036 --sort-by=.lastTimestamp

同时检查该节点上 kubelet 与容器运行时的日志：

# 在节点 szb13036 上执行
journalctl -u kubelet --since "1 hour ago" | grep -iE "error|fail|timeout"
docker ps -a | head    # 确认运行时健康

3. 检查 kube-controller-manager 参数与日志

RKE1 集群中 controller-manager 以静态 Pod 形式运行：

# 查看启动参数（关注 sync 周期、eviction 相关参数）
docker ps | grep kube-controller-manager
docker inspect <cid> | grep -A 50 '"Cmd"'

# 查看日志中 node-controller 相关记录
kubectl -n kube-system logs -l component=kube-controller-manager --tail=500 | grep -i "szb13036\|node_controller\|taint"

关键参数参考：

参数	默认值	说明
--node-monitor-period	5s	节点状态同步周期
--node-monitor-grace-period	40s	判定 NotReady 的宽限时间
--pod-eviction-timeout	5m	失联后驱逐 Pod 的超时
--node-eviction-rate	0.1	每秒驱逐速率

4. 检查是否为云控制器频繁回写

云平台集群常见 cloud-controller-manager 或自研 agent 定期刷新 Node 信息：

# 观察 Node 的 annotations/labels 是否在变
kubectl get node szb13036 -o jsonpath='{.metadata.annotations}' | jq .

# 对比 resourceVersion 增长速率
watch -n 5 'kubectl get node szb13036 -o jsonpath="{.metadata.resourceVersion}{\"\n\"}"'

若 resourceVersion 每几秒增长一次且内容无实质变化，说明某组件在做"无效更新"（no-op update），可定位到该组件并优化。

5. 检查 RKE 层面

# RKE1 集群状态与 k8s 版本
rke version
kubectl version --short

# 确认 cluster.yml 中 controller 的 extra_args 配置
cat cluster.yml

---

四、常见原因与解决方案

原因 1：节点网络/负载导致 Ready 状态抖动 → node-controller 反复打删污点

现象：事件中 Node UPDATE 伴随 taints 增删；kubectl get node 偶发 NotReady。

解决：

• 排查节点与 API Server 之间的网络质量（跨机房专线抖动、丢包）。
• 检查节点 CPU/内存/磁盘压力（node pressure 会触发 condition 变化）：

kubectl describe node szb13036 | grep -A 10 Conditions

• 可适当调大宽限参数降低敏感度（在 RKE cluster.yml 中配置）：

services:
  kube-controller:
    extra_args:
      node-monitor-grace-period: "60s"
      pod-eviction-timeout: "10m"

原因 2：kubelet 心跳/状态上报异常（K8s 1.16 已知问题）

• 1.16.3 属于较老版本（2019 年发布），存在多项 node lifecycle 相关 bug（如 Lease 与 Node 状态同步竞争），后续 patch 版本已修复。

解决：评估将集群升级到 1.16 的最新 patch（如 1.16.15），或整体升级到更高版本（建议 1.20+，注意 RKE1 的版本支持矩阵）。

原因 3：云平台控制器/agent 无效刷新 Node 对象

现象：resourceVersion 持续增长但 diff 为空或仅 resourceVersion/managedFields 变化。

解决：

• 定位云平台上该 agent（如节点元数据同步组件），让其只在内容变化时才调用 Update（先比较再写）。
• 此类 UPDATE 一般无害，若只是告警噪音，可在告警规则中过滤：user == system:serviceaccount:kube-system:node-controller 且资源 == Node 的事件降噪处理。

原因 4：监控/告警系统将正常 controller 行为误报

node-controller 对 Node 的 UPDATE 本身属于 Kubernetes 正常控制循环行为，只要：

• 节点状态稳定（始终 Ready）；
• 无 Pod 被异常驱逐；
• 更新间隔符合 sync 周期；

则可认为是正常事件，建议在告警平台将其加入白名单/降噪。

---

五、结论与建议

1. 从样例看（同一节点 3 秒内两条 UPDATE、用户为 node-controller），最可能是该节点状态（conditions/taints）在短时间内发生抖动，或控制器在每次 sync 周期都写入 Node 对象。
2. 优先执行排查步骤 1、2：通过审计日志确认更新字段、确认节点是否 Ready/NotReady 抖动。
3. 若为正常控制循环行为 → 告警降噪/加白名单即可。
4. 若为节点抖动 → 治理节点网络与资源压力，必要时调大 node-monitor-grace-period。
5. 长期建议：规划集群升级，K8s 1.16.3 已停止维护多年，存在大量已修复的稳定性与安全缺陷。

---

文档生成时间：2026-07-22数据来源：rke1+k8s1.16.3.txt（苏州集群 / 云平台 SZB 集群告警事件）