CCE节点NotReady网络异常定位方法详解

CCE节点从Ready翻成NotReady，往往不是单一组件故障，而是kubelet心跳、CNI插件、安全组规则中的某一环先断开。做CCE节点NotReady网络异常定位时，如果只重启节点或删除重建，通常会在几小时或几天后再次复现。下面从状态定义和网络诱因开始梳理。

CCE节点NotReady概述

CCE节点进入NotReady，本质是kubelet无法在规定窗口内向控制面上报心跳。默认的node-monitor-grace-period约为40秒，网络抖动只要持续超过这个时间，节点状态就会翻转。网络异常在CCE托管集群里是最常见的诱因之一，但表现不一定明显：节点可能还能被ping通，容器网络也可能仍有一部分在转发。从聚搜云接触到的企业运维场景来看，相当一部分NotReady并非节点真正宕机，而是kubelet到API Server的链路被安全组或ACL静默切断，节点本身仍可被ping通。这种故障最容易在变更安全组后出现，恢复后如果没有回滚规则，几小时后又会复发。

什么是NotReady状态？

kubelet每隔一段时间向API Server上报节点心跳，并在Conditions中更新Ready字段。若控制面在node-monitor-grace-period默认约40秒内没有收到心跳，就会把节点标成Ready=False，进而进入NotReady。这个状态不等于节点宕机，更多时候意味着控制面与节点之间的通信链路已经不稳定。理解为“节点失联”比“节点故障”更接近实际，这也是排查时不能只盯着节点是否存活的原因。

为什么网络异常最容易触发NotReady？

CCE节点依赖多层网络：VPC路由、安全组、子网ACL、CNI插件，以及元数据服务169.254.0.0/16。节点初始化和组件鉴权都依赖这套链路，安全组误封元数据网段或API Server端口时，kubelet心跳会先断掉。已经运行的Pod因为走CNI和VPC路由，可能暂时不受影响，这就造成“Pod还能通，节点却NotReady”的假象。网络问题也因此比磁盘或内存故障更具隐蔽性。

哪些影响范围需要第一时间确认？

节点进入NotReady后，调度器不会再向该节点分配新Pod，已有的Pod会根据污点和驱逐策略进入迁移。若故障节点上恰好是单副本的Deployment，业务会直接暴露。若同时伴随CNI插件异常，新建Pod会卡在ContainerCreating。因此处理顺序不是急着恢复节点，而是先确认影响哪些namespace和工作负载，再决定是临时摘流还是先做网络排查。

定位前的准备工作

需要哪些工具权限

排查 CCE 节点 NotReady 前，至少要具备三类权限：集群侧 kubectl get nodes、describe node 和读取 Events 的 RBAC 权限；节点侧 SSH 或云控制台 VNC 登录权限；VPC 安全组和子网 ACL 的只读权限。工具方面，kubectl、nc -vz、ip route、iptables-save、journalctl 需要一并准备好，因为网络类 NotReady 往往要跨控制面、数据面和节点内核三个层检查。华为云 CCE 节点依赖云元数据服务，排查时不能只盯着容器网络，元数据链路也要纳入初始检查范围。

如何获取节点日志

节点状态异常时，优先通过 journalctl -u kubelet -n 200 --no-pager 查看 kubelet 最近的报错，关注 Failed to update node status、dial tcp ... i/o timeout 或 CNI 插件初始化失败这几类关键字。容器运行时则执行 journalctl -u containerd 或 journalctl -u docker。华为云控制台还提供节点日志采集和下载，适合节点无法 SSH 登录时使用。获取日志前要确认节点根盘没有写满，否则 journald 可能已经停止落盘，看到的日志会缺失关键时间段。

熟悉CCE网络模型

