如何发现 Kubernetes 中服务和工作负载的异常

一时失言乱红尘 2022-09-15 12:22 200阅读 0赞

大家好，我是来自阿里云的李煌东，今天由我为大家分享 Kubernetes 监控公开课的第二节内容：如何发现 Kubernetes 中服务和工作负载的异常。

本次分享由三个部分组成：

一、Kubernetes 异常定位存在痛点；

二、针对这些痛点，Kubernetes 监控如何更快、更准、更全的发现异常；

三、网络性能监控、中间件监控等典型案例解析。

# Kubernetes 异常定位存在痛点 #

当下的互联网架构中，越来越多的公司采用微服务 + Kubernetes 这样的架构，这样的架构有如下特点：

1.  首先应用层基于微服务，微服务由解耦开的几个服务相互调用构成，服务一般职责分明、边界明确，造成的结果是一个简单的产品也有几十、甚至上百个微服务，相互之间的依赖、调用是非常复杂的，这给定位问题带来比较大的成本。同时，每个服务的 owner 可能来自不同团队，不同的开发，可能使用不同的语言，对我们监控的影响是对每一种语言都需要进行监控工具的接入，投资回报率低。还有一个特点是多协议，几乎每种中间件（Redis、MySQL、Kafka）都有他们独特的协议，怎么要做到快速对这些协议进行观测，是不小的挑战。
2.  虽然 Kubernetes 和容器对上层应用屏蔽了底层的复杂度，但是带来的两个结果是：基础设施层越来越高；另一个是上层应用和基础设施之间信息变得越来越复杂了。举个例子，用户反馈网站访问很慢，管理员查看访问日志、服务状态、资源水位发现都没问题，这时候不知道问题出现在哪里，虽然怀疑基础设施有问题，但无法定界的情况下只能一个一个排查效率低，问题的根源就是上层应用和基础设施之间缺少上下问题关联，无法做到端到端串联。
3.  最后一个痛点是数据散、工具多、信息没打通。举个例子，假设我们收到一个告警，用 grafana 去查看指标，指标只能描述的比较粗略，我们得去看下日志，这时候我们要去 SLS 日志服务看下有没有对应的日志，日志也没问题，这时候我们需要登录到机器上去看，然而登录到容器里面可能又因为重启导致日志没有了。查了一波之后，可能我们会觉得可能问题不是出现在这个应用，于是我们又去看链路追踪是不是下游有问题。总而言之，工具用了一大堆，浏览器开了十几个窗口，效率低、体验差。

这三个痛点分别归纳为成本、效率、体验三个方面。针对这些痛点，接下来我们一起看下 Kubernetes 监控的数据体系，看下怎么来更好的解决成本、效率、体验三大问题。

# Kubernetes 监控如何发现异常 #

下图金子塔自顶向下表示信息的密度或者详细程度，越往下面信息越详细。我们从底部开始讲，Trace 是我们通过eBPF技术以无入侵、多协议、多语言的方式采集应用层协议数据，如 HTTP、MySQL、Redis，协议数据会进一步解析成容易理解的请求详情、响应详情、各个阶段的耗时信息。

![图片 1.png][1.png]

再上一层是指标，指标主要由黄金指标、网络、Kubernetes 体系中的指标。其中黄金指标和网络指标是基于 eBPF 采集的，所以同样他们是没有入侵的，支持各种协议的，有了黄金指标，我们就能知道服务整体上是否有异常、是否有慢、是否影响用户；网络指标主要是对socket的支持，如丢包率、重传率、RTT 等，主要用来监控网络是否正常的指标。Kubernetes 体系中的指标是指原来 Kubernetes 监控体系中的 cAdvisor/MetricServer/Node Exporter/NPD 这些指标。

再上一层是事件，事件直接明确地告诉我们发生了什么，可能我们遇到最多的是 Pod 重启、拉镜像失败等。我们对 Kubernetes 事件进行了持久化存储，并保存一段时间，这样方便定位问题。然后，我们的巡检和健康检查也是支持以事件的形式报出来。

