Kubernetes问题诊断之诊断应用程序

诊断问题的第一步是区分是Pod的问题、Deployment（StatefulSet/DaemonSet）控制器的问题，还是Service的问题

🚨【阿里云限时特惠】云产品低至38元/年起！🎉

各位技术伙伴，阿里云爆款钜惠来袭！立即抢购：阿里云特惠 💰

🔥 新人专享特惠

200M带宽云服务器
38元/年起（官网价￥459元/年），立省421元！
✔️ 适用场景：网站搭建/Web应用/电商独立站

经济型e实例
续费99元/年 | 2核2G + 3M带宽 + 40G ESSD云盘
✔️ 含防病毒版安全防护（防勒索/挖矿/木马）
✔️ 限新用户，每人限购1台

🤖 AI大模型特惠

DeepSeek R1大模型
首年99元起 | 1.5B/7B参数规格
✔️ 支持宝塔面板一键部署
✔️ 数学/代码/推理任务表现出色

企业知识库应用
数据库+文件存储+多端支持
✔️ 低代码扩展 + 钉钉/企微/微信集成

Debugging Pods

怀疑Pod碰到问题时，先看一下Pod的完整描述 , 执行如下语句可以查看到Pod最新的状态以及最近关联的事件 :

kubectl describe pods ${POD_NAME}

输出:

# Pod 基础信息
Name:           nginx-deployment-5754944d6c-d8hs8  # Pod 名称（包含 Deployment 名称和哈希值）
Namespace:      default                             # 所属命名空间（默认 default）
Priority:       0                                   # 优先级（0 表示未设置优先级类）
Node:           demo-worker002/172.17.216.82        # 所在节点名称和 IP
Start Time:     Wed, 02 Oct 2019 22:36:19 +0800     # 创建时间（UTC+8）

# 标识与元数据
Labels:                                             # 标签（用于资源选择）
  app=nginx                                         # 应用标识标签
  pod-template-hash=5754944d6c                      # 控制器生成的哈希标签（用于滚动更新）
Annotations:                                        # 注解（存储扩展元数据）
  cni.projectcalico.org/podIP: 192.168.15.129/32    # Calico CNI 分配的 Pod IP

# 运行状态
Status:         Running                             # Pod 状态（Running/Error/Pending 等）
IP:             192.168.15.129                      # Pod 集群内部 IP
Controlled By:  ReplicaSet/nginx-deployment-5754944d6c  # 所属控制器（ReplicaSet）

# 容器配置
Containers:
  nginx:                                            # 容器名称
    Container ID:   docker://70b70667e082d6b4cbc7ab7a5fba33c2fa93509e08794658fde9ad9ac04a0327  # 容器运行时 ID
    Image:          nginx:1.7.9                     # 使用的镜像
    Image ID:       docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451  # 镜像摘要
    Port:           80/TCP                          # 容器暴露端口
    Host Port:      0/TCP                           # 节点映射端口（0 表示未启用）
    State:          Running                         # 容器状态（Running/Waiting/Terminated）
      Started:      Wed, 02 Oct 2019 22:36:22 +0800 # 容器启动时间
    Ready:          True                            # 就绪状态（通过 Readiness Probe 检测）
    Restart Count:  0                               # 重启次数（0 表示未重启）
    Environment:    <none>                          # 环境变量（未设置）
    Mounts:                                         # 存储卷挂载
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-s6znq (ro)  # 自动挂载的 ServiceAccount 令牌

# Pod 状态条件
Conditions:                                         # 状态条件（系统级诊断）
  Type              Status
  Initialized       True   # 初始化容器已完成
  Ready             True   # 已就绪可接收流量
  ContainersReady   True   # 所有容器已就绪
  PodScheduled      True   # 已成功调度到节点

# 存储卷配置
Volumes:                                            # 存储卷定义
  default-token-s6znq:                             # 卷名称（自动生成的 Secret）
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-s6znq                # 引用的 Secret 名称
    Optional:    false                              # 是否为可选卷

# 资源管理
QoS Class:       BestEffort                         # 服务质量等级（无资源限制）
Node-Selectors:  <none>                             # 节点选择器（未设置）
Tolerations:                                        # 污点容忍配置
  node.kubernetes.io/not-ready:NoExecute for 300s   # 容忍节点未就绪状态
  node.kubernetes.io/unreachable:NoExecute for 300s # 容忍节点不可达状态