CCE 节点 NotReady 与网络模型强相关。默认 VPC-router 模型下，Pod IP 直接从 VPC 子网分配，节点路由表需要包含 Pod 网段指向节点的路由条目；如果是 Overlay 模型，则依赖 CNI 隧道和节点间 VPC 互通。做好定位准备时，建议先确认集群使用哪种容器网络模型，并检查 kubectl get pods -n kube-system | grep cni 中 CNI 组件是否 Running。从华为云代理商聚搜云整理的运维案例来看，不少 NotReady 的根因并不在 kubelet 本身，而在 CNI 组件异常或 VPC 路由被误删，因此提前理解网络模型能避免把时间都花在重启节点上。

一步步定位网络异常

节点进入 NotReady 后，先不要急着重启或删除节点，按“网络连通性 → kubelet 日志 → CNI 插件状态”三层排查，能避免把临时抖动误判为节点故障。从聚搜云接触到的华为云 CCE 运维场景来看，多数 CCE 节点 NotReady 网络异常最终都落在安全组、VPC 路由表或 CNI 配置上，真正需要重建节点的比例并不高。

检查节点网络连通性

先执行 kubectl get nodes -o wide 和 kubectl describe node <node-name>，确认 NotReady 是心跳超时还是 CNI 未就绪。接着在故障节点上验证三条关键链路：节点到 API Server 的 6443/5443 端口、节点到同 VPC 其他节点、节点到元数据服务 169.254.0.0/16。可以用 nc -vz <API-Server-IP> 6443 或 curl -k https://<API-Server-IP>:6443/healthz 测试。常见误区是 ping 通了就认为网络正常，但 kubelet 心跳走的是 TCP 443 或 6443，安全组可能只放通了 ICMP，导致节点间能 ping 通但 kubelet 上报失败。

查看kubelet日志

journalctl -u kubelet -n 200 --no-pager 是定位 NotReady 最直接的命令。重点抓取 Failed to update node status、network plugin is not ready、dial tcp ... i/o timeout 这几类报错。如果日志里反复出现 connection refused 或 timeout，基本可以判定 kubelet 到 API Server 的链路被安全组或路由阻断；如果出现 CNI 相关错误，则转入插件层排查。同时建议对照 journalctl -u containerd 或 journalctl -u docker，确认容器运行时是否同步异常。不要只看最新的几行日志，NotReady 可能发生在几分钟前，需要结合 kubectl describe node 里的 LastHeartbeatTime 倒推时间窗口。

分析CNI插件状态

CCE 默认使用 VPC-router 或 Overlay 容器网络模型，节点 NotReady 时如果 CNI 组件异常，新建 Pod 会卡在 ContainerCreating。执行 kubectl get pods -n kube-system | grep cni 查看 CNI Pod 是否处于 Running 状态，再检查故障节点上 /etc/cni/net.d/ 下的配置文件是否与正常节点一致。实际定位中，第三方 CNI（如 Calico、Cilium）与 CCE 网络模型冲突、节点路由表被误清空导致 CNI 无法分配 IP 的情况并不少见。用 ip route 和 iptables-save 与同集群正常节点做 diff，往往能快速发现路由条目缺失或 NAT 规则错误。

常见原因与修复方案

在CCE节点NotReady的处置中，网络侧根因很少是单一问题，安全组、子网路由表和内核参数经常交叉出现。从聚搜云接触到的企业运维场景来看，直接重启节点虽然能让状态暂时恢复，但如果底层规则没有修正，故障通常会在几小时到几天内复现。所以下面按三个最常见原因拆开，给出可复现的命令和修复动作。

安全组规则配置错

安全组误配置是CCE节点NotReady最常见的网络根因。节点初始化和kubelet上报依赖元数据服务与API Server，规则被改动后，kubelet到6443端口会被静默拦截。定位时执行 curl -k https://<API-Server-IP>:6443/healthz，超时则对比正常节点，重点检查是否放通VPC内网、169.254.0.0/16和TCP 6443。修复应恢复默认模板，避免自定义规则覆盖控制面端口。

子网路由表异常

子网路由表异常常表现为节点间二层可通，但到API Server的跨子网路径中断。VPC路由被误改或优先级错误时，kubelet心跳会上报超时。用 ip route 对比正常节点，确认默认路由下一跳是否指向VPC路由器。若路由表被清空，需从控制台重新下发子网关联，不要手动添加静态路由，否则重启后会再次覆盖。修复后执行 ip route get 169.254.169.254 验证元数据可达性，再观察40秒内节点状态。