最顶层是告警，告警是监控系统的最后一环，当我们发现某些特定异常可能对业务有损后，我们就需要对指标、事件进行告警配置。告警目前支持 PromQL，智能告警支持对历史数据进行智能算法检测，从而发现潜在的异常事件。告警的配置支持动态阈值，通过调节灵敏度的方式来配置告警，从而避免写死阈值。

有了 Trace、指标、事件、告警之后，我们用拓扑图将这些数据和 Kubernetes 实体都关联起来，每个节点对应 Kubernetes 实体中的服务和工作负载，服务之间调用用线表示。有了拓扑图，我们就像拿到一张地图，能快速识别拓扑图中的异常，并对异常进行进一步的分析，对上下游、依赖、影响面进行分析，从而对系统有了更全面的掌控。

# 最佳实践&场景分析 #

接下来我们讲下发现 Kubernetes 中服务和工作负载的异常的最佳实践。

首先还是先有指标，指标能反应服务的监控状态，我们应尽可能地收集各种指标，并且越全越好，不限于黄金指标、USE 指标、Kubernetes 原生指标等；然后，指标是宏观数据，需要做根因分析我们得有 Trace 数据，多语言、多协议的情况下要考虑采集这些 Trace 的成本，同样尽可能地支持多一点协议、多一点语言；最后，用一张拓扑将指标、Trace、事件汇总起来、串联起来，形成一张拓扑图，用来做架构感知分析、上下游分析。

![图片 2.png][2.png]

通过这三种方法的分析，服务和工作负载的异常通常暴露无遗了，但我们不应该就此停止前进的脚步，加入这个异常下次再来，那么我们这些工作得重来一遍，最好的办法是针对这类异常配置对应的告警，自动化地管理起来。

我们用几个具体的场景来详细介绍：

### （一）网络性能监控 ###

网络性能监控以重传为例，重传的意思是说发送方认为发生了丢包现象，就重发这些数据包。以图中的传输过程为例：

![图片 3.png][3.png]

1.  发送方发送编号为 1 的包，接收方接受了，返回 ACK 2
2.  发送方发送编号为 2 的包，接收方返回 ACK 2
3.  发送方发送编号为 3、4、5 的包，接收方都返回 ACK 2
4.  直到发送方收到 3 次同样的 ACK ，就会触发重传机制，重传会导致延迟升高

代码和日志是观察不出来的，这种情形下最终很难找到根因。为了能快速定位这个问题，我们需要一组网络性能指标来提供定位依据，包含以下指标，P50、P95、P99 指标来表示延时，然后我们需要流量、重传、RTT、丢包这些指标来表征网络情况。

以某个服务 RT 高为例：首先我们看到拓扑的边是红的，红的判断逻辑是根据延时、错误来判断的，当发现这个红边的时候，点击上面的边，就可以看对应的黄金指标了。

![图片 4.png][4.png]

点击底部最左边这个按钮，可以查看当前服务的网络数据列表，我们可以按平均响应时间、重传、RTT 排下序，可以看到第一个服务调用延时比较高，快到一秒的返回时间，同时也看到重传比较高，相比于其他服务高很多。这里其实是通过工具去注入了重传高这么一个故障，看起来更明显一些。这样分析下来我们就知道可能是网络的问题，就可以进一步排查了。有经验的开发一般会拿着网络指标、服务名、ip、域名这些信息去找网络的同事排查，而不是只是告诉对方说我服务很慢，这样对方知道的信息太少，就不会积极去排查，因为别人也不知道从哪里开始，当我们提供了相关数据，对方就有了参考，会顺藤摸瓜进一步推进。

### （二）DNS 解析异常 ###

