Kubernetes：3步排查K8S Deployment故障

以你之姓@ 2023-07-10 05:22 45阅读 0赞

**目录**

Kubernetes中部署一个应用程序

3步排查K8S Deployment故障

1、 故障排查Pod

常见的Pod错误

启动错误包括：

运行时错误包括：

ImagePullBackOff

CrashLoopBackOff

RunContainerError

Pod处于Pending状态

Pod不处于Ready状态

2、 排查Service故障

3、 排查Ingress故障

调试Ingress Nginx

总 结

--------------------

# Kubernetes中部署一个应用程序 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][] Deployment故障排查思路

> Deployment故障排查思路
> 
>   
> **1. pod是pending状态**
> 
>  *  cluster full ? 
>  *  ResourceQuota? 
>  *  PVC pending? 
>  *  pod 是否调度到Node？Scheduler? Kubelet?
> 
> **2. pod不是running状态**
> 
>  *  kubectl logs 分析？还可以判断是否container quickly died?
>  *  ImagePullBackOff? - image name\\tag\\registry是否正确？
>  *  CrashLoopBackOff?-crashing app? Dockerfile-CMD？liveness prode?
> 
> **3. pod不是ready状态**
> 
>  *  Readiness probe?
> 
> **4. 不能访问app**
> 
>  *  端口？
>  *  endpoints? 
>  *  Service targetPort 是否可以和 containerPort匹配？
>  *  Igress-serviceName和servicePort是否和Service匹配？

在Kubernetes中部署一个应用程序，你通常需要定义三个组件：

>  *  Deployment——这是创建名为Pods的应用程序副本的方法
>  *  Serivce——内部负载均衡器，将流量路由到Pods
>  *  Ingress——可以描述流量如何从集群外部流向Service

现在，我们来快速回顾一下什么端口和标签需要匹配：

> 1.  Service selector应该匹配Pod的标签
> 2.  Service`targerPort`应该匹配在Pod内容器的`containerPort`
> 3.  Service 端口可以是任意数字。多个Service可以使用同个端口，因为它们已经分配了不同的IP地址
> 4.  Ingress的`servicePort`应该匹配在Service中的port
> 5.  Service的名称应该匹配在Ingress中的`serviceName`的字段

了解如何构造YAML只是开始。那么，出了问题时会有什么表现？Pod可能无法启动，或者直接崩溃。

# 3步排查K8S Deployment故障 #

在我们深入研究有故障的deployment之前，必须有一个明确定义的模型，以了解Kubernetes的工作方式。

既然在每个deployment中都有那三个组件，你应该从底层开始按顺序调试它们。

> 1.  你应该确保你的Pod正在运行
> 2.  着重关注使Service将流量路由到Pod
> 3.  检查Ingress是否正确配置

*  你应该从底层开始排查Deployment故障。首先，检查Pod是否准备就绪并且正在运行
 *  如果Pod已经准备就绪，你需要检查Service是否可以将流量分配到Pod。
 *  最后你应该检查Service和Ingress之间的连接。

# 1、 故障排查Pod #

在大多数情况下，问题出现在Pod本身。所以你应该确保Pod正在运行并准备就绪。应该如何检查呢？

kubectl get pods
    NAME                    READY STATUS            RESTARTS  AGE
    app1                    0/1   ImagePullBackOff  0         47h
    app2                    0/1   Error             0         47h
    app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

以上部分，只有最后一个Pod是正在运行并且准备就绪的，而前两个Pod既没有Running也没有Ready。那么，你应该如何定位是什么出了问题呢？

这里有4个十分有用的命令可以帮助你排查Pod的故障：

>  *  `kubectl logs <pod name>`能够帮助检索Pod的容器日志
>  *  `kubectl describe pod <pod name>`能够有效地检索与Pod相关的事件列表
>  *  `kubectl get pod <pod name>`对于提取存储在Kubernetes中的Pod的YAML定义十分有用
>  *  `kubectl exec -ti <pod name> bash`可以用于在Pod其中一个容器中运行一个交互式命令

你应该使用哪一个呢？实际上，没有一种命令是万能的，你可以根据实际情况结合使用。

## 常见的Pod错误 ##

> Pod可能会出现启动和运行时的错误。

## 启动错误包括： ##

>  *  ImagePullBackoff
>  *  ImageInspectError
>  *  ErrImagePull
>  *  ErrImageNeverPull
>  *  RegistryUnavailable
>  *  InvalidImageName

