引言

长期使用Kubernetes的用户可能遇到过许多错误，其中部分错误含义模糊。Kubernetes错误往往令人困扰，因此故障排查至关重要。一个简单的配置错误、缺失的环境变量或不足的资源，都可能导致整个程序故障，让团队陷入困惑。
Pod 与容器生命周期错误（Pod and Container Lifecycle Errors）
资源与调度错误（Resource and Scheduling Errors）
节点级错误（Node-Level Errors）
理解这些错误及其产生原因，比单纯解决错误更为重要。像OOMKilled、CrashLoopBackOff和ImagePullBackOff 这类错误，通常难以理解且修复复杂。 本文将教你如何排查Kubernetes常见错误确保Pod与集群平稳运行。
一、Pod 与容器生命周期错误

这类错误是Kubernetes中最常见的错误类型，因为它们直接影响应用的基础运行。如果 Pod 或容器发生故障，整个应用将无法使用。
这类错误的产生原因包括：
复杂的依赖关系（Complex dependencies）
资源限制（Resource constraints）
配置问题（Configuration problems）
镜像问题（Image issues）
通常情况下，当容器发生故障时，Kubernetes 会尝试自动重启容器。但如果存在基础性问题（如缺失配置），则会陷入循环：
容器启动 → 失败 → Kubernetes 重启 → 再次失败……（Container starts → Fails → Kubernetes restarts it → Fails again…）
Pod 与容器生命周期错误的常见示例包括：

1. CrashLoopBackOff错误 当Kubernetes反复尝试启动容器但均失败时，会触发此错误。最常见的原因包括：缺失环境变量、Dockerfile启动指令不当，或依赖问题导致应用无法连接数据库或服务。 如果应用使用的端口与其他应用冲突，也可能出现此问题。 如何修复Kubernetes中的CrashLoopBackOff错误 修复步骤首先是定位存在问题的Pod：运行 kubectl get pods 命令，查看所有 Pod 列表。 查看 Pod 日志以定位问题根源： kubectl logs pod-name –previous 通过以下命令获取更多详细信息： kubectl describe pod 如果问题是缺失环境变量，需更新Deployment 配置：运行kubectl edit deployment -n 命令，在编辑器中打开 Deployment 配置文件，在容器规格（container spec）下添加缺失的环境变量： spec: containers:
   • name: my-app image: my-image:latest env:
     • name: MY_ENV_VAR
       value: “my-value”
       如果容器需要更长的启动时间，需排查是否存在资源相关的崩溃问题：调整存活探针（liveness）、就绪探针（readiness）或启动探针（startup probes） 的配置，延迟健康检查时间。这样可避免 Kubernetes 在容器初始化完成前过早重启容器。
2. OOMKilled错误
   OOMKilled指容器因尝试使用超过Kubernetes允许的内存额度，而被强制终止的情况。当应用内存使用量超过Pod规格限制，或存在内存泄漏导致内存持续增长时，会触发此错误。
   将内存限制设置过低也可能导致该问题。例如，处理大型文件、缓存数据或管理大量并发请求等操作，均需要较多内存支持。
   如何修复Kubernetes中的OOMKilled错误
   首先，通过kubectl get pods命令定位被 OOMKilled的Pod，然后通过以下命令查看错误原因：
   kubectl describe pod
   监控运行中Pod的实时内存使用情况：
   kubectl top pod
   如果应用需要更多内存（这是 OOMKilled 错误的常见原因），需提高Deployment 的内存限制：
   containers:

• name: my-app
  image: my-image:latest
  resources:
  requests:
  memory: “256Mi” # 最低保证内存
  limits:
  memory: “512Mi” # 允许使用的最大内存
  3.ImagePullBackOff/ErrImagePull 错误
  这两个类似的错误均发生在Kubernetes无法下载容器镜像时。当Kubernetes重试拉取镜像时，会显示 ImagePullBackOff 错误；当首次拉取镜像失败时，则显示ErrImagePull 错误。
  常见原因包括：从私有镜像仓库拉取镜像时缺少认证凭据、镜像仓库中不存在指定镜像、镜像名称或标签错误，或网络无法访问镜像仓库。
  如何修复Kubernetes中的ImagePullBackOff/ErrImagePull错误
  首先，查看存在问题的Pod的错误信息。如果是私有镜像仓库认证问题，需创建Docker仓库密钥：
  kubectl createsecretdocker-registrymy-registry-secret\
  –docker-server=private-registry.com\
  –docker-username=myuser\
  –docker-password=mypassword\
  –docker-email=my@email.com
  然后在Deployment配置中引用该密钥：
  apiVersion: apps/v1
  kind:Deployment
  metadata:
  name:my-app
  spec:
  template:
  spec:
  imagePullSecrets:
  -name:my-registry-secret
  containers:
  -name:my-app
  image:private-registry.com/my-app:v1.2.3
  4.CreateContainerConfigError错误
  当配置错误时Kubernetes虽能拉取镜像，但无法创建容器。容器创建过程需配置环境变量、卷挂载、密钥（secrets）和配置映射（config maps），若这些配置引用出现问题，会触发此错误。
  如何修复Kubernetes中的CreateContainerConfigError错误
  通过kubectl describe pod 命令查看 Pod 描述，获取错误详情。验证所引用的密钥和配置映射是否存在：

列出当前命名空间下的所有密钥

kubectl get secrets

列出所有配置映射

kubectl get configmaps
如果密钥缺失，需创建密钥：
kubectl create secret generic my-secret \
–from-literal=DATABASE_PASSWORD=mypassword \
–from-literal=API_KEY=myapikey
若为配置映射问题，需创建配置映射：
kubectl create configmap my-config \
–from-literal=database.url=postgresql://localhost:5432/mydb # 直接指定值
–from-file=config.properties # 从文件导入
随后，验证Deployment或Pod的YAML 配置中引用是否正确：
envFrom:

• secretRef:
  name: my-secret
• configMapRef:
  name: my-config
  5.ContainerCannotRun/RunContainerError错误
  当 Kubernetes 成功创建容器，但无法运行其主进程时，会触发此错误。容器虽已存在，但无法执行命令或入口点（entrypoint）。与应用崩溃不同，此错误的核心是容器运行时无法启动进程。
  常见原因包括：缺失共享库或依赖项、可执行文件路径错误、可执行文件无执行权限，或 Pod 规格中入口点/命令语法错误。
  如何修复Kubernetes中的ContainerCannotRun/RunContainerError错误
  在相同镜像中启动调试终端：
  kubectl run debug-pod –image=my-app:latest -it –rm — /bin/sh
  在容器内部检查可执行文件：
  ls -la /app/myapp # 验证文件是否存在及是否有执行权限
  file /app/myapp # 确认二进制文件架构
  ldd /app/myapp # 检查是否缺失共享库
  如果是权限问题，需在 Dockerfile 中修复。
  二、资源与调度错误

资源不足或无合适节点运行Pod，会导致资源与调度错误。创建Pod时，Kubernetes调度器会检查集群中所有节点，根据资源需求和节点限制选择最优节点。
这类错误的棘手之处在于，它们通常反映的是集群基础性问题，而非单纯的配置问题。
1.挂起状态的Pod（Pending Pods）
当Kubernetes为Pod寻找运行节点时，Pod会处于“Pending”（挂起）状态。若无法找到合适节点，Pod 将一直保持此状态。
常见原因包括：CPU或内存资源不足、节点选择器（node selectors）或亲和性规则（affinity rules）与所有节点不匹配、持久卷声明（PersistentVolumeClaim）无法连接存储，或节点资源压力过大、存在未匹配容忍度的污点（taints），或节点被标记为不可调度。
如何修复Kubernetes中的挂起状态Pod
查看所有挂起状态的Pod及其挂起时长：
kubectl get pods –field-selector=status.phase=Pending
获取Pod无法调度的详细原因：
kubectl describe pod
若资源不足，可减少Pod的资源请求，或向集群中添加更多节点。

