4. Pod 启动失败排查：ImagePullBackOff、CrashLoopBackOff、Init 容器失败的原因与修复步骤

在 Knative Service 部署过程中，Pod 无法进入 Running 状态是最常见的故障场景。本章聚焦三种核心启动失败模式：ImagePullBackOff（镜像拉取失败）、CrashLoopBackOff（容器反复崩溃重启）以及 Init 容器失败（初始化任务未完成）。掌握这些模式的根因定位与修复方法，是 SRE 保障 Serverless 工作负载稳定性的基本功。

4.1 ImagePullBackOff：镜像拉取失败

ImagePullBackOff 表示 Kubernetes 无法从指定镜像仓库拉取容器镜像，经过多次重试后进入退避状态。Knative 场景下，镜像通常由 Container 字段指定，或通过 revisionTemplate 中的 image 定义。

4.1.1 常见原因

4.1.2 修复步骤

1. 验证镜像地址：在集群外使用 docker pull <image> 或 crictl pull <image> 测试镜像是否存在且可拉取。
2. 检查 ImagePullSecret：确认 ServiceAccount 已关联正确的 Secret，且 Secret 中的 .dockerconfigjson 包含有效的认证信息。

   kubectl get serviceaccount default -n <namespace> -o yaml
   kubectl get secret <pull-secret-name> -n <namespace> -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d

3. 排查网络连通性：在集群节点上测试能否解析 Registry 域名并建立连接。

   kubectl run test-pod --image=busybox -it --rm -- nslookup <registry-host>

4. 处理限流：为 Knative Service 的 ServiceAccount 绑定 Docker Hub 认证 Secret，或迁移至镜像缓存/私有 Registry。
5. 验证 Knative 配置：检查 ksvc 的 spec.template.spec.containers[].image 字段是否正确。

4.2 CrashLoopBackOff：容器反复崩溃重启

CrashLoopBackOff 表明容器进程启动后立即退出（退出码非 0），Kubernetes 不断重启容器，每次重启间隔指数级增长。这是 Knative 工作负载中最常见的运行时故障。

4.2.1 根因分类

4.2.2 修复步骤

1. 获取容器日志：使用 kubectl logs <pod-name> --previous 查看上一次崩溃的日志（当前容器可能已重启多次）。
2. 检查退出码：通过 kubectl describe pod <pod-name> 查看 Last State 中的 Exit Code。
3. 分析应用启动逻辑：确认应用是否依赖外部服务（如数据库、配置中心），启动时是否进行健康检查。Knative 默认使用 tcpSocket 或 httpGet 探针，探针失败也会导致容器被重启。
4. 调整资源限制：如果退出码为 137，增加 resources.limits.memory 或检查应用内存配置。

   kn service update <service-name> --limit-memory=512Mi

5. 验证启动命令与参数：检查 command 和 args 是否正确，工作目录是否存在。
6. 测试本地运行：在本地使用 Docker 运行相同镜像，模拟 Knative 环境变量和启动参数，复现崩溃。

4.3 Init 容器失败

Init 容器在应用容器启动前执行，用于完成初始化任务（如数据库迁移、配置文件生成、权限设置）。如果 Init 容器失败，Pod 将停留在 Init:Error 或 Init:CrashLoopBackOff 状态，用户容器永远不会启动。

4.3.1 失败原因

• 初始化脚本错误：Shell 命令语法错误、依赖工具缺失、环境变量未传递。
• 外部依赖不可用：Init 容器尝试连接数据库、API 或挂载卷，但目标未就绪。
• 资源不足：Init 容器未单独设置资源限制，导致与用户容器争抢资源被 OOM 杀死。
• 卷挂载冲突：Init 容器与用户容器共享卷时，写入权限或路径冲突。
• 超时：Init 容器执行时间过长，超过默认活跃截止时间（默认 60s，可通过 activeDeadlineSeconds 调整）。

4.3.2 修复步骤

1. 查看 Init 容器日志：使用 kubectl logs <pod-name> -c <init-container-name> 获取 Init 容器的输出。
2. 检查 Init 容器状态：通过 kubectl describe pod <pod-name> 查看 Init Containers 段的 State 和 Last State。
3. 验证命令与参数：确认 initContainers[].command 和 args 在容器内可执行。建议在 Init 容器镜像中预装调试工具（如 busybox）。
4. 设置独立的资源限制：为 Init 容器显式声明 resources.requests 和 resources.limits，避免被用户容器抢占。

   initContainers:
     - name: init-migration
       image: myapp-init:latest
       resources:
         requests:
           memory: "128Mi"
           cpu: "100m"
         limits:
           memory: "256Mi"
           cpu: "200m"

5. 增加重试与超时控制：在 Init 容器脚本中加入重试逻辑（如 for i in 1 2 3; do ... && break; sleep 2; done），并设置合理的 activeDeadlineSeconds。
6. 测试 Init 容器独立运行：使用 kubectl run init-test --image=<init-image> --command -- <command> 单独测试 Init 容器逻辑。

4.4 综合排查清单

以下清单可作为 Pod 启动失败时的快速参考，按优先级排列：