## 运行时错误包括： ##

>  *  CrashLoopBackOff
>  *  RunContainerError--判断是否PVC问题？
>  *  KillContainerError
>  *  VerifyNonRootError
>  *  RunInitContainerError
>  *  CreatePodSandboxError
>  *  ConfigPodSandboxError
>  *  KillPodSandboxError
>  *  SetupNetworkError
>  *  TeardownNetworkError

这些错误中，有些比其他错误更为常见。以下是最常见的错误以及如何修复它们：

## ImagePullBackOff ##

当Kubernetes无法检索Pod其中之一的容器镜像时，将出现此错误。

有三种常见原因：

>  *  镜像名称无效——例如，你错误拼写名称或镜像不存在
>  *  你给这一镜像指定了一个不存在的tag
>  *  你所检索的镜像是私有仓库的，并且Kubernetes没有访问它的凭据

前两个原因可以通过更正镜像名称和tag解决。最后一个，你需要将凭据添加到“Secret”中的私有镜像仓库中，并在Pod中引用它。

官方文档可以让你更加清楚：

[https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/][https_kubernetes.io_docs_tasks_configure-pod-container_pull-image-private-registry]

## CrashLoopBackOff ##

如果容器无法启动，Kubernetes状态将显示CrashLoopBackOff消息。

通常情况下，容器在以下场景中无法启动：

