华为云 CCE 工作负载起不来：Pending、ImagePullBackOff 与 CrashLoopBackOff 分层排查

云容器引擎 CCE 上，工作负载「起不来」时，控制台常见「未就绪」，kubectl get po 的 STATUS 则可能是 Pending、ContainerCreating、ImagePullBackOff、CrashLoopBackOff，偶尔还有 Evicted 或 Init:*。很多人一上来就换镜像或加大 CPU/内存，其实先用 STATUS 和 Events 定层，再按调度、镜像、启动/探针、节点与配额往下核，会快很多。本文对照华为云 CCE 官方排查文档整理分层清单。SWR 登录与组织权限此前已单独写过；这里只覆盖集群里工作负载为什么起不来，涉及 SWR 时只核对镜像地址和密钥是否一致。

一、先定层：用 STATUS 和 Events 分类

官方建议：工作负载异常时先看 Pod 事件，再针对性处理。控制台路径是集群 → 工作负载 → 选命名空间 → 查看负载状态。「未就绪」重点查 Pod；「处理中」一般是过程态，长时间不恢复按未就绪查；「运行中」通常不必处理。

实例状态以 kubectl get po 的 STATUS 为准。官方说明：STATUS 由 kubectl 根据 Pod 的 state.Phase、state.Conditions 和 status.ContainerStatuses 生成：

先固定一个异常 Pod：

kubectl get po -n <ns>
kubectl describe pod <pod-name> -n <ns>
kubectl get events -n <ns>

describe 底部的 Events 是定层依据。官方示例里，调度失败会看到 Warning FailedScheduling ... 0/2 nodes are available: 2 Insufficient cpu.。控制台等价操作是工作负载详情 → 异常实例操作栏「事件」。

容器日志不必一开始就登节点。控制台可在工作负载「日志」里切换实例和容器。官方「通过 ICAgent 采集容器日志」页给出的写法是：

kubectl logs <pod_name> -n <namespace>
kubectl logs <pod_name> -c <container_name> -n <namespace>

容器已在反复重启时，当前日志往往只是最新一次启动的输出。可用 kubectl logs <pod_name> -n <namespace> --previous 看上一轮退出前的标准输出；CCE「启动容器失败」排查页则建议到节点上，对已退出容器执行 docker logs 或 crictl logs。

二、Pending：先分清是调度，还是存储

Pending 且事件出现「实例调度失败」时，按事件原文对号入座。

no nodes available to schedule pods. 时，先 kubectl get node 确认是否都是 Ready。节点不可用时，需要修节点、重置节点，或新增节点（负载未设亲和时，Pod 可迁到新节点）。Insufficient cpu / Insufficient memory 表示 Pod 的 request 超过了节点可分配资源。官方说法是「实例资源的申请量」大于「节点可分配资源总量」。常见处理是给集群加节点。调度看的是已分配量，不是监控里瞬时还「空着」多少。

事件类似 didn't match node selector、didn't match pod affinity rules、didn't match pod affinity/anti-affinity 时，是节点选择器或亲和/反亲和互斥。若配置了节点亲和，还需确保目标节点标签 supportContainer 为 true，否则可能出现 MatchNodeSelector, NodeNotSupportsContainer。

had volume node affinity conflict 是因为云硬盘不能跨可用区挂载。CCE 创建的云硬盘 PV 默认带节点亲和，选择器 key 为 failure-domain.beta.kubernetes.io/zone。可重建与节点同可用区的存储卷，或重建负载并让存储卷自动分配。若事件其实是挂卷失败、添加存储失败，官方另有专题，不要和纯调度问题混着改亲和。

had taints that the pod didn't tolerate 时，用 kubectl describe node <node> 看 Taints。用户自己加的污点，可删除或在 Pod 里加 tolerations；系统自动加上的，先处理根因，污点通常会消失。官方列出的内置污点包括 node.kubernetes.io/not-ready、unreachable、memory-pressure、disk-pressure、pid-pressure 等。

Insufficient ephemeral-storage 表示节点临时存储不够，或 Pod 的 ephemeral-storage request/limit 超出可分配量，可用 kubectl describe node 对比 Capacity / Allocatable。everest driver not found at node 表示该节点上 everest-csi-driver 未处于 running，可检查 kube-system 里同名 DaemonSet，异常时删除对应 Pod 让其重建。Too many pods 表示节点上的 Pod 数超过「最大实例数」（kubelet 的 maxPods）。控制台「节点管理」页有 Pod(已分配/可用地址总数/总额度) 列，可直接看是否到顶。DefaultPool 节点需重置才能改最大实例数，自定义节点池可改 max-pods。

三、ImagePullBackOff：地址、密钥、网络，而不是再登录一次

控制台常见文案是「实例未就绪：Back-off pulling image “xxxxx”」，对应事件「实例拉取镜像失败」或「重新拉取镜像失败」。这里不重复 SWR 登录步骤。

