Kubernetes Deployment故障排除图解指南

崔文亮 發表於 2019-12-10 09:34:00

Kubernetes Deployment故障排除图解指南

<div class="post-content">
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-1.png" alt="img{512x368}">
<hr>
 
下面是一个示意图，可帮助你调试Kubernetes Deployment（你可以在此处下载它的PDF版本）。
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-2.png" alt="img{512x368}">
当你希望在Kubernetes中部署应用程序时，你通常会定义三个组件：
<ul>
<li>一个Deployment – 这是一份用于创建你的应用程序的Pod副本的”食谱”；</li>
<li>一个Service – 一个内部负载均衡器，用于将流量路由到内部的Pod上；</li>
<li>一个Ingress – 描述如何流量应该如何从集群外部流入到集群内部的你的服务上。</li>
</ul>
 
下面让我们用示意图快速总结一下要点。
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-3.png" alt="img{512x368}">
<center>在Kubernetes中，你的应用程序通过两层负载均衡器暴露服务：内部的和外部的</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-4.png" alt="img{512x368}">
<center>内部的负载均衡器称为Service，而外部的负载均衡器称为Ingress</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-5.png" alt="img{512x368}">
<center>Pod不会直接部署。Deployment会负责创建Pod并管理它们</center>
 
 
假设你要部署一个简单的”HelloWorld”应用，该应用的YAML文件的内容应该类似下面这样：
<pre><code>// hello-world.yaml

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: /

</code></pre>
 
这个定义很长，组件之间的相互关系并不容易看出来。
例如：
<ul>
<li>什么时候应使用端口80，又是何时应使用端口8080？</li>
<li>你是否应该为每个服务创建一个新端口以免它们相互冲突？</li>
<li>标签(label)名重要吗？它们是否在每一处都应该是一样的？</li>
</ul>
在进行调试之前，让我们回顾一下这三个组件是如何相互关联的。
让我们从Deployment和Service开始。
<h2> </h2>
<h2>一. 连接Deployment和Service</h2>
令人惊讶的消息是，Service和Deployment之间根本没有连接。
事实是：Service直接指向Pod，并完全跳过了Deployment。
因此，你应该注意的是Pod和Service之间的相互关系。
你应该记住三件事：
<ul>
<li>Service selector应至少与Pod的一个标签匹配；</li>
<li>Service的targetPort应与Pod中容器的containerPort匹配；</li>
<li>Service的port可以是任何数字。多个Service可以使用同一端口号，因为它们被分配了不同的IP地址。</li>
</ul>
下面的图总结了如何连接端口：
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-6.png" alt="img{512x368}">
<center>考虑上面被一个服务暴露的Pod</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-7.png" alt="img{512x368}">
<center>创建Pod时，应为Pod中的每个容器定义containerPort端口</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-8.png" alt="img{512x368}">
<center>当创建一个Service时，你可以定义port和targetPort，但是哪个用来连接容器呢？</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-9.png" alt="img{512x368}">
<center>targetPort和containerPort应该始终保持匹配</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-10.png" alt="img{512x368}">
<center>如果容器暴露3000端口(containerPort)，那么targetPort应该匹配这一个端口号</center>
 
 
再来看看YAML，标签和ports/targetPort应该匹配：
<pre><code>// hello-world.yaml

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
</code></pre>
那deployment顶部的track: canary标签呢?
它也应该匹配吗？
该标签属于deployment，service的选择器未使用它来路由流量。
换句话说，你可以安全地删除它或为其分配其他值。
那matchLabels选择器呢？
它必须始终与Pod的标签匹配，并且被Deployment用来跟踪Pod。
假设你已经进行了所有正确的设置，该如何测试它呢？
你可以使用以下命令检查Pod是否具有正确的标签：
<pre><code>$ kubectl get pods --show-labels
</code></pre>
或者，如果你拥有属于多个应用程序的Pod：
<pre><code>$ kubectl get pods --selector any-name=my-app --show-labels
</code></pre>
any-name=my-app就是标签：any-name: my-app。
还有问题吗？
你也可以连接到Pod！
你可以使用kubectl中的port-forward命令连接到service并测试连接。
<pre><code>$ kubectl port-forward service/<service name> 3000:80
</code></pre>
<ul>
<li>service/ 是服务的名称- 在上面的YAML中是“my-service”</li>
<li>3000是你希望在计算机上打开的端口</li>
<li>80是service通过port字段暴露的端口</li>
</ul>
如果可以连接，则说明设置正确。
如果不行，则很可能是你填写了错误的标签或端口不匹配。
<h2> </h2>
<h2>二. 连接Service和Ingress</h2>
接下来是配置Ingress以将你的应用暴露到集群外部。
Ingress必须知道如何检索服务，然后检索Pod并将流量路由给它们。
Ingress按名字和暴露的端口检索正确的服务。
在Ingress和Service中应该匹配两件事：
<ul>
<li>Ingress的servicePort应该匹配service的port；</li>
<li>Ingress的serviceName应该匹配服务的name。</li>
</ul>
下面的图总结了如何连接端口：
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-11.png" alt="img{512x368}">
<center>你已经知道servive暴露一个port</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-12.png" alt="img{512x368}">
<center>Ingress有一个字段叫servicePort</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-13.png" alt="img{512x368}">
<center>service的port和Ingress的service应该始终保持匹配</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-14.png" alt="img{512x368}">
<center>如果你为service指定的port是80，那么你也应该将ingress的servicePort改为80</center>
 
