一、本文概述及主要术语
1.1 概述
本文基于 Pod 、Service 和 Ingress 三大模块进行划分,对于 Kubernetes 日常可能出现的故障问题,提供了较为具体的排查步骤,并附上相关解决方法或参考文献。
1.2 主要术语
-
Pod: Kubernetes 中创建和管理的、最小的可部署的计算单元。是一组(一个或多个) 容器;这些容器共享存储、网络、以及怎样运行这些容器的声明。
-
Port-forward: 通过端口转发映射本地端口到指定的应用端口。
-
Service: 一个 Kubernetes 的 Service 是一种抽象,它定义了一组 Pods 的逻辑集合和一个用于访问它们的策略 - 有时被称为微服务。
-
Ingress: 提供了集群外部到内部 HTTP 和 HTTPS 服务的路由通信,流量路由通过 Ingress 资源上定义的规则控制。
二、故障诊断流程
2.1 Pods 模块检查
-
以下流程若成功则继续往下进行,若失败则根据提示进行跳转。
2.1.1 检查是否有 pod 处于 PENDING 状态
-
kubectl get pods:如果有 pod 处于 PENDING 状态则往下看,否则前往 2.1.5 。
[root@10-186-65-37 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-55b54d55b8-5msx8 0/1 Pending 0 5m
2 kubectl describe pod <pod-name>:若正确输出指定的一个或多个资源的详细信息,则判断是否集群资源不足,若不足则进行拓展,否则前往 2.1.2 。
2.1.2 检查是否触发 ResourceQuota limit
-
kubectl describe resourcequota -n <namespace>:
2 如有限制则进行相应资源释放或拓展,参考:https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources
否则前往 2.1.3
2.1.3 检查是否有 PVC 处于 PENDING 状态
-
持久卷(PersistentVolume,PV)是集群中的一块存储,可以由管理员事先供应,或者使用存储类(Storage Class)来动态供应;持久卷申领( PersistentVolumeClaim, PVC )表达的是用户对存储的请求。
-
kubectl describe pvc <pvc-name>:若 STATUS 为 Pending
则参考如下链接进行解决:https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/
否则前往 2.1.4 。
2.1.4 检查 pod 是否被分配至 node
-
kubectl get pods -o wide:若已被分配至 node
则是 Scheduler 方面的问题,参考如下链接进行解决:https://kubernetes.io/zh/docs/concepts/scheduling-eviction/kube-scheduler/
否则为 Kubectl 的问题。
2.1.5 检查是否有 pods 处于 RUNNING 状态
-
kubectl get pods -o wide:如果 pods 处于 RUNNING 状态则前往 2.1.10 ,否则前往 2.1.6 。
2.1.6 检查 pod 日志
-
kubectl logs <pod-name>:
若能正确获取日志则根据日志修复相关问题。
-
若无法获取日志则判断容器是否快速停止运行,若快速停止则执行:kubectl logs <pod-name> --previous
-
无法获取日志,且容器并非快速停止运行,则前往2.1.7
2.1.7 Pod 状态是否处于 ImagePullBackOff
-
kubectl describe pod <pod-name>:查看 status 是否为 ImagePullBackOff ?不为 ImagePullBackOff 则前往2.1.8 。
-
查看 image 名称是否正确,错误则修正。
-
查看 image tag 是否存在并经过验证。
-
是否从 private registry 拉取镜像?若是则确认配置信息正确。
-
若并非从 private registry 拉取镜像,问题可能出在 CRI(容器运行时接口) 或 kubectl 。
2.1.8 Pod 状态是否处于 CrashLoopBackOff
-
kubectl describe pod <pod-name>:查看 status 是否为 CrashLoopBackOff ?否则前往 2.1.9 。
-
若是则查看日志并修复应用程序崩溃。
-
确认是否遗漏了 Dockerfile 中的 CMD 指令?Docker history < image-id > (后可加 --no-trunc 显示完整输出)
-
Pod 状态是否频繁重启且状态处于 Running 和 CrashLoopBackOff 之间切换?若是则需修复 liveness probe(存活探测器)的问题,请参考如下链接:https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
2.1.9 Pod 状态是否处于 RunContainerError
-
kubectl describe pod <pod-name>:查看 status 是否为 RunContainerError 。
-
若状态为 RunContainerError 问题可能由于挂载卷 (volume) 导致,请参考如下链接:https://kubernetes.io/zh/docs/concepts/storage/volumes/
-
否则请在 StackOverflow 等网站寻求帮助。
2.1.10 检查是否有 pods 处于 READY 状态
-
若处于 READY 状态,则继续往下执行进行映射设置
若无处于 READY 状态的 pods 则前往 2.1.11 。
2. kubectl port-forward <pod-name> 8080:<pod-port>
3. 映射成功前往 2.2 。
a)进行映射
b)验证映射成功
失败则需确认程序可被所有地址监听,设置语句如下
若无法被所有地址监听则为未知状态(Unknown state)。
2.1.11 检查 Readiness(就绪探测器)
-
kubectl describe pod <pod-name>
-
正常输出则根据日志和参考如下链接修复相应问题 https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
-
失败则为未知状态(Unknown state)。
2.2 Service 模块检查
2.2.1 Service 当前状态检查
-
kubectl describe service <service-name> 成功输出如下
2 是否能看到 Endpoints 列且有正常输出?非正常输出则前往 2.2.2 。
3 kubectl port-forward service/<service-name> 8080:<service-port> 成功输出如下
4成功则前往 2.3 ,失败则前往 2.2.4 。
2.2.2 Selector 与 Pod label 比对
-
查看 pod 的 label 信息 kubectl describe pod <pod-name>
2 查看 service 的 selector 信息 kubectl describe service <service-name>
3 比对两者是否正确匹配,错误则进行修正,正确则前往 2.2.3 。
2.2.3 检查 Pod 是否已分配 IP
-
查看 pod 的 ip 信息 kubectl describe pod <pod-name>
-
已正确分配 ip ,则问题是由于 kubectl 导致。
3未分配 ip ,则问题是由于 Controller manager 导致。
2.2.4 检查 Service TargetPort 与 Pod ContainerPort
-
查看 service 的 TargetPort 信息: kubectl describe service <service-name>
2 查看 pod 的 ContainerPort 信息: kubectl describe pod <pod-name>
3 上方两者一致则问题是由于 kube-proxy 导致,不一致则进行信息修正。
2.3 Ingress 模块检查
2.3.1 Ingress 当前状态检查
-
kubectl describe ingress <ingress-name> 成功输出如下:
2 是否能看到 backends 列且有正常输出?正常输出前往 2.3.4 ,否则前往 2.3.2 。
2.3.2 检查 ServiceName 和 ServicePort
-
kubectl describe ingress <ingress-name>
-
kubectl describe service <service-name>
3 检查前两者的 ServiceName 和 ServicePort 书写是否正确,若正确则前往2.3.3,错误请修正。
2.3.3 Ingress controller 文档
-
问题是由于 Ingress controller 导致,请查阅文档寻找解决方法:https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
2.3.4检查 port-forward ingress
-
kubectl port-forward <ingress-pod-name> 8080:<ingress-port> 测试是否能正常访问:curl localhost:8080
可正常访问前往 2.3.5 ,否则前往 2.3.3 。
2.3.5 检查能否在外网通过 Ingress 进行访问
-
可从外网成功访问,故障排查结束。
-
若无法从外网访问,则问题是由于基础设施(infrastructure)或集群暴露(exposed)方式导致,请排查。
参考文献
故障分析 | Kubernetes 故障诊断流程 (qq.com)