阿里云海外代理商阿里云容器服务 ACK 节点状态显示 NotReady 原因排查（Kubelet/CRI 异常）

← 返回列表

很多人看到 ACK 节点变成 NotReady，第一反应是“集群坏了”。但实际排查里，真正卡住的往往不是 Kubernetes 本身，而是节点侧的 kubelet、containerd/dockerd、系统磁盘、网络连通性，或者账号侧的欠费、风控、权限限制。对用户来说，最关心的不是原理，而是“这台节点能不能马上恢复、要不要重建、会不会影响业务、后面还会不会再发生”。

如果你现在正卡在 NotReady，先不要急着重装系统。先看节点是否还能登录、ACK 控制台是否还能同步状态、Pod 是否只在少数节点异常。如果是单节点异常，通常优先定位节点本身；如果是整批节点一起异常，要先检查账号、地域网络和镜像拉取能力，这类问题往往不是单机故障。

先判断：是节点问题，还是账号/账单问题

很多排查会被忽略的一点是：节点状态异常，有时是云资源侧问题间接触发的。比如账号欠费后，部分实例会进入受限状态；实名认证未通过，某些新购资源或变更操作会被拦截；风控审核触发时，短时间内批量创建节点池、频繁更换支付方式，也可能导致控制台操作失败。

先看 ECS 实例是否正常运行，是否还能 SSH 登录。
再看 ACK 集群里是否只有单节点 NotReady，还是多个节点同时掉线。
如果节点已经不通，优先查账单、到期时间、控制台告警和工单通知。
如果是新建节点后很快变成 NotReady，重点看镜像拉取、VPC、Security Group 和系统初始化脚本。

最常见的 4 类原因

1. Kubelet 没起来，或者反复崩溃

这是最常见的。节点上 kubelet 无法正常注册到控制面，ACK 控制台就会显示 NotReady。实际场景里，常见触发点是系统更新后配置文件被改坏、证书过期、节点磁盘满了、内存不足导致进程被杀。

阿里云海外代理商 你可以先在节点上看：

systemctl status kubelet
journalctl -u kubelet -xe

如果日志里出现证书、配置文件、无法连接 API Server、cgroup 不兼容这几类关键词，通常就不是“ACK 面板刷新慢”，而是节点已经失去注册能力。

2. CRI 异常，容器运行时挂了

如果 containerd 或 dockerd 异常，kubelet 即使在跑，也可能判断节点不可用。实操里最常见的是镜像拉取失败、运行时配置损坏、磁盘空间不足，或者升级后版本不匹配。

建议同步检查：

systemctl status containerd
journalctl -u containerd -xe
df -h

如果根分区只剩下几个 GB，或者 /var/lib/containerd、/var/lib/kubelet 爆满，先清理再判断，不要一上来重建节点。很多业务中断其实是磁盘告警没处理。

3. 节点网络不通，导致心跳丢失

有些节点在本地看着“活着”，但 ACK 侧就是显示 NotReady。这类情况常见于安全组收紧、NAT 网关策略调整、DNS 解析异常、出口到控制面网络被拦，或者跨地域访问不稳定。

如果你最近做过以下动作，要优先回看变更：

修改安全组规则，误删了必要出站访问。
切换 VPC 路由、NAT、EIP 或出口代理。
更换镜像仓库地址，导致拉取超时。
阿里云海外代理商 节点所在地域和业务访问地域不一致，延迟被放大。

4. 资源不足，节点被“拖死”

这类问题在低配节点上很常见。比如 2 核 4G 节点同时跑业务容器、日志采集、监控组件和系统守护进程，内存抖动后 kubelet 会先慢，再掉，再重启失败。表面看像“突然 NotReady”，其实是长期资源压榨的结果。

如果节点经常在高峰时段掉线，别只看 CPU。重点看内存、磁盘 IO、inode 和进程数。很多线上故障不是算力不够，而是系统盘太小。

实操排查顺序，别反着来

建议按这个顺序处理，效率最高：

确认 ECS 实例是否在线，能否 SSH 登录。
检查 kubelet 和 CRI 服务状态。
看磁盘、内存、inode 是否紧张。
查看最近 1 小时内是否有变更：升级、重启、改安全组、改镜像、改脚本。
检查节点日志里是否有证书、网络、镜像拉取错误。
如果是单节点且业务有冗余，优先隔离问题节点，再修复或替换。

不少人会直接重装节点，这样虽然快，但如果根因是账号欠费、地域网络、镜像仓库访问受限，重装后还会复发。真正该重装的，是已经出现系统级损坏、日志证据明确、恢复成本高于重建的节点。

账号购买、实名认证、充值续费这些问题，会不会影响排查

会，而且影响比很多人想象得大。尤其是刚买 ACK、刚开通 ECS、或者准备补节点时，账号状态会直接决定你能不能继续操作。

实名认证未完成：通常会影响新资源创建、扩容、部分计费变更操作。
充值余额不足：节点到期、按量计费实例、带宽和日志服务都可能被连带影响。
支付方式异常：信用卡扣款失败、PayPal 失败、账单未结清时，控制台里经常先看到“操作失败”，后面才发展成节点异常。
风控审核：批量开通、短时间多地区切换、异常支付行为，可能触发人工复核，节点创建和续费会变慢。

如果你是生产环境，建议至少提前做两件事：一是把节点到期和账单告警接到企业常用通知渠道；二是确保主账号、RAM 权限和支付方式可用，不要把续费压到最后一天。很多“节点 NotReady”最后查出来，根因不是技术故障，而是实例因欠费或续费失败进入限制状态。

支付方式和成本，怎么选更稳

从实际运维看，最省心的支付方式不一定是最便宜的，而是“失败率最低、补款最及时”。如果你是临时测试环境，按量付费更灵活；如果是长期生产环境，包年包月更适合做成本控制，但要盯紧到期时间和续费策略。

场景	更适合的方式	实际注意点
短期验证、PoC	按量付费	方便开关，但要防止忘记关停导致费用累积
稳定生产集群	包年包月	要提前续费，避免节点到期引发业务中断
跨境或国际业务	支持当地常用信用卡/PayPal 的方式	重点防风控审核和扣款失败
频繁扩缩容	账户余额充足 + 自动化告警	比单纯追求低单价更重要的是操作稳定性

成本上，ACK 节点真正花钱的不只有 ECS。系统盘、公共带宽、NAT 网关、日志、监控、快照、镜像仓库流量都可能叠加。很多团队以为“节点一天几十块”，最后月账单翻倍，原因就是配套资源没算进去。

哪些情况建议直接换节点，不要硬修

以下几种情况，继续修旧节点往往不划算：

系统盘损坏、文件系统报错反复出现。
kubelet 和 CRI 服务反复起不来，重启后只能短暂恢复。
节点已经被多个 Pod 反复写爆，日志证据不完整。
你没有把握恢复时间，业务又没有容灾。

如果是无状态工作负载，通常做法是先把 Pod 迁走，再替换节点。对于有状态业务，先确认数据是否在云盘、NAS 或独立存储上，不要因为一个节点故障直接把数据一起带走。

用户最常问的几个问题

Q：节点显示 NotReady，但 Pod 还在跑，要不要立刻处理？
A：要。Pod 还能跑不代表节点没问题，很多故障是“先 NotReady，后全量驱逐”。如果业务重要，至少先保留日志，再看是否能恢复 kubelet/CRI。

Q：重启节点是不是最快？<