Kubernetes中Deployment部署故障排除

Kubernetes中Deployment部署故障排除

字符型思维导图

  1. 排查pod状态(带标签):kubectl get pods,是否有等待处理的pod?
    1. 是?kubectl describe pod <pod-name>,集群资源是否已经爆满?
      1. 是?增加更多的磁盘资源
      2. 否?您是否达到ResourceQuota限制?
        1. 是?放宽ResourceQuota限制,修改pod的规格。
        2. 否?是否挂载了PersistentVolumeClaim(PVC)。
          1. 是?修复PersistentVolumeClaim(PVC)存储
          2. 否?kubectl get pods -o wide ,Pod是否已分配给节点
            1. 是?Kubelet可能存在问题,排查kubelet日志和状态
            2. 否?Scheduler可能存储问题,排查Scheduler进程状态和日志
    2. 否?Pod正在Running吗?
      1. 是?Pod准备好了吗?
        1. 是?kubectl port-forward <pod-name> 8080:<pod-port>,是否可以访问该应用程序吗?
          1. 是?Pod是运行正常的。可以检查一下Service应用,kubectl describe service <service-name>,检查是否可以看到Service对应的endpoints列表?
            1. 是?kubectl port-forward service/<service-name> 8080:<service-port>,现在可以访问该应用程序吗?
              1. 是?Service服务运行正常。检查kubectl describe ingress <ingress-name>,检查可以看到后端列表(backends)吗?
                1. 是?检查kubectl port-forward <ingress-pod-name> 8080:<ingress-port>,重新测试是否可以访问该应用程序吗?
                  1. 是?Ingress正常运行。该应用程序应该正在运行。 您可以尝试从公共互联网访问它看看?
                    1. 是?END检查结束.
                    2. 否?问题可能出在基础架构以及如何暴露集群端口上面(expose)
                  2. 否?这个问题特定于Ingress控制器。查阅相关Ingress文档
                2. 否?检查serviceName和servicePort是否与Service匹配?
                  1. 是?这个问题特定于Ingress控制器。查阅相关Ingress文档
                  2. 否?修改入口serviceName和servicePort问题。
              2. 否?服务上的targetPort是否与Pod中的containerPort相匹配?
                1. 是?问题可能出在Kube Proxy上。
                2. 否?修改Service服务targetPort和containerPort相同
            2. 否?检查规格选择器是否与正确的Pod标签匹配?
              1. 是?Kubelet存在问题,检查对应的进程日志。
              2. 否?修改为正确的规格选择器,使它与Pod标签匹配
          2. 否?检查容器暴露的端口是否正确并且正在监听0.0.0.0?
            1. 是?未知状态
            2. 否?检查这个容器应用,并且更正容器内端口
        2. 否?kubectl describe pod <pod-name>,检查一下准备就绪探针是否失败?
          1. 是?准备就绪探针是否失败?
          2. 否?未知错误
      2. 否?kubectl logs <pod-name>,可以查看该应用程序的日志详情
        1. 是?解决应用程序日志中的问题
        2. 否?看下是容器生存周期时间设置太短了吗?
          1. 是?kubectl logs <pod-name> --previous,输出pod中曾经运行过,但目前已终止的容器的日志,判断程序情况
          2. 否?kubectl describe pod <pod-name>,Pod状态为ImagePullBackOff(镜像拉取失败)状态吗?
            1. 是?可以先看下拉取镜像的名称是否正确?
              1. 是?看下镜像的标签是否正确?
              2. 否?修改为正确镜像的名称
                1. 是?看下是否从私有镜像仓库里面拉取镜像?
                2. 否?修改为正确的标签
                  1. 是?配置特定的私有仓库秘钥拉取私有仓库镜像
                  2. 否?问题可能出在CRI(容器运行时接口)或Kubelet程序
            2. 否?Pod状态为CrashLoopBackOff(崩溃循环状态)吗?
              1. 是?是否检查了日志并修复了崩溃的容器应用程序?
                1. 是?是否忘记了Dockerfile中的CMD指令?
                  1. 是?修改Dockerfile文件
                  2. 否?观察下Pod是否经常重启? 在Running和CrashLoopBackoff之间循环?
                    1. 是?修改一下livenessprobe(存活探针)
                    2. 否?未知状态
                2. 否?修复崩溃的应用
              2. 否?Pod状态为RunContainerError(运行容器错误)吗?
                1. 是?这个问题可能和挂载volume(卷)有关
                2. 否?查询下是否容器溢出问题

流程性思维导图

下图可帮助你调试Kubernetes Deployment。点击此处(https://kuboard.cn/statics/learning/troubleshooting-kubernetes.pdf)获取该图的PDF版本

猜你喜欢

转载自www.cnblogs.com/passzhang/p/12411556.html