第二个场景是 DNS 解析异常。DNS 通常是协议通信的第一步，比如 HTTP 请求，第一步就是先拿到 IP，也就是我们平常说的服务发现过程，第一步出现问题，整个调用就直接失败了，这就是所谓关键路径不能掉链子。在 Kubernetes 集群中所有的 DNS 都走 CoreDNS 的解析，所以 CoreDNS 上容易出现瓶颈，一旦出现问题，影响面也是非常大的，可能整个集群都不可用了。举个两个月前发生的鲜活的例子，著名的 CDN 公司 Akamai 就发生了一个 DNS 故障，导致众多网站像 Airbnb 网站无法访问，事故持续了长达一个小时。

在 Kubernetes 集群中 DNS 解析比较核心的几个场景有三个：

1.  调用外部 API 网关
2.  调用云服务，云服务一般是公网的
3.  调用外部中间件

![图片 5.png][5.png]

这里对 CoreDNS 常见的问题进行了归纳，大家可以参考下，排查下自己的集群上有没有类似问题：

1.  配置问题（ndots 问题），ndots 是个数字，表示域名中点的个数要是小于 ndots，那么搜索就优先走 search 列表中的域去查找，这样的话会产生多次查询，对性能的影响还是挺大的。
2.  由于 Kubernetes 所有的域名解析都走 CoreDNS，非常容易成为性能瓶颈，有人统计过大概 qps 在 5000~8000 的时候就要关注性能问题了。尤其是依赖外部 Redis、MySQL 这种访问量比较大的。
3.  低版本的 CoreDNS 有稳定性问题，这个也是需要关注的点。
4.  有些语言，想 PHP 对连接池支持的不是很好，导致每次都要去解析 DNS，创建连接，这个现象也是比较常见的。

接下来，我们看下 Kubernetes CoreDNS 中可能会发生问题的地方，首先应用和 CoreDNS 之间的网络可能有问题；第二是 CoreDNS 本身问题，比如 CoreDNS 返回 SERVFAIL、REFUSE 这些错误码，甚至因为 Corefile 配置错了，导致返回值是错的；第三点是跟外部 DNS 通信的时候，发生网络中断、性能问题；最后一个是外部 DNS 不可用。

针对这些问题点总结出以下步骤来盘查：

第一、从客户端侧，先看下请求内容和返回码，如果是返回是错误码说明是服务端有问题。如果是慢解析，可以看下时间瀑布流看下时间耗费在哪个阶段。  
第二、看网络是否正常，看流量、重传、丢包、RTT 这几个指标就够了。  
第三、查看服务端，看下流量、错误、延时、饱和度这几个指标，再看下 CPU、内存、磁盘等这几个资源指标，也能定位出是否有问题。  
第四、看下外部 DNS，同理我们可以通过请求 Trace、返回码、网路流量、重传等指标来定位。

![图片 6.png][6.png]

接下来我们看下拓扑。首先看到红色的线表示有异常的 DNS 解析调用，点击这个我们能看到调用的黄金指标；点击查看列表，弹出详情页面，可查看请求的详情，是请求这个域名，请求过程中经历发送、等待、下载三个过程，看起来指标正常，接下来我们点击看响应，发现响应是域名不存在。那么这时候我们可以进一步看下外部 DNS 是否有问题，步骤也是一样的，后面我会在 demo 中展示，所以这里就不展开先了。

### （三）全链路压测 ###

第三个典型场景是全链路压测，对于大促这种场景峰值是平常的数倍，怎么保障大促的稳定，需要通过一系列的压测来验证系统能力、系统稳定性评估、做容量规划、识别系统瓶颈。一般会有这么几个步骤：先预热下，这时候验证下链路是否正常的，逐步加流量直到峰值，然后开始摸高，也就是看下能支持的最大 TPS 是多少，接着再加流量，这时候主要就是看服务是否能正常限流了，因为已经找过最大 TPS 了，再加大力量就是破坏性流量了。那么在这个过程中，我们需要关注哪些点呢？