用 kubectl/YAML 创建负载时，先看有没有 imagePullSecrets：拉 SWR 镜像时，name 需固定为 default-secret；拉第三方私有仓时，写成自己创建的 Secret 名称。default-secret 是 CCE 在每个命名空间下默认创建的系统密钥，类型为 kubernetes.io/dockerconfigjson，内容是登录 SWR 的凭据。它会定期更新，现有 data 过一段时间会失效；kubectl describe secret default-secret 能看到注解 swr-auth-may-expires-at。官方明确提醒：直接引用 default-secret，不要把内容复制出来另建成新 Secret，复制出去的凭据会过期。事件里若出现 denied: You may not login yet，优先查是不是漏了 imagePullSecrets，或 Secret 名写错。

SWR 控制台复制的下载指令形如 docker pull swr.cn-east-3.myhuaweicloud.com/group/nginx:v2.0.0，也就是 swr.<region>.myhuaweicloud.com/<组织>/<镜像名称>:<版本>。区域、组织、仓库名、tag 任一段和 SWR 不一致，节点都拉不到。第三方镜像官方格式是 domainname/organization/imagename:tag，没写版本时默认 latest；Docker 开源仓库可写 nginx:latest 这种短格式。地址填错时，事件里常见去连 registry-1.docker.io 并报 no such host。

连不上仓库时，事件可能是 Client.Timeout exceeded while awaiting headers。官方说明：SWR 仅支持直接拉取 Docker 官方镜像，其他仓库需要节点能出公网。处理是给节点绑公网 IP，或先把镜像上传到 SWR 再拉。x509: certificate signed by unknown authority 表示第三方仓库用了非知名或不安全证书，需要在节点上加载该仓库根证书并重启 docker/containerd。公共仓库限速时会出现 toomanyrequests 或 you have reached your pull rate limit，官方建议把常用镜像转到 SWR 再拉。

no space left on device 表示节点上存镜像的磁盘满了。可清理未使用镜像（containerd 用 crictl images / crictl rmi，docker 用 docker images / docker rmi），或按官方文档扩容数据盘并扩逻辑卷。不要删除 cce-pause 等系统镜像，否则容器会创建不出来。context canceled 可能是镜像过大或节点性能较差，拉取进度长时间无更新被取消。可先在节点上手动 crictl pull / docker pull，若想让节点使用已缓存的镜像，需在负载里明确设置 imagePullPolicy: IfNotPresent，并核对负载实际引用的镜像地址与 tag（或 digest）和节点上已有的一致。它不是无条件默认：镜像 tag 为 latest 或未写 tag 时，Kubernetes 默认策略是 Always。集群 v1.25 及以上还可改自定义节点池的 image-pull-progress-timeout；DefaultPool 不支持改该参数。

四、CrashLoopBackOff：进程退出、探针误杀，还是资源不够

镜像已经拉下来、容器却反复重启时，先看退出日志和探针事件，而不是继续改镜像地址。官方启动失败排查顺序是：到 Pod 所在节点，用 docker ps -a 或 crictl ps -a 找到已退出容器，再看 docker logs / crictl logs；同时可用 cat /var/log/messages | grep $containerID | grep oom 判断是否系统 OOM。控制台「日志」和前面的 kubectl logs / --previous 也能先看标准输出。

健康检查很容易被当成「程序一启动就挂」。官方对三种探针的职责如下：

• 存活探针（livenessProbe）：检查失败后会重启该容器。事件出现 Liveness probe failed 时，先看探针。
• 就绪探针（readinessProbe）：判断业务是否就绪，以决定是否转发流量。失败时，CCE 会临时把它从服务端点移除；同一页的失败阈值说明还写明：就绪探针连续失败后，Pod 被标为未就绪并从 Service Endpoints 去掉，容器不会被重启。因此 READY 长期不是 1/1、服务进不了流量，优先查就绪探针；反复重启优先查存活探针。
• 启动探针（startupProbe）：检测应用是否已启动。它通过之前，集群不会开始做存活和就绪检查，避免启动较慢的应用被提前终止。

公共参数的官方默认值：超时 timeoutSeconds 设为 0 或不设时默认 1 秒；成功阈值 successThreshold 默认 1，且存活/启动探针必须为 1；最大失败次数 failureThreshold 默认 3。HTTP 检查要求路径以 / 开头，返回码 200～399 视为成功；主机地址不填时默认是 Pod IP。

五、节点与配额：最大实例数、网卡、子网 IP 和驱逐

调度阶段的 Too many pods 只是配额问题的一种。节点到底能跑多少 Pod，还取决于集群网络模型：

节点默认最大实例数随内存变化（官方表，2026-10-14 版本；以当前网络模型、实例规格和集群版本的限制为准）：4G 为 20，8G 为 40，16G 为 60，32G 为 80，64G 及以上为 110。

Turbo 集群里，使用该容器网络的 Pod 创建时会分配一张网卡（hostNetwork: true 的 Pod 不在此列）。事件 no eni bound to pod 时，要继续看伴随信息：insufficient IP addresses in subnets 表示容器子网 IP 耗尽或未配子网，可在同一 VPC 下追加容器子网；insufficient NICs on node 表示节点已绑定网卡数达到规格上限，常见原因是给节点额外绑了弹性网卡，若必须额外绑网卡，需同步修改节点池 maxPods。