实践中，你应该查看以下几行(下面代码中的my-service和80)：
<pre><code>// hello-world.yaml

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: /
</code></pre>
你如何测试Ingress是否正常工作呢？
你可以使用与以前相同的策略kubectl port-forward，但是这次你应该连接到Ingress控制器，而不是连接到Service。
首先，使用以下命令检索Ingress控制器的Pod名称：
<pre><code>$ 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-minikube1/1 Running
kube-system kube-proxy-zvf2h 1/1 Running
kube-system kube-scheduler-minikube 1/1 Running
kube-system nginx-ingress-controller-6fc5bcc1/1 Running
</code></pre>
标识Ingress Pod（可能在其他命名空间中）并描述它以检索端口：
<pre><code>$ kubectl describe pod nginx-ingress-controller-6fc5bcc \
--namespace kube-system \
| grep Ports
Ports: 80/TCP, 443/TCP, 18080/TCP
</code></pre>
最后，连接到Pod：
<pre><code>$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system
</code></pre>
此时，每次你访问计算机上的端口3000时，请求都会转发到Ingress控制器Pod上的端口80。
如果访问http://localhost:3000，则应找到提供网页服务的应用程序。
<h3>回顾Port</h3>
快速回顾一下哪些端口和标签应该匹配：
<ul>
<li>service selector应与Pod的标签匹配</li>
<li>service的targetPort应与Pod中容器的containerPort匹配</li>
<li>service的端口可以是任何数字。多个服务可以使用同一端口，因为它们分配了不同的IP地址。</li>
<li>ingress的servicePort应该匹配service的port</li>
<li>serivce的名称应与ingress中的serviceName字段匹配</li>
</ul>
知道如何构造YAML定义只是故事的一部分。
出了问题后该怎么办？
Pod可能无法启动，或者正在崩溃。
<h2> </h2>
<h2>三. kubernetes deployment故障排除的3个步骤</h2>
在深入研究失败的deployment之前，我们必须对Kubernetes的工作原理有一个明确定义的思维模型。
由于每个deployment中都有三个组件，因此你应该自下而上依次调试所有组件。
<ul>
<li>你应该先确保Pods正在运行</li>
<li>然后，专注于让service将流量路由到到正确的Pod</li>
<li>然后，检查是否正确配置了Ingress</li>
</ul>
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-15.png" alt="img{512x368}">
<center>你应该从底部开始对deployment进行故障排除。首先，检查Pod是否已就绪并正在运行。</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-16.png" alt="img{512x368}">
<center>如果Pod已就绪，则应调查service是否可以将流量分配给Pod。</center>
 
<img src="https://tonybai.com/wp-content/uploads/k8s-deployment-troubleshooting/troubleshooting-deployments-17.png" alt="img{512x368}">
<center>最后，你应该检查service与ingress之间的连接。</center>
 