首先针对我们多语言、多协议的微服务架构，比如这里的 Java、Golang、Python 应用，这里有 RPC、MySQL、Redis、Kafka 应用层协议，我们得有各种语言、各种协议的黄金指标，用来验证系统能力；针对系统的瓶颈、容量规划这块，我们需要 use 指标，去看各种流量级别情况下资源的饱和度，来确定是不是要扩容，每增加一次流量，对应看下 use 指标，对应调整容量，逐步优化；对于复杂架构，需要有一张全局的大图来帮助梳理上下游依赖、全链路架构，确定爆炸报警，比如这里的 CheckoutService 就是个关键的服务，这个点如果出现问题，影响面会很大。

![图片 7.png][7.png]

第一、各种语言、协议通信的黄金指标，通过查看列表进一步看调用的详情  
第二、点击节点详情下钻查看 cpu、memory 等 use 资源指标  
第三、整个拓扑图是能反映整个架构的形态的，有了全局的架构视角，就能识别哪个服务容易成为瓶颈、爆炸半径有多大，是否需要做高可用保障。

### （四）访问外部 MySQL ###

第四个场景是访问外部 MySQL，先看下访问外部 MySQL 有哪些常见的问题：

![图片 8.png][8.png]

1.  首先是慢查询，慢查询提现为延时指标高，这时候去看 trace 里面详情请求是啥，查询的是哪张表，哪些字段，进而看下是不是查询量太大了、表太大了、还是说没有建索引等。
2.  查询语句过大，我们知道查询语句太大会导致传输耗时高，网络稍一抖动就造成失败重试，还会引发带宽占用的问题。一般都是一些批量的更新、插入导致的，出现这种问题延时指标会飙高，这时候我们可以选择RT较高的一些 Trace 来看，看下语句怎么写的、看下查询语句的长度是不是太大了。
3.  错误码返回，比如表不存在这种，那么解析出其中的错误码就很有帮助了，再进一步看里面的详情，去看语句，就比较容易定位出根因了。
4.  网络问题，这个点也讲过比较多了，一般配合着延时指标加上 RTT、重传、丢包来确定网络是否有问题。

![图片 9.png][9.png]

接下来看下拓扑图，中间框住的应用依赖了外部的 MySQL 服务，点击拓扑线可以进一步看黄金指标，点击查看列表可以进一步看请求的详情、响应等。同时我们也可以看下网络性能指标，这个 table 是将当前拓扑中的网络数据根据来源和目标进行归类，可以分别查看请求数、错误数、平均响应时间、socket 重传、socket rtt，点击上面箭头可以对应地排序。

### （五）多租户架构 ###

第五个典型案例是多租户架构。多租户指的是不同的租户、工作负载、不同团队，公用一个集群，通常一个租户对应一个命名空间，同时保证资源的逻辑隔离或者物理隔离，互不影响、互不干扰。常见的场景有：企业内部用户，一个团队对应一个租户，同一个命名空间内网络不受限制，用网络策略去控制不同命名空间之间的网络流量。第二种是 SaaS 提供商多租户架构，每个用户对应一个命名空间，同时租户和平台分别处于不同的命名空间。虽然 Kubernetes 的命名空间特性给多租户架构带来了便利，但也给可观测带来两个挑战：第一命名空间非常多，查找信息变得很繁琐，增加了管理成本、理解成本。第二是租户之间有流量隔离的要求，在命名空间比较多的情况下往往无法做到准确、全面的发现异常流量。第三是对多协议、多语言的 Trace 支持。曾经遇到过一个客户，一个集群里面有 400 多个命名空间，管理起来非常痛苦，而且应用是多协议、多语言的，要支持 Trace，得一个个改造。

![图片 10.png][10.png]