内核参数不当

内核参数不当较隐蔽，常见于节点自定义优化后。例如 net.ipv4.ip_forward 被关闭或 tcp_keepalive_time 被调小，会导致Pod跨节点通信中断或kubelet长连接被重置。先看 journalctl -u kubelet -n 200 --no-pager 是否出现 i/o timeout，再执行 sysctl -a | grep -E 'ip_forward|tcp_keepalive'。修复不要只改 /etc/sysctl.conf，还要确认 br_netfilter 模块已加载。改完 sysctl -p 并重启kubelet，节点即可恢复Ready。

如何预防NotReady

从上海华为云代理商聚搜云整理的运维案例来看，CCE节点NotReady的预防重点不在“事后重建快”，而在于把网络配置变更和节点健康监控前置。下面拆成三个层面。

配置健康检查告警

Prometheus告警规则里建议同时监控三类指标：节点NotReady状态（kube_node_status_condition）、kubelet心跳超时次数、节点网络接收丢包率（node_network_receive_drop_total）。丢包率阈值设1%比5%更合理，因为kubelet默认40秒上报周期内，短时丢包就可能触发状态翻转。告警触发后先看kubectl describe node的Conditions和最近心跳时间，区分是kubelet上报异常还是网络完全不可达，避免一上来就重启节点。

定期检查网络配置

安全组误改是节点NotReady最常见的根因，所以网络配置要当代码管。建议把安全组、路由表、CNI配置（/etc/cni/net.d/）纳入Terraform或配置管理，每月做一次正常节点与故障节点的ip route、iptables-save diff。重点核对到API Server的6443端口出方向规则和元数据服务169.254.0.0/16是否被误拦。发现控制台手动改过安全组，要回看操作记录并沉淀成变更单，否则节点重建后同样问题会复现。

采用高可用架构

单节点NotReady影响面取决于Pod调度策略。核心业务必须配置podAntiAffinity让副本分散到不同节点，同时给coredns、ingress controller这些集群组件设多副本并打散。节点池建议至少跨两个可用区，因为网络故障经常是按可用区出现的。配合PodDisruptionBudget限制主动驱逐时的不可用副本数，这样即使某个节点网络异常，也不会出现整个服务同时中断的情况。

西安华为云代理商支持

技术协助与工单支持

遇到 CCE 节点 NotReady 后，如果内部排查链路超过 2 小时仍未定位，工单支持应直接附带节点名、故障时间窗和 journalctl -u kubelet --since 输出。从西安华为云代理商聚搜云整理的工单处理记录看，安全组出方向漏放 6443 端口是较常见根因，占同类工单比例接近四成；其次是 VPC 路由表被误清，导致节点访问 API Server 超时。技术支持侧通常会优先核对云 API 审计日志中的安全组变更时间，而不是直接建议重建节点。

定期巡检优化建议

定期巡检不要只查节点 CPU 和磁盘，网络异常往往是渐变后突变。建议在 Prometheus 里对 node_network_receive_drop_total 和 node_network_transmit_drop_total 设置持续告警，阈值超过 1% 就触发工单排查。同时检查 kube-system 命名空间下 CNI 组件 Pod 的重启次数，kubectl get pods -n kube-system | grep cni 如果存在 CrashLoopBackOff，即使节点暂时 Ready，也说明网络插件已不稳定，离 NotReady 可能只差一次短时抖动。

紧急响应服务

对核心生产集群，紧急响应第一步不是 kubectl delete node，而是先 kubectl cordon 隔离节点并保留现场。需要立即抓取 ip route、iptables-save 以及 journalctl -u kubelet -n 300，否则节点重启后这些证据会被覆盖。西安华为云代理商聚搜云在实际运维中遇到过节点恢复后无法复现的情况，原因正是现场未保留；后续只能等下一次故障才能比对 CNI 配置差异。恢复调度后，仍需持续观察节点状态至少 30 分钟。