>  *  应用程序中存在错误，导致无法启动
>  *  你错误配置了容器 [https://stackoverflow.com/questions/41604499/my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo][https_stackoverflow.com_questions_41604499_my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo] --- **The pod is crashing because it starts up then immediately exits, thus Kubernetes restarts and the cycle continues.**
>  *  Liveness探针失败次数太多

你应该尝试并检索该容器的日志以确定出现故障的原因。

**如果由于你的容器重启过快而无法查看日志，你可以使用以下命令：**

kubectl logs <pod-name> --previous

它将从之前的容器中打印错误信息。

## RunContainerError ##

容器不能启动时出现错误，甚至在容器内的应用程序启动之前就无法启动。

这个问题通常由于错误配置导致的，如：

>  *  安装一个不存在的volume，如ConfigMap或Secret
>  *  将只读volume安装为可读写

你应该使用`kubectl describe pod <pod-name>`来收集和分析错误。

## Pod处于Pending状态 ##

当你创建一个Pod时，Pod保持在Pending状态。这是为什么呢？假设你的调度组件运行了解，那么有以下几个原因：

>  *  集群没有足够的资源来运行Pod，如CPU和内存
>  *  当前命名空间有一个ResourceQuota对象并且所创建的Pod会使该命名空间超过资源额度
>  *  Pod与一个Pending状态的PersistentVolumeClaim绑定。

那么，最好的选择是使用命令`kubectl describe`检查事件：

kubectl describe pod <pod name>

对于由于ResourceQuotas造成的错误，可以使用以下方法检查集群的日志：

kubectl get events --sort-by=.metadata.creationTimestamp

## Pod不处于Ready状态 ##

如果Pod正在运行但是不Ready，这意味着**Readiness探针出现故障**。当Readiness探针出现故障时，Pod无法附加到Service上，并且流量无法转发到实例上。

Readiness探针故障是特定于应用程序的错误，因此使用`kubectl describe`来检查事件部分，以验证错误。

# 2、 排查Service故障 #

如果你的Pod正在运行并且准备就绪，但是你依旧无法接收来自应用程序的响应，你应该检查Service是否配置正确。

Service旨在根据pod的标签将流量路由到Pod。所以第一件事，你需要检查Service target多少个Pod。可以通过**检查Service中的Endpoint来完成此步骤：**

kubectl describe service <service-name> | grep Endpoints

> 一个endpoint是一对`<ip address:port>`\`，并且当Service（至少）target一个pod时。至少有一对。

如果“Endpoint”部分是空的，那么有两种解释：

> 1.  任何正在运行的Pod没有正确的label（提示：你需要检查以下你是否在正确的命名空间内）
> 2.  在Service的selector标签中有错别字

如果你看到了endpoint列表，但依旧无法访问你的应用程序，**那么你的Service中的`targetPort`可能是罪魁祸首**。

**你应该怎么测试Service？无论Service类型是什么，都可以使用`kubectl port-forward`连接到它：**

kubectl port-forward service/<service-name> 3000:80

其中：

>  *  `<service-name>`是Service的名称
>  *  `3000`是你想要在电脑上打开的端口
>  *  `80`是由Service暴露的端口

# 3、 排查Ingress故障 #

如果你走到了这个部分，这意味着：

>  *  Pod正在运行并且准备就绪
>  *  Service可以分发流量给Pod

但你依旧无法接收app的响应。那么这很有可能是**Ingress配置出现错误**。

由于使用的Ingress controller是集群中的第三方组件，那么根据Ingress controller的类型会由不同的调试技术。但是在深入研究Ingress特定的工具之前，你可以使用一些简单的方法检查。

Ingress使用`serviceName`和`servicePort`连接Service。你应该检查那些是否正确配置。你可以使用以下命令检查Ingress是否正确配置：

kubectl describe ingress <ingress-name>

**如果*Backend*列是空的，那么配置中肯定存在错误。**

如果你能在*Backend*列中看到endpoint，但依旧无法访问应用程序，那么可能是以下问题：

>  *  你将Ingress暴露于公网的方式
>  *  你将集群暴露于公网的方式

你可以通过直接连接到Ingress Pod将基础设施问题与Ingress隔离开来。

首先，为你的Ingress Controller检索Pod（可能位于不同的命名空间中）：

kubectl get pods --all-namespaces
    NAMESPACE   NAME                              READY STATUS
    kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
    kube-system etcd-minikube                     1/1   Running
    kube-system kube-apiserver-minikube           1/1   Running
    kube-system kube-controller-manager-minikube  1/1   Running
    kube-system kube-proxy-zvf2h                  1/1   Running
    kube-system kube-scheduler-minikube           1/1   Running
    kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

描述它以检索端口：

kubectl describe pod nginx-ingress-controller-6fc5bcc
     --namespace kube-system \
     | grep Ports

最后，连接到Pod：

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

**此时，每次你在电脑上访问端口3000，请求将会转发到Pod上的端口80。**

那么，现在能够正常运行了吗？

如果正常工作，问题就出在基础设施。你应该检查流量如何路由到你的集群。

如果无法正常工作，问题就在Ingress controller。你应该调试Ingress。

如果仍然无法使Ingress controller正常工作，则应该开始对其进行调试。市场有许多不同版本的Ingress controller。比较流行的包括Nginx、HAProxy、Traefik等。

你应该查阅Ingress controller的文档以查找故障排查指南。

既然Ingress Nginx是最流行的Ingress controller，那么在下一个部分我们将介绍一些相关的技巧。

## 调试Ingress Nginx ##

Ingress-nginx有kubectl的官方插件，你可以访问以下网址查看：

> [https://kubernetes.github.io/ingress-nginx/kubectl-plugin/][https_kubernetes.github.io_ingress-nginx_kubectl-plugin]

你可以使用`kubectl ingress-nginx`来进行以下操作：

>  *  检查日志、Backend、证书等
>  *  连接到Ingress
>  *  检查当前的配置

你还可以尝试以下三个命令：

>  *  `kubectl ingress-nginx lint`这是用来检查`nginx.conf`
>  *  `kubectl ingress-nginx backend`来检查*Backend*（与`kubectl describe ingress <ingress-name>`类似）
>  *  `kubectl ingress-nginx logs`来检查日志

请注意，你需要使用`--namespace <name>`来指定正确的命名空间。

# 总 结 #

如果你毫无头绪，那么在Kubernetes中进行故障排除可能是一项艰巨的任务。

你应该永远记住以从下至上的顺序解决问题：**现检查Pod，然后向上移动堆栈至Service和Ingress。**

而本文中的debug技术在其他地方也是通用的，例如：

>  *  出现故障的Jobs和CronJobs
>  *  StatefulSets和DaemonSets

原文链接：[https://learnk8s.io/troubleshooting-deployments][https_learnk8s.io_troubleshooting-deployments]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200229185908211.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ==,size_16,color_FFFFFF,t_70
[https_kubernetes.io_docs_tasks_configure-pod-container_pull-image-private-registry]: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
[https_stackoverflow.com_questions_41604499_my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo]: https://stackoverflow.com/questions/41604499/my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo
[https_kubernetes.github.io_ingress-nginx_kubectl-plugin]: https://kubernetes.github.io/ingress-nginx/kubectl-plugin/
[https_learnk8s.io_troubleshooting-deployments]: https://learnk8s.io/troubleshooting-deployments