这是我们产品的集群首页，Kubernetes 的实体以命名空间的方式划分，支持查询来定位到我想看的集群。气泡图上展示对应命名空间上的实体数，以及有异常的实体数，比如框子里 3 个命名空间里存在有异常的 pod，点进去可以进一步看异常。首页下面是按黄金指标排序的性能概览，也就是场景的 Top 功能，这样能快速查看哪几个命名空间是有异常的。

![图片 11.png][11.png]

在拓扑图中，如果命名空间比较多，可以通过过滤功能查看想看的命名空间，或者通过搜索方式快速定位到想看的命名空间。由于节点是以命名空间分组的，能通过命名空间之间的线来查看命名空间的流量，这样就能方便地查看有来自哪些命名空间的流量、是否有异常流量等等。

![图片 12.png][12.png]

我们将上述场景介绍总结如下：

![图片 13.png][13.png]

1.  网络监控：如何能分析网络导致的服务的错慢、中断，如何分析网络问题带来的影响
2.  服务监控：如何通过黄金指标确定服务是否健康？如何通过支持多协议的 Trace 查看详情？
3.  中间件、基础设施监控：如何用黄金指标、trace 分析中间件、基础设施的异常，如何快速定界是网络问题，还是自身问题，还是下游服务问题
4.  架构感知：如何通过拓扑感知整个架构，梳理上下游、内部外部依赖，进而能掌控全局？如何通过拓扑保障架构有足够的观测性、稳定性保障，如何通过拓扑分析、发现系统中的瓶颈、爆炸半径。

从这几个场景中又进一步列举常见的 case：网络、服务的可用性检测，健康检查；中间件架构升级可观测性保障；新业务上线验证；服务性能优化；中间件性能监控；方案选型；全链路压测等。

# 产品价值 #

经过以上内容介绍，我们将 Kubernetes 的产品价值总结如下：

![图片 14.png][14.png]

1.  通过多协议、多语言、无入侵的方式采集服务的指标和 Trace 数据，最大限度地减少接入的成本，同时提供覆盖度全面的指标和Trace；
2.  有了这些指标和 Trace 之后我们就能，对服务和工作负载进行科学的分析、下钻；
3.  将这些指标、Trace 关联起来串成一张拓扑图，能在一张大图上进行架构感知、上下游分析、上下文关联等，充分得理解架构，评估潜在的性能瓶颈等，方便做进一步的架构优化；
4.  提供配置简单的告警配置方法，将经验知识沉淀到告警中，做到主动发现。

本节课的内容到这里就结束了，欢迎大家前往钉钉搜索群号（31588365）加入答疑交流群进行交流。

目前 Kubernetes 监控已经全面免费公测，点击下方链接，立即开启试用！  
https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n

[1.png]: /images/20220828/bddbd334f7094fe9a45f33d2b4f9014c.png
[2.png]: /images/20220828/326f401344f64feab8997d379fe54dbc.png
[3.png]: /images/20220828/d095fe0e5fc74bee96ef265a2a280486.png
[4.png]: /images/20220828/7ff6b38c979d44d685d10bb4455f08aa.png
[5.png]: /images/20220828/c4d61f9deaf24aa0bf3bf38daba18bbe.png
[6.png]: /images/20220828/05519878993844fb8d5ea85b1f2b5a92.png
[7.png]: /images/20220828/c39a189ea4754ff98144b64c91695e01.png
[8.png]: /images/20220828/7ae31dc074e6403a8f6e730c4f97484e.png
[9.png]: /images/20220828/38ef81d5771c4a27a89e99d16bf4ff6b.png
[10.png]: /images/20220828/6511b794c82b4fc48315105a8d8f80c6.png
[11.png]: /images/20220828/539c79685e434c3c94680a47087371b1.png
[12.png]: /images/20220828/070f7983f90a4341b667503e79f998d8.png
[13.png]: /images/20220828/97649df24f6e4d6ca3775a1d6db03eab.png
[14.png]: /images/20220828/fe59b4b78036499c885b9dc69696a3cb.png