# 事件日志
Events:          <none>                             # 近期事件（无异常事件）

查看Pod中容器的状态：是否所有的容器都处于 Running 状态？是否近期有重启过？

Pod是Pending状态

意味着该 Pod 不能被调度到某一个节点上,通常，这是因为集群中缺乏足够的资源或者 合适 的资源。

上述 kubectl describe... 命令的输出中的 Events 字段，会有对应的事件描述为什么 Pod 不能调度到节点上 。 可能的原因有：

资源不就绪 : 创建 Pod 时 , Pod 可能依赖集群中的其他资源（如 ConfigMap、PersistentVolumeClaim (PVC) 等）。若这些资源未就绪，Pod 将无法调度。 例如:

Type     Reason            Age        From               Message
----     ------            ----       ----               -------
Warning  FailedScheduling  <unknown>  default-scheduler  pod has unbound immediate PersistentVolumeClaims (repated 2 times)

缺乏足够的资源 : 可能集群中的CPU或内存都已经耗尽 ,此时可以尝试:

查看节点资源状态
– 使用 kubectl top nodes 查看各节点的 CPU 和内存实时使用率，识别资源紧张的节点
– 通过 kubectl describe node 检查节点的 Conditions 字段，已关注 MemoryPressure 或 DiskPressure 警告

分析 Pod 资源消耗
– 运行 kubectl top pods --all-namespaces 按资源使用量排序，找出高负载的 Pod
– 结合 kubectl describe pod 查看 Pod 的事件日志，确认是否因资源不足被驱逐（如 OOMKilled 或 Evicted）

该Pod使用hostPort : 当Pod使用 hostPort 时，该Pod可以调度的地方就比较有限。 hostPort 会将容器端口直接绑定到宿主机的特定端口（如 80 端口）。由于同一节点的同一端口只能被一个进程占用 。 若节点上的 hostPort 被其他程序（包括非 Kubernetes 管理的进程）占用，Pod 将无法调度到该节点 。例如，若某节点已运行占用 80 端口的服务，则所有需绑定 hostPort:80 的 Pod 均无法调度至此节点

污点和容忍：

Pod是Wating状态

此时该 Pod 已经被调度到某个节点上了，但是却不能运行。

查看Pod事件及状态

执行以下命令获取详细信息：

kubectl describe pod <pod-name>  # 查看Events字段中的错误提示
kubectl get pod <pod-name> -o yaml  # 检查镜像、资源请求等配置

检查容器日志

若容器已启动但异常退出

kubectl logs <pod-name> -c <container-name>  # 查看当前日志
kubectl logs --previous <pod-name> -c <container-name>  # 查看历史崩溃日志

若为Init容器问题

kubectl logs <pod-name> -c <init-container-name>

验证镜像拉取

登录Pod所在节点，手动执行docker pull ，确认镜像可拉取

检查节点网络连通性（如防火墙、代理设置）及镜像仓库权限

Pod是Crash或者Unhealthy

通常是容器中应用程序的问题

通过 kubectl logs 直接获取容器的实时日志，快速定位应用错误：

kubectl logs ${POD_NAME} -c ${CONTAINER_NAME}

若容器已重启多次，使用 --previous 参数获取上一次崩溃的日志：

kubectl logs --previous ${POD_NAME} -c ${CONTAINER_NAME}

Kubernetes 会保留最近退出的容器日志（存储在节点 /var/log/pods/ 目录下的链接文件 )

Pod是Running状态，但是不工作

通常是由于YAML配置文件中的非致命错误导致实际配置与预期不符

🚨【阿里云限时特惠】云产品低至38元/年起！🎉

各位技术伙伴，阿里云爆款钜惠来袭！立即抢购：阿里云特惠 💰

🔥 新人专享特惠

200M带宽云服务器
38元/年起（官网价￥459元/年），立省421元！
✔️ 适用场景：网站搭建/Web应用/电商独立站

经济型e实例
续费99元/年 | 2核2G + 3M带宽 + 40G ESSD云盘
✔️ 含防病毒版安全防护（防勒索/挖矿/木马）
✔️ 限新用户，每人限购1台

🤖 AI大模型特惠

DeepSeek R1大模型
首年99元起 | 1.5B/7B参数规格
✔️ 支持宝塔面板一键部署
✔️ 数学/代码/推理任务表现出色

企业知识库应用
数据库+文件存储+多端支持
✔️ 低代码扩展 + 钉钉/企微/微信集成