2. FailedScheduling错误 当调度器无法为Pod分配节点时，会显示FailedScheduling错误。与通用的“Pending”状态不同，此错误会提供调度失败的详细原因，便于问题修复。 如何修复Kubernetes中的FailedScheduling错误 查看事件日志，定位失败的确切原因： kubectl describe pod | grep -A3 Events 若为资源相关问题：调整Pod的资源请求（requests）或限制（limits），或添加更多节点。 若为约束相关问题：检查亲和性/反亲和性（affinity/anti-affinity）、节点选择器（node selectors）和容忍度（tolerations）配置。 若为污点问题：确保Pod配置了正确的容忍度： spec: tolerations:
   • key: “special-workload”
     operator: “Equal”
     value: “true”
     effect: “NoSchedule”
3. 被驱逐的Pod
   此错误最常见的原因是节点资源压力过大：当节点内存、磁盘空间或索引节点（inodes）不足时，Kubernetes会驱逐Pod，以防止节点变得不稳定。
   “被驱逐的Pod”指运行中的Pod被强制从节点移除。Kubernetes 会在驱逐Pod时终止该Pod，从而保护集群或节点。
   如何处理Kubernetes中的被驱逐Pod
   遇到此错误时，首先筛选被驱逐的Pod，并查看错误消息以确定原因：

筛选被驱逐的 Pod

kubectl get pods –field-selector=status.phase=Failed

查看“Message”字段，了解驱逐原因：

kubectl describe pod
若为资源不足导致，可通过以下命令检查节点资源压力：
kubectl describe node worker-node-1 | grep -A 10 Conditions:
随后监控资源使用情况，定位问题根源：

查看当前资源使用情况

kubectl top nodes
kubectl top pods –sort-by=memory
kubectl top pods –sort-by=cpu
三、节点级错误

节点级错误会影响集群中所有工作节点（而非仅单个Pod）。Pod 的正常运行依赖健康的节点，因此任何节点问题都会影响应用的调度、性能和可用性。

1. NodeNotReady错误
   此错误名称含义直观：表示集群工作节点健康检查失败，或停止响应控制平面。通常当kubelet崩溃、节点失去网络连接或系统崩溃时，kubelet会停止与控制平面通信，从而触发此错误。
   如何修复Kubernetes中的NodeNotReady错误
   查看未就绪的节点：
   kubectl get nodes
   若存在问题节点，通过以下命令获取详细信息：
   kubectl describe node
   验证节点上的 kubelet 是否正常运行。
   检查节点与控制平面之间的网络/域名系统（DNS）连接。
   若节点永久宕机：排空节点并删除该节点：
   kubectl drain –ignore-daemonsets –delete-emptydir-data
   kubectl delete node
2. DiskPressure/MemoryPressure错误
   当节点磁盘空间或内存不足时，Kubernetes会设置警告状态。即使节点仍在运行，Kubernetes也会限制相关操作，以防止系统故障。
   如何修复Kubernetes中的DiskPressure/MemoryPressure 问题
   定位存在资源压力的节点：
   kubectl get nodes -o wide
   kubectl describe node | grep -A 5 Conditions:
   通过清理未使用的镜像/容器释放磁盘空间。
   通过添加节点扩展集群。
   调整Pod的资源请求/限制，避免资源过度分配。
   若为内存问题：优化应用以减少内存使用，或增大节点规格。
3. NetworkUnavailable错误
   当节点网络故障，无法与集群其他节点或服务通信时，会触发此错误。此问题会导致该节点上的Pod无法与其他 Pod 通信。
   如何修复Kubernetes中的NetworkUnavailable错误
   检查CNI（容器网络接口）插件日志：CNI 插件故障也可能导致此错误。
   确保节点之间的必要端口已开放。
   重启kubelet和网络相关Pod。
   若仅单个节点受影响：检查该节点的网络接口。
   若 CNI 插件配置错误：重新应用或重新安装 CNI 插件。