<h3> </h3>
<h3>1. Pod故障排除</h3>
在大多数情况下，问题出在Pod本身。
你应该确保Pod正在运行并准备就绪。
该如何检查呢？
<pre><code>$ kubectl get pods
NAME READY STATUS RESTARTSAGE
app1 0/1 ImagePullBackOff0 47h
app2 0/1 Error 0 47h
app3-76f9fcd46b-xbv4k 1/1 Running 1 47h
</code></pre>
在上述会话中，最后一个Pod处于就绪并正常运行的状态；但是，前两个Pod既不处于Running也不是Ready。
你如何调查出了什么问题？
有四个有用的命令可以对Pod进行故障排除：
<ul>
<li>kubectl logs 有助于检索Pod容器的日志</li>
<li>kubectl describe pod 检索与Pod相关的事件列表很有用</li>
<li>kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义</li>
<li>kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用</li>
</ul>
应该使用哪一个呢？
没有一种万能的。
相反，我们应该结合着使用它们。
<h4>常见Pod错误</h4>
Pod可能会出现启动和运行时错误。
启动错误包括：
<ul>
<li>ImagePullBackoff</li>
<li>ImageInspectError</li>
<li>ErrImagePull</li>
<li>ErrImageNeverPull</li>
<li>RegistryUnavailable</li>
<li>InvalidImageName</li>
</ul>
运行时错误包括：
<ul>
<li>CrashLoopBackOff</li>
<li>RunContainerError</li>
<li>KillContainerError</li>
<li>VerifyNonRootError</li>
<li>RunInitContainerError</li>
<li>CreatePodSandboxError</li>
<li>ConfigPodSandboxError</li>
<li>KillPodSandboxError</li>
<li>SetupNetworkError</li>
<li>TeardownNetworkError</li>
</ul>
有些错误比其他错误更常见。
以下是最常见的错误列表以及如何修复它们的方法。
<h4>ImagePullBackOff</h4>
当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。
共有三个可能的原因：
<ul>
<li>镜像名称无效-例如，你拼错了名称，或者image不存在</li>
<li>你为image指定了不存在的标签</li>
<li>你尝试检索的image属于一个私有registry，而Kubernetes没有凭据可以访问它</li>
</ul>
前两种情况可以通过更正image名称和标记来解决。
针对第三种情况，你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。
官方文档中有一个有关如何实现此目标的示例。
<h4>CrashLoopBackOff</h4>
如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。
通常，在以下情况下容器无法启动：
<ul>
<li>应用程序中存在错误，导致无法启动</li>
<li>你未正确配置容器</li>
<li>Liveness探针失败太多次</li>
</ul>
你应该尝试从该容器中检索日志以调查其失败的原因。
如果由于容器重新启动太快而看不到日志，则可以使用以下命令：
<pre><code>$ kubectl logs <pod-name> --previous
</code></pre>
这个命令打印前一个容器的错误消息。
<h4>RunContainerError</h4>
当容器无法启动时，出现此错误。
甚至在容器内的应用程序启动之前。
该问题通常是由于配置错误，例如：
<ul>
<li>挂载不存在的卷，例如ConfigMap或Secrets</li>
<li>将只读卷安装为可读写</li>
</ul>
你应该使用kubectl describe pod 命令收集和分析错误。
<h4>处于Pending状态的Pod</h4>
当创建Pod时，该Pod保持Pending状态。
为什么？
假设你的调度程序组件运行良好，可能的原因如下：
<ul>
<li>集群没有足够的资源（例如CPU和内存）来运行Pod</li>
<li>当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额</li>
<li>该Pod绑定到一个处于pending状态的 PersistentVolumeClaim</li>
</ul>
最好的选择是检查kubectl describe命令输出的“事件”部分内容：
<pre><code>$ kubectl describe pod <pod name>
</code></pre>
对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志：
<pre><code>$ kubectl get events --sort-by=.metadata.creationTimestamp
</code></pre>
<h4>处于未就绪状态的Pod</h4>
如果Pod正在运行但未就绪(not ready)，则表示readiness就绪探针失败。
当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。
就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。
<h3> </h3>
<h3>2. 服务的故障排除</h3>
如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。
service旨在根据流量的标签将流量路由到Pod。
因此，你应该检查的第一件事是服务关联了多少个Pod。
你可以通过检查服务中的端点(endpoint)来做到这一点：
<pre><code>$ kubectl describe service <service-name> | grep Endpoints
</code></pre>
端点是一对，并且在服务（至少）以Pod为目标时，应该至少有一个端点。
如果“端点”部分为空，则有两种解释：
<ul>
<li>你没有运行带有正确标签的Pod（提示：你应检查自己是否在正确的命名空间中）</li>
<li>service的selector标签上有错字</li>
</ul>
如果你看到端点列表，但仍然无法访问你的应用程序，则targetPort可能是你服务中的罪魁祸首。
你如何测试服务？
无论服务类型如何，你都可以使用kubectl port-forward来连接它：
<pre><code>$kubectl port-forward service/<service-name> 3000:80
</code></pre>
这里：
<ul>
<li>是服务的名称</li>
<li>3000 是你希望在计算机上打开的端口</li>
<li>80 是服务公开的端口</li>
</ul>
<h3> </h3>
<h3>3.Ingress的故障排除</h3>
如果你已到达本节，则：
<ul>
<li>Pod正在运行并准备就绪</li>
<li>服务会将流量分配到Pod</li>
</ul>
但是你仍然看不到应用程序的响应。
这意味着最有可能是Ingress配置错误。
由于正在使用的Ingress控制器是集群中的第三方组件，因此有不同的调试技术，具体取决于Ingress控制器的类型。
但是在深入研究Ingress专用工具之前，你可以用一些简单的方法进行检查。
Ingress使用serviceName和servicePort连接到服务。
你应该检查这些配置是否正确。
你可以通过下面命令检查Ingress配置是否正确：
<pre><code>$kubectl describe ingress <ingress-name>
</code></pre>
如果backend一列为空，则配置中必然有一个错误。
如果你可以在“backend”列中看到端点，但是仍然无法访问该应用程序，则可能是以下问题：
<ul>
<li>你如何将Ingress暴露于公共互联网</li>
<li>你如何将集群暴露于公共互联网</li>
</ul>
你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。
首先，获取你的Ingress控制器Pod（可以位于其他名称空间中）：
<pre><code>$ 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-minikube1/1 Running
kube-system kube-proxy-zvf2h 1/1 Running
kube-system kube-scheduler-minikube 1/1 Running
kube-system nginx-ingress-controller-6fc5bcc1/1 Running
</code></pre>
描述它以检索端口：
<pre><code># kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system \
| grep Ports
</code></pre>
最后，连接到Pod：
<pre><code>$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system
</code></pre>
此时，每次你访问计算机上的端口3000时，请求都会转发到Pod上的端口80。
现在可以用吗？
<ul>
<li>如果可行，则问题出在基础架构中。你应该调查流量如何路由到你的集群。</li>
<li>如果不起作用，则问题出在Ingress控制器中。你应该调试Ingress。</li>
</ul>
如果仍然无法使Ingress控制器正常工作，则应开始对其进行调试。
目前有许多不同版本的Ingress控制器。
热门选项包括Nginx，HAProxy，Traefik等。
你应该查阅Ingress控制器的文档以查找故障排除指南。
由于Ingress Nginx是最受欢迎的Ingress控制器，因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。
<h4>调试Ingress Nginx</h4>
Ingress-nginx项目有一个Kubectl的官方插件。
你可以用kubectl ingress-nginx来：
<ul>
<li>检查日志，后端，证书等。</li>
<li>连接到ingress</li>
<li>检查当前配置</li>
</ul>
你应该尝试的三个命令是：
<ul>
<li>kubectl ingress-nginx lint，它会检查 nginx.conf</li>
<li>kubectl ingress-nginx backend，以检查后端（类似于kubectl describe ingress ）</li>
<li>kubectl ingress-nginx logs，查看日志</li>
</ul>
<blockquote>
请注意，你可能需要为Ingress控制器指定正确的名称空间–namespace 。
</blockquote>
<h2> </h2>
<h2>四. 总结</h2>
如果你不知道从哪里开始，那么在Kubernetes中进行故障排除可能是一项艰巨的任务。
你应该始终牢记从下至上解决问题：从Pod开始，然后通过Service和Ingress向上移动堆栈。
你在本文中了解到的调试技术也可以应用于其他对象，例如：
<ul>
<li>failing Job和CronJob</li>
<li>StatefulSets和DaemonSets</li>
</ul>
本文翻译自learnk8s上的文章A visual guide on troubleshooting Kubernetes deployments。
</div> 
来源：https://www.cnblogs.com/evenchen/p/12014778.html

頁: [1]

琼殿技术论坛's Archiver

Kubernetes Deployment故障排除图解指南