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

当你希望在Kubernetes中部署一个应用程序,你通常需要定义三个组件:

  • Deployment——这是创建名为Pods的应用程序副本的方法

  • Serivce——内部负载均衡器,将流量路由到Pods

  • Ingress——可以描述流量如何从集群外部流向Service

接下来,我们通过图片快速回顾一下。

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

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

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是如何与彼此关联的。你应该记住三件事:

  1. Service selector至少与Pod的一个标签匹配

  2. Serivce targetPort应该与Pod内的容器的containerPort相匹配

  3. Serviceport可以是任何数字。多个Service可以使用同一个端口,因为它们已经被分配了不同的IP地址

以下图片总结了如何连接端口:

考虑由Service暴露的pod

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

当你创建一个Service时,你能够定义一个port和一个targetPort。但你应该将哪一个连接到容器呢?

targetPortcontainerPort应该能够匹配

如果你的容器暴露端口3000,那么targetPort应该与该数字相匹配。

如果你查看了YAML,标签与portstargerPort应该匹配:

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中应该匹配两件事:

  1. Ingress的servicePort应该与Service的port匹配

  2. 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 ,你应该能找到提供网页的应用程序。

简单回顾一下

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

  1. Service selector应该匹配Pod的标签

  2. ServicetargerPort应该匹配在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

  • 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消息。

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

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

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

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是一对```,并且当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的名称

  • 3000是你想要在电脑上打开的端口

  • 80是由Service暴露的端口

3、 排查Ingress故障

如果你走到了这个部分,这意味着:

  • Pod正在运行并且准备就绪

  • Service可以分发流量给Pod

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

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

Ingress使用serviceNameservicePort连接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!

超长可视化指南!带你理清K8S部署的故障排查思路,让bug无处遁形的更多相关文章

  1. K8s deployments的故障排查可视化指南已更新(2021 中文版)

    转载自:https://mp.weixin.qq.com/s/07S930e6vsN2iToo0gP0zg 英文版 高清图地址:https://learnk8s.io/a/a-visual-guide ...

  2. 2.Ceph 基础篇 - 集群部署及故障排查

    文章转载自:https://mp.weixin.qq.com/s?__biz=MzI1MDgwNzQ1MQ==&mid=2247485243&idx=1&sn=e425c31a ...

  3. K8s 部署 Dashboard UI 仪表板 ——让一切可视化

    K8s 部署 Dashboard UI  仪表板   --让一切可视化 Dashboard 介绍 仪表板是基于Web的Kubernetes用户界面.您可以使用仪表板将容器化应用程序部署到Kuberne ...

  4. Jenkins+Git+Docker+K8s部署

    准备工作 Jenkins已安装 Docker和K8s部署运行成功 代码管理工具使用Git 最近公司项目使用Jenkins+Git+Docker+K8s进行持续化构建部署,这里笔者整理了一下构建部署的相 ...

  5. 阿里nacos k8s部署

    阿里nacos k8s部署 [root@master1 nacos]# cat nacos-quick-start.yaml --- apiVersion: v1 kind: Service meta ...

  6. 日志分析系统 - k8s部署ElasticSearch集群

    K8s部署ElasticSearch集群 1.前提准备工作 1.1 创建elastic的命名空间 namespace编排文件如下: elastic.namespace.yaml --- apiVers ...

  7. 微服务从代码到k8s部署应有尽有系列(五、民宿服务)

    我们用一个系列来讲解从需求到上线.从代码到k8s部署.从日志到监控等各个方面的微服务完整实践. 整个项目使用了go-zero开发的微服务,基本包含了go-zero以及相关go-zero作者开发的一些中 ...

  8. 微服务从代码到k8s部署应有尽有系列(八、各种队列)

    我们用一个系列来讲解从需求到上线.从代码到k8s部署.从日志到监控等各个方面的微服务完整实践. 整个项目使用了go-zero开发的微服务,基本包含了go-zero以及相关go-zero作者开发的一些中 ...

  9. k8s部署使用Dashboard(十)--技术流ken

    安装Dashboard 前面博客Kubernetes 所有的操作我们都是通过命令行工具 kubectl 完成的.为了提供更丰富的用户体验,Kubernetes 还开发了一个基于 Web 的 Dashb ...

随机推荐

  1. VScode(一):C/C++ & MinGW & Code Runner

    目录 1 VScode配置安装 2 MinGW配置安装 2.1 MinGW下载安装 2.2 MinGW环境配置 3 VScode编译C/C++ 3.1 扩展插件安装 3.2 项目配置 3.2.1 配置 ...

  2. [论文翻译]Practical Diversified Recommendations on YouTube with Determinantal Point Processes

    目录 ABSTRACT(摘要) 1 INTRODUCTION(简介) 2 RELATED WORK 2.1 Diversification to Facilitate Exploration(对应多样 ...

  3. express项目创建

    npm install express-generator -g       全局安装express生成器 express -h  帮助中心 express 项目名 npm i    安装依赖 nod ...

  4. 【5min+】闪电光速拳? .NetCore 中的Span

    系列介绍 简介 [五分钟的DotNet]是一个利用您的碎片化时间来学习和丰富.net知识的博文系列.它所包含了.net体系中可能会涉及到的方方面面,比如C#的小细节,AspnetCore,微服务中的. ...

  5. java.sql.SQLException: connection holder is null 问题处理

    问题描述 上上个周测试的时候突然报系统异常,于是我立即查看日志,发现是一个数据库异常:java.sql.SQLException: connection holder is null我第一想到的就是可 ...

  6. 区间 dp

    以一个经典题目引入到正题 : 有 n 堆石子 , 每两堆石子合并会花费一定的价值,所花费的价值即为 两堆石子上的价值和 , 问合并所有的石子后的最小花费 ? 思路分析 : 因为题干可以看成是对每个区间 ...

  7. DP-01背包 (题)

    nyoj 325   http://acm.nyist.net/JudgeOnline/problem.php?pid=325 zb的生日 时间限制:3000 ms  |  内存限制:65535 KB ...

  8. Spring Cloud(三):Web服务客户端之Feign

    前文介绍了实现客户端负载均衡的Ribbon,但直接使用Ribbon的API来实现服务间的调用相对较为繁琐,服务间的调用能否像本地接口调用一样便捷.透明,更符合编程习惯呢?Feign就是用来干这事的. ...

  9. MongoDB数据库备份和恢复

    1.数据库备份 mogodbdump -h dbhost -d dbname -o dbdirectory -h: 服务器地址,也可以指定端口号 -d: 需要备份的数据库的名称 -o: 备份的数据库存 ...

  10. Bootstrap File Input 的使用

    由于工作需要使用Bootstrap的FileInput插件,在此分享下插件的使用方法 直接上代码 fileinput.html <!DOCTYPE html> <html> & ...