image
本文将帮助你厘清在Kubernetes中调试 deployment的思路。下图是完整的故障排查思路，如果你想获得更清晰的图片，请在公众号后台（RancherLabs）回复“troubleshooting”。
image
当你希望在Kubernetes中部署一个应用程序，你通常需要定义三个组件：
-
Deployment——这是创建名为Pods的应用程序副本的方法
-
Serivce——内部负载均衡器，将流量路由到Pods
-
Ingress——可以描述流量如何从集群外部流向Service
接下来，我们通过图片快速回顾一下。
image
在Kubernetes中，你的应用程序通过两层负载均衡器暴露：内部和外部。
image
内部负载均衡器称为Service，而外部负载均衡器则称为Ingress。
image
Pod未直接部署，因此，Deployment创建Pod并监视它们。
假设你想部署一个简单的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: /
这个定义很长，容易忽略组件之间的相互关系。
例如：
-
你什么时候应该使用80端口，什么时候使用端口8080？
-
你是否应该为每个服务创建一个新端口，以免它们冲突？
-
标签（label）名称重要吗？是否应该每一处都一样？
在进行debug之前，我们先来回顾一下这三个组件之间的关系如何。
首先，我们从Deployment和Service开始。
连接Deployment和Service
实际上，Deployment和Service根本没有连接。相反，该Service直接指向Pod，并完全跳过Deployment。所以，你应该关注的是Pod和Service是如何与彼此关联的。你应该记住三件事：
-
Service selector至少与Pod的一个标签匹配
-
Serivce
targetPort应该与Pod内的容器的containerPort相匹配 -
Serviceport可以是任何数字。多个Service可以使用同一个端口，因为它们已经被分配了不同的IP地址
以下图片总结了如何连接端口：
image
考虑由Service暴露的pod
image
当你创建一个pod，你应该在你的Pod中为每个容器定义端口containerPort
image
当你创建一个Service时，你能够定义一个port和一个targetPort。但你应该将哪一个连接到容器呢？
image
targetPort与containerPort应该能够匹配
image
如果你的容器暴露端口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相匹配
以下图片将总结如何连接端口：
image
你已经知道该服务暴露了一个端口
image
Ingress有一个名为servicePort的字段。
image
Serviceport和IngressservicePort应该相匹配
image
如果你决定分配端口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的标签
-
Service
targerPort应该匹配在Pod内容器的containerPort -
Service 端口可以是任意数字。多个Service可以使用同个端口，因为它们已经分配了不同的IP地址
-
Ingress的
servicePort应该匹配在Service中的port -
Service的名称应该匹配在Ingress中的
serviceName的字段
了解如何构造YAML只是开始。那么，出了问题时会有什么表现？Pod可能无法启动，或者直接崩溃。
3步排查K8S Deployment故障
在我们深入研究有故障的deployment之前，必须有一个明确定义的模型，以了解Kubernetes的工作方式。
既然在每个deployment中都有那三个组件，你应该从底层开始按顺序调试它们。
-
你应该确保你的Pod正在运行
-
着重关注使Service将流量路由到Pod
-
检查Ingress是否正确配置
image
你应该从底层开始排查Deployment故障。首先，检查Pod是否准备就绪并且正在运行
image
如果Pod已经准备就绪，你需要检查Service是否可以将流量分配到Pod。
image
最后你应该检查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
-
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消息。
通常情况下，容器在以下场景中无法启动：
-
应用程序中存在错误，导致无法启动
-
你错误配置了容器
-
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”部分是空的，那么有两种解释：
-
任何正在运行的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暴露的端口
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/
你可以使用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！
网友评论