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

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

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

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

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

Kubernetes 异样定位存在痛点

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

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

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

Kubernetes 监控如何发现异常

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

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

再上一层是事件，事件间接明确地通知咱们产生了什么，可能咱们遇到最多的是 Pod 重启、拉镜像失败等。咱们对 Kubernetes 事件进行了长久化存储，并保留一段时间，这样不便定位问题。而后，咱们的巡检和健康检查也是反对以事件的模式报进去。

最顶层是告警，告警是监控零碎的最初一环，当咱们发现某些特定异样可能对业务有损后，咱们就须要对指标、事件进行告警配置。告警目前反对 PromQL，智能告警反对对历史数据进行智能算法检测，从而发现潜在的异样事件。告警的配置反对动静阈值，通过调节灵敏度的形式来配置告警，从而防止写死阈值。

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

最佳实际 & 场景剖析

接下来咱们讲下发现 Kubernetes 中服务和工作负载的异样的最佳实际。

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

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

咱们用几个具体的场景来具体介绍：

（一）网络性能监控

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

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

代码和日志是察看不进去的，这种情景下最终很难找到根因。为了能疾速定位这个问题，咱们须要一组网络性能指标来提供定位根据，蕴含以下指标，P50、P95、P99 指标来示意延时，而后咱们须要流量、重传、RTT、丢包这些指标来表征网络状况。

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

点击底部最右边这个按钮，能够查看以后服务的网络数据列表，咱们能够按均匀响应工夫、重传、RTT 排下序，能够看到第一个服务调用延时比拟高，快到一秒的返回工夫，同时也看到重传比拟高，相比于其余服务高很多。这里其实是通过工具去注入了重传高这么一个故障，看起来更显著一些。这样剖析下来咱们就晓得可能是网络的问题，就能够进一步排查了。有教训的开发个别会拿着网络指标、服务名、ip、域名这些信息去找网络的共事排查，而不是只是通知对方说我服务很慢，这样对方晓得的信息太少，就不会踊跃去排查，因为他人也不晓得从哪里开始，当咱们提供了相干数据，对方就有了参考，会顺藤摸瓜进一步推动。

（二）DNS 解析异样

第二个场景是 DNS 解析异样。DNS 通常是协定通信的第一步，比方 HTTP 申请，第一步就是先拿到 IP，也就是咱们平时说的服务发现过程，第一步呈现问题，整个调用就间接失败了，这就是所谓要害门路不能掉链子。在 Kubernetes 集群中所有的 DNS 都走 CoreDNS 的解析，所以 CoreDNS 上容易呈现瓶颈，一旦呈现问题，影响面也是十分大的，可能整个集群都不可用了。举个两个月前产生的鲜活的例子，驰名的 CDN 公司 Akamai 就产生了一个 DNS 故障，导致泛滥网站像 Airbnb 网站无法访问，事变继续了长达一个小时。

在 Kubernetes 集群中 DNS 解析比拟外围的几个场景有三个：

1. 调用内部 API 网关
2. 调用云服务，云服务个别是公网的
3. 调用内部中间件

这里对 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、返回码、网路流量、重传等指标来定位。

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

（三）全链路压测

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

首先针对咱们多语言、多协定的微服务架构，比方这里的 Java、Golang、Python 利用，这里有 RPC、MySQL、Redis、Kafka 应用层协定，咱们得有各种语言、各种协定的黄金指标，用来验证零碎能力；针对零碎的瓶颈、容量布局这块，咱们须要 use 指标，去看各种流量级别状况下资源的饱和度，来确定是不是要扩容，每减少一次流量，对应看下 use 指标，对应调整容量，逐渐优化；对于简单架构，须要有一张全局的大图来帮忙梳理上下游依赖、全链路架构，确定爆炸报警，比方这里的 CheckoutService 就是个要害的服务，这个点如果呈现问题，影响面会很大。

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

（四）拜访内部 MySQL

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

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

接下来看下拓扑图，两头框住的利用依赖了内部的 MySQL 服务，点击拓扑线能够进一步看黄金指标，点击查看列表能够进一步看申请的详情、响应等。同时咱们也能够看下网络性能指标，这个 table 是将以后拓扑中的网络数据依据起源和指标进行归类，能够别离查看申请数、谬误数、均匀响应工夫、socket 重传、socket rtt，点击下面箭头能够对应地排序。

（五）多租户架构

第五个典型案例是多租户架构。多租户指的是不同的租户、工作负载、不同团队，专用一个集群，通常一个租户对应一个命名空间，同时保障资源的逻辑隔离或者物理隔离，互不影响、互不烦扰。常见的场景有：企业外部用户，一个团队对应一个租户，同一个命名空间内网络不受限制，用网络策略去管制不同命名空间之间的网络流量。第二种是 SaaS 提供商多租户架构，每个用户对应一个命名空间，同时租户和平台别离处于不同的命名空间。尽管 Kubernetes 的命名空间个性给多租户架构带来了便当，但也给可观测带来两个挑战：第一命名空间十分多，查找信息变得很繁琐，减少了治理老本、了解老本。第二是租户之间有流量隔离的要求，在命名空间比拟多的状况下往往无奈做到精确、全面的发现异常流量。第三是对多协定、多语言的 Trace 反对。已经遇到过一个客户，一个集群外面有 400 多个命名空间，治理起来十分苦楚，而且利用是多协定、多语言的，要反对 Trace，得一个个革新。

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

在拓扑图中，如果命名空间比拟多，能够通过过滤性能查看想看的命名空间，或者通过搜寻形式疾速定位到想看的命名空间。因为节点是以命名空间分组的，能通过命名空间之间的线来查看命名空间的流量，这样就能不便地查看有来自哪些命名空间的流量、是否有异样流量等等。

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

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

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

产品价值

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

1. 通过多协定、多语言、无入侵的形式采集服务的指标和 Trace 数据，最大限度地缩小接入的老本，同时提供覆盖度全面的指标和 Trace；
2. 有了这些指标和 Trace 之后咱们就能，对服务和工作负载进行迷信的剖析、下钻；
3. 将这些指标、Trace 关联起来串成一张拓扑图，能在一张大图上进行架构感知、上下游剖析、上下文关联等，充沛得了解架构，评估潜在的性能瓶颈等，不便做进一步的架构优化；
4. 提供配置简略的告警配置办法，将教训常识积淀到告警中，做到被动发现。

本节课的内容到这里就完结了，欢送大家返回钉钉搜寻群号（31588365）退出答疑交换群进行交换。

目前 Kubernetes 监控曾经全面收费公测，点击下方链接，立刻开启试用！
https://www.aliyun.com/activi…