K8s 服务异常排障过程全解密

1 简介

Kubernetes（K8s）是一个用于大规模运行分布式应用和服务的开源容器编排平台。K8s 让应用发布更加快速安全，让应用部署也更加灵活，但在带来这些便利性的同时，也给应用排障增加了 K8s 平台层面的复杂度，本篇文章将以常见的服务异常入手，来详细拆解 K8s 服务访问方式，以及如何利用现有的可观测体系来对 k8s 平台和应用服务进行快速排障。

2 服务的访问方式

开启 K8s 服务异常排障过程前，须对 K8s 服务的访问路径有一个全面的了解，下面我们先介绍目前常用的 K8s 服务访问方式（不同云原生平台实现方式可能基于部署方案、性能优化等情况会存在一些差异，但是如要运维 K8s 服务，则需要在一开始就对访问方式有一个了解）。

2.1 方式一: 集群内客户端通过 Cluster IP访问集群内服务

从访问逻辑拓扑来分析，集群内客户端 POD 访问的是集群内服务的 svc_name，然后在 svc 层进行 DNAT，将请求转发到对应的后端 POD。这个过程对应的访问实现拓扑则要复杂不少:

• step 1: client_pod 根据 DNS 配置，请求 DNS 服务器解析 svc_name，DNS 服务器会返回 svc_name 对应的 ClusterIP
• step 2: client_pod 请求 ClusterIP，Node 根据 kube-proxy 配置的 IPVS/IPTABLES 完成 DNAT
• step 3: 根据 DNAT 的结果，Node 将请求转发给对应的 server_pod，server_pod 可能与 client_pod 在同一个 Node，也可能在不同 Node，此差异主要体现在网络转发层面

2.2 方式二: 集群外通过 NodePort 访问集群内服务

相比方式一，访问逻辑拓扑上 client 访问的区别是从 svc_name 替换为 nodeip:port。访问实现拓扑主要过程如下：

• step 1: client 直接请求 svc 对外暴露的 nodeip:port，如果是 LoadBalance 类型的服务，在此之前还会访问 LB（因为并不是 K8s 服务的中的特别能力，所以此处并无特别说明），请求转发到对应的 Node 上，Node 也会根据kube-proxy 配置的 IPVS/IPTABLES 完成 DNAT
• step 2: 与方式一的 step 3 一致

2.3 方式三: 集群外通过 ingress 访问集群内服务

方式三相比前两种方式，引入了 Ingress 的概念，因此复杂度增加了非常多。访问逻辑拓扑中外部 client 可以直接请求 url 而不是 ip 了，请求 url 会先到达 Ingress，由 Ingress 完成反向代理，转发给后端的 svc，svc 再完成 DNAT 转发给后端 POD。访问实现拓扑会根据 ingress-controller 部署形式不同而有差异，ingress-controller 非 hostnetwork 部署下文简称部署模式一，ingress-controller hostnetwork 部署下文简称部署模式二

• step 1：外部 client 请求 DNS 服务器解析 url 的域名，DNS 服务会返回 ingress-controller 服务所在的 IP (如果前面有挂 LB，则访问的是 LB 的 IP，否则返回的是 ingress-controller 服务的 nodeip:port)
• step 2：此时部署模式一，则需要按方式二访问 ingress-controller（为避免画图过于复杂，未画出 ingress_controller_pod 分布在不同 Node 场景）；部署模式二，请求到达 Node 后，则直接转给 ingress_controller_pod
• step 3：此为部署模式一特有的步骤，参考方式二
• step 4/5/6：请求经过 ingress_controller_pod 后，已经确定需要转发的后端 svc，则按方式一进行转发即可（为避免画图过于复杂，未画出 server_pod 分布在同 Node 场景）

3 服务异常的排障思路

了解服务的访问方式后，在遇到服务异常时，基于一套整体的排障思路来开展工作，更能事半功倍，接下来详细聊聊如何进行排障。

3.1 step1: 确定 Node/Pod 是否异常

首先我们可以通过 Prometheus 提供的 Dashboard 来检查部署的实例的基础状态，通过直接查看应用的 CPU/内存/带宽等指标，确认目前部署实例的负载都在正常范围内。

Node

Pod

3.2 step2: 确定后端服务是否异常

然后我们可以通过 DeepFlow 提供的 Dashboard 查看后端服务的黄金指标：请求、异常、时延，以快速判断目前的服务是否在正常运行。

后端服务

3.3 step3: 确定 DNS 是否异常

从前面服务的访问方式一节可知，仅方式一/方式三的访问过程经过 DNS 服务，因此只有这两种场景才需要检查 DNS 服务是否异常，方式一和三都需要检查集群内的 DNS 服务是否异常，方式三相比方式一还需要检查 client 访问的集群外的 DNS 服务是否异常。对于 CoreDNS 本身，我们可以使用 Prometheus 提供的 Dashboard 来进行排障，对于排查应用服务访问 DNS 异常，我们可以使用 DeepFlow 提供的 Dashboard 查看 DNS 服务的请求、异常、时延指标。

如 DNS 服务无异常，则可直接用 ClusterIP 访问服务，如果能正常访问，那可以确定是 DNS 的问题，并且这个问题很大可能就是配置错误。

3.4 step4: 确定 SVC 是否异常

因为 SVC 的功能实际是 kube-proxy 同步配置到 IPVS/IPTABLES 来实现的，所以我们可以参考 step 1 的排查步骤，把 kube-proxy 视作应用 POD，通过 Prometheus 提供的 Dashboard 查看 kube-proxy 是否正常。

如果能确定应用服务运行正常，可以尝试直接访问后端 POD，如果能正常访问，则可以继续分析 SVC 问题，很大可能是 IPVS/IPTABLES 配置错误。

3.5 step5 确定 ingress 是否异常

在服务访问方式中方式三的场景下，如果需要检查 Ingress 的状态，可以查看基于 ingress-controller 服务的状态/负载/请求日志等构建的 Dashboard。这一类 Dashboard 除了 Prometheus/DeepFlow 有提供之外，各个 API 网关的厂商也有提供，可以用 DeepFlow + 厂商提供的 Dashboard 结合进行分析，厂商会更关注网关本身的分析，DeepFlow 则更关注全链路分析，快速定位问题点。

3.6 step6: 追踪访问路径异常点

上述排障过程，都是独立的一个个点检查，如果都没问题，则可以去追踪报障的某一次访问路径是否有异常。如果能直接定位访问路径，确认问题点就会变得更简单。比如我们发现访问路径如果存在断路，则分析断路位置即可；如果追踪的是时延高的问题，则分析追踪到的每一段路径的时延即可。访问路径需要能覆盖从应用->系统->网络各个层面，目前提供这样全链路追踪能力的组件不多，可以使用 DeepFlow 等自动化的分布式追踪能力来进行排查。