长时间「创建中」还可能是 cce-pause 系统镜像被误删，或开启 CPU 管理策略后在 ECS 侧改了节点规格。后者需按官方步骤处理 cpu_manager_state 并重启 kubelet。

若 STATUS 已是 Evicted，问题通常不在启动命令。节点 NotReady 或不可达时会被加上相应的 NoExecute 污点，之后 Pod 是否以及何时被驱逐，取决于 Pod 对该污点的容忍和 tolerationSeconds（常见默认约 300 秒；DaemonSet 等特殊 Pod、控制器或集群配置可能不同）；kubelet 则在节点资源压力下按优先级驱逐部分 Pod。kubelet 默认硬驱逐条件包括：memory.available<100Mi、nodefs.available<10%、imagefs.available<15%、nodefs.inodesFree<5%（Linux）。驱逐看的是资源使用率，调度看的是资源分配量，所以容易出现「刚被驱逐，又被调回原节点」。kubelet 驱逐后留下的 Evicted Pod 主要是定位记录，可以直接删除。

六、推荐排查顺序

1. 定层：kubectl get po -n <ns> 看 STATUS 和 RESTARTS，kubectl describe pod 或控制台「事件」记下原文。
2. Pending：先看是 FailedScheduling 还是挂卷。调度类按事件查节点 Ready、CPU/内存 request、污点、亲和、可用区、最大实例数。
3. ImagePullBackOff：核对完整镜像地址是否与 SWR（或第三方仓）一致，YAML 是否引用了正确的 imagePullSecrets（SWR 用 default-secret），节点能否访问仓库，磁盘是否写满。
4. CrashLoopBackOff：看当前日志和上一轮日志，对照退出码；有 Liveness probe failed 先调探针；有 OOM 再调内存。
5. 创建中 / 网卡类事件：查 cce-pause、Turbo 子网 IP 与网卡配额，不要当成普通镜像拉取失败。
6. Evicted：看节点压力污点和驱逐来源，而不是反复重建同一个 YAML。
7. 仍不明：到工作负载「日志」或已对接的 LTS 检索。

七、速查表

八、常见坑

1. 看监控还有空闲，调度却报资源不足：调度比较的是 request 与可分配量，不是瞬时使用率。
2. 复制 default-secret 另存一份：凭据会过期，过几天突然拉不下镜像。
3. 镜像地址只写了仓库名，区域或组织与 SWR 不一致：节点可能去公网仓库找，最后变成 DNS 或超时。
4. 清理磁盘时删掉 cce-pause：后续 Pod 会卡在创建 sandbox。
5. 把就绪探针失败当成崩溃：就绪失败通常只摘流量；反复重启先看存活探针。
6. 存活探针延迟过短：应用还没听端口就被重启，看起来像 CrashLoop。可加大 initialDelaySeconds，或加启动探针。
7. VPC/Turbo 集群只改 max-pods：IP 或网卡不够时，新建 Pod 仍然起不来。
8. 驱逐后又调度回原节点：使用率和分配量的判断标准不同，需要把 request 调整得更合理。

九、小结

CCE 工作负载起不来，本质是「调度到节点 → 拉取镜像 → 启动并通过探针 → 节点还有额度」这条链路在某一层断了。先读 STATUS 和 Events 定层，再改 YAML 或扩容，比来回猜测更快。镜像层只需保证地址和密钥与 SWR（或第三方仓）一致；启动层把日志、退出码和存活探针看清楚，大多能落到具体配置。文中命令、事件原文和默认值以当前控制台和官方文档为准。

参考（华为云官方文档）

• 工作负载状态异常定位方法：https://support.huaweicloud.com/cce_faq/cce_faq_00134.html
• 工作负载异常：实例调度失败：https://support.huaweicloud.com/cce_faq/cce_faq_00098.html
• 工作负载异常：实例拉取镜像失败：https://support.huaweicloud.com/cce_faq/cce_faq_00015.html
• 工作负载异常：启动容器失败：https://support.huaweicloud.com/cce_faq/cce_faq_00018.html
• 设置容器健康检查：https://support.huaweicloud.com/usermanual-cce/cce_10_0112.html
• 集群系统密钥说明（default-secret）：https://support.huaweicloud.com/usermanual-cce/cce_10_0388.html
• 拉取镜像到本地（SWR 地址示例）：https://support.huaweicloud.com/usermanual-swr/swr_01_0017.html
• 工作负载异常：一直处于创建中：https://support.huaweicloud.com/cce_faq/cce_faq_00140.html
• 节点可创建的最大 Pod 数量说明：https://support.huaweicloud.com/usermanual-cce/cce_10_0348.html
• CCE Turbo 集群如何修复出现故障的容器网卡：https://support.huaweicloud.com/cce_faq/cce_faq_00121.html
• 工作负载异常：实例驱逐异常（Evicted）：https://support.huaweicloud.com/cce_faq/cce_faq_00209.html
• 登录容器实例：https://support.huaweicloud.com/usermanual-cce/cce_10_00356.html
• 通过 ICAgent 采集容器日志（含 kubectl logs）：https://support.huaweicloud.com/usermanual-cce/cce_10_0018.html