超长可视化指南！带你理清K8S部署的故障排查思路，让bug无处遁形

时间 2020-02-27

标签可视化指南理清 k8s 部署故障排查思路 bug 无处遁形繁體版

原文原文链接

本文将帮助你厘清在Kubernetes中调试 deployment的思路。下图是完整的故障排查思路，若是你想得到更清晰的图片，请在公众号后台（RancherLabs）回复“troubleshooting”。

当你但愿在Kubernetes中部署一个应用程序，你一般须要定义三个组件：nginx

Deployment——这是建立名为Pods的应用程序副本的方法git
Serivce——内部负载均衡器，将流量路由到Podsgithub
Ingress——能够描述流量如何从集群外部流向Serviceapi

接下来，咱们经过图片快速回顾一下。

在Kubernetes中，你的应用程序经过两层负载均衡器暴露：内部和外部。

内部负载均衡器称为Service，而外部负载均衡器则称为Ingress。

Pod未直接部署，所以，Deployment建立Pod并监视它们。安全

假设你想部署一个简单的Hello World应用程序，那么对于此类应用程序，其YAML文件与如下相似：
bash

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

这个定义很长，容易忽略组件之间的相互关系。app

例如：
负载均衡

你何时应该使用80端口，何时使用端口8080？ide
你是否应该为每一个服务建立一个新端口，以避免它们冲突？工具
标签（label）名称重要吗？是否应该每一处都同样？

在进行debug以前，咱们先来回顾一下这三个组件之间的关系如何。

首先，咱们从Deployment和Service开始。

链接Deployment和Service

实际上，Deployment和Service根本没有链接。相反，该Service直接指向Pod，并彻底跳过Deployment。因此，你应该关注的是Pod和Service是如何与彼此关联的。你应该记住三件事：

Service selector至少与Pod的一个标签匹配
Serivce targetPort应该与Pod内的容器的containerPort相匹配
Serviceport能够是任何数字。多个Service可使用同一个端口，由于它们已经被分配了不一样的IP地址

如下图片总结了如何链接端口：

考虑由Service暴露的pod

当你建立一个pod，你应该在你的Pod中为每一个容器定义端口containerPort

当你建立一个Service时，你可以定义一个port和一个targetPort。但你应该将哪个链接到容器呢？

targetPort与containerPort应该可以匹配

若是你的容器暴露端口3000，那么targetPort应该与该数字相匹配。

若是你查看了YAML，标签与ports或targerPort应该匹配：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app

那么在Deployment顶部的track: canary标签呢？也应该匹配吗？

那个标签属于deployment，而且Service selector不使用它来路由流量。换言之，你能够安全地将其移除或者给它分配不一样的值。

那么matchLabelsselector呢？它须要与Pod标签匹配而且Deployment使用它来跟踪Pod。

假设你作了一个正确的更改，你应该如何测试它呢？你可使用如下命令检查Pod是否拥有正确的标签：

kubectl get pods --show-labels

或者若是你有属于多个应用程序的Pod：

kubectl get pods --selector any-name=my-app --show-labels

其中any-name=my-app是标签any-name: my-app。依旧存在问题？你也能够链接到Pod。你能够在kubectl中使用命令port-forward链接到Serivce并测试链接。

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

其中：

service/<service name>是serivce的名称——在当前YAML中，是“my-service”。
3000是你但愿在你的电脑上打开的端口
80是Service在port字段中暴露的端口

若是你可以链接，那么设置就是正确的。若是你没法链接，你颇有可能弄错了标签或者端口未匹配。

链接Service和Ingress

暴露应用程序的下一步是配置Ingress。Ingress必须知道如何检索Service，而后检索Pod并将流量路由到它们。Ingress经过名称和暴露的端口来检索正确的Service。

在Ingress和Service中应该匹配两件事：

Ingress的servicePort应该与Service的port匹配
Ingress的serviceName应该与Service的name相匹配

如下图片将总结如何链接端口：

你已经知道该服务暴露了一个端口

Ingress有一个名为servicePort的字段。

Serviceport和IngressservicePort应该相匹配

若是你决定分配端口80给该service，你应该同时更改servicePort为80

实际操做中，你须要查看这些命令行：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: my-service
        servicePort: 80
      path: /

你应该如何测试Ingress是否正常运行呢？你可使用和以前相同的策略，即kubectl port-forward，但不是链接到service，而是链接到Ingress controller。

首先，使用如下命令为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

验证Ingress Pod（可能在不一样的命名空间）而且描述它以检索端口：

kubectl describe pod nginx-ingress-controller-6fc5bcc \
 --namespace kube-system \
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最后，链接到Pod：

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

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

若是你访问 http://localhost:3000 ，你应该能找到提供网页的应用程序。

简单回顾一下

如今，咱们来快速回顾一下什么端口和标签须要匹配：

Service selector应该匹配Pod的标签
ServicetargerPort应该匹配在Pod内容器的containerPort
Service 端口能够是任意数字。多个Service可使用同个端口，由于它们已经分配了不一样的IP地址
Ingress的servicePort应该匹配在Service中的port
Service的名称应该匹配在Ingress中的serviceName的字段

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

3步排查K8S Deployment故障

在咱们深刻研究有故障的deployment以前，必须有一个明肯定义的模型，以了解Kubernetes的工做方式。

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

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

你应该从底层开始排查Deployment故障。首先，检查Pod是否准备就绪而且正在运行

若是Pod已经准备就绪，你须要检查Service是否能够将流量分配到Pod。

最后你应该检查Service和Ingress之间的链接。

一、故障排查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
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/

CrashLoopBackOff

若是容器没法启动，Kubernetes状态将显示CrashLoopBackOff消息。

一般状况下，容器在如下场景中没法启动：

应用程序中存在错误，致使没法启动
你错误配置了容器

https://stackoverflow.com/questions/41604499/my-kubernetes-pods-keep-crashing-with-crashloopbackoff-but-i-cant-find-any-lo
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来检查事件部分，以验证错误。

二、排查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”部分是空的，那么有两种解释：

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

若是你看到了endpoint列表，但依旧没法访问你的应用程序，那么你的Service中的targetPort多是罪魁祸首。

你应该怎么测试Service？不管Service类型是什么，均可以使用kubectl port-forward链接到它：

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

其中：

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

三、排查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/

你可使用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

但愿你们都没有bug！