通过Kubernetes监控探索应用架构，发现预期外的流量

深藏阁楼爱情的钟 2022-09-12 06:43 91阅读 0赞

**简介：** Kubernetes 监控立足于应用监控之下的 Kubernetes 容器界面和底层操作系统，是 Kubernetes 集群软件栈端到端可观测性的一体化解决方案，在 Kubernetes 监控中可以同时看到关联的所有层的观测数据。我们希望通过 Kubernetes 监控的一系列最佳实践，让大家能够使用 Kubernetes 监控解决 Kubernetes 环境下棘手的可观测问题。

大家好，我是阿里云云原生应用平台的炎寻，很高兴能和大家一起在 Kubernetes 监控系列公开课上进行交流。本次公开课期望能够给大家在 Kubernetes 容器化环境中快速发现和定位问题带来新的解决思路。

# 为什么需要 Kubernetes 监控？ #

很多同学对应用性能监控应该并不陌生，这类监控主要关注业务应用逻辑、应用框架和语言运行时，监控对象有线程池满，数据库连接无法获取，MySQL， 内存溢出，还有各种调用链异常栈等。随着 Kubernetes 容器化技术带来的云原生技术演进，上层应用的开发和运维变得更加简单，但复杂度是恒定的，上层的复杂度降低必然伴随着底层的复杂度提升。如下图所示，复杂度逐渐转移到容器虚拟化层以及系统调用内核层对各种虚拟化技术的支持。每一层都可能出现问题，且这些问题会影响上层应用。比如容器虚拟化层的 Kubernetes 组件异常，如果调度器异常，Pod 将无法调度影响应用；比如文件系统相关的系统调用异常，上层应用无法读取文件，造成应用问题；比如内核异常，应用进程无法调度完成工作。

![1.png][]

应用想要健康稳定的运行，需要的是软件栈端到端的健康稳定，虽然现在很多运维团队都搭建了应用监控和系统监控体系，但没有一个监控能够自顶向下、端到端的串联起来各层软件的行为，导致棘手的问题发生时，无从下手处理。在应用层，一个网络请求超时，在客户端和服务端看起来似乎都没有问题，但实际上是网络层包发送 RTT 过高，重传率过高，亦或是 DNS 解析慢，或者是 CNI 插件慢。如何在 Kubernetes 容器化环境下做到端到端的可观测性是Kubernetes 监控出现的意义。

Kubernetes 监控立足于应用监控之下的 Kubernetes 容器界面和底层操作系统。在容器虚拟化层，我们通过以下五个数据源获取观测数据，通过 Kubernetes 管控组件 exporter 来获取 Kubernetes 管控组件的观测数据；通过 cAdvisor 获取容器的资源观测数据；通过 kube-state-metrics 获取 Kubernetes 资源的状态数据，还有事件和 Kubernetes 资源的状态以及条件数据。在系统调用层，我们通过 Kprobe/tracepoints  等 Linux tracing 技术获取观测数据；在内核层，我们通过内核可观测模块获取观测数据，然后 Kubernetes 监控通过进程、容器、Kubernetes 资源和业务应用的关联关系向上关联打通应用性能监控，打造端到端的可观测性。所以 Kubernetes 监控是 Kubernetes 集群软件栈端到端可观测性的一体化解决方案，在 Kubernetes 监控中可以同时看到关联的所有层的观测数据。我们希望通过 Kubernetes 监控的一系列最佳实践，让大家能够使用 Kubernetes 监控解决 Kubernetes 环境下棘手的可观测问题。

我们也将从两个类型去讲解，第一类是发现问题，主要包含五类问题的发现：应用架构问题、性能问题、资源问题、调度问题和网络问题。第二类是定位问题，主要包含对以上五类发现的问题进行根因定位，并且提供修复建议。

![2.png][]

# 探索应用架构，发现预期外的流量 #

Kubernetes 监控系列公开课第一节课的主题是“如何使用 Kubernetes 监控进行应用架构探索，发现预期外的流量”，包含以下三点内容：

*  背景介绍：应用架构探索的挑战；
 *  典型场景：在哪些场景下，我们需要进行应用架构的探索；
 *  最佳实践：介绍一种应用架构探索的模式，高效的发现定位问题。

### 一、应用架构探索的挑战 ###

（1）混沌的微服务架构

在 Kubernetes 容器化环境里，微服务架构是最普遍的架构模式。在这种架构下，随着业务发展，一定会有越来越多的微服务，他们之间的关系也会越来越复杂。在复杂度不断增长的情况下，一些常见架构问题就变得困难，比如应用当前运行架构是怎样的，应用下游依赖服务是否正常，应用上游客户端流量是否正常，应用 DNS 解析是否正常，两个应用之间的连通性是否有问题等。因此，我们要进行应用架构探索，往往变得十分困难。

（2）多语言

在微服务架构里面，各个微服务通常可以使用不同编程语言，只要暴露出标准的服务即可。那么不同语言如何进行监控，是否有相同的埋点模式，是否对应语言有好用高效的埋点工具呢？代码侵入对性能有什么影响，是否埋点代码会影响业务运行呢？这是多语言场景下面临的观测难题。

（3）多通信协议

在微服务架构里面，各个微服务之间的通信可以使用不同通信协议，比如 HTTP、gRPC、Kafka、Dubbo 等，往往我们需要识别这些协议才能快速发现对应依赖服务的问题，但是识别协议意味着理解各个协议，在合适的地方需要进行埋点，不同通信协议如何统一埋点代码侵入，是否会影响业务性能，这是通信协议场景下面临的观测难题。

### 二、典型场景 ###

（1）架构感知

架构感知是根据真实的网络调用，将微服务作为节点，微服务之间的调用作为边，绘制出一张拓扑图。通过对比静态设计的期望架构，我们可以发现问题，比如是不是多了或少了某个微服务，微服务之间的关系是不是正确，通常在新应用上线、新地区开服、整体链路梳理等需要关注结构大图的场景使用。

（2）架构异常发现

架构异常发现是指通过自定义架构拓扑图中节点和边的异常规则显示对应的异常颜色，能够快速发现异常的节点和边，通常在整体链路梳理和健康巡检等关注节点和边状态的场景下使用。

（3）关联分析

通过异常发现定位到某个节点或者边异常之后，我们通常需要关联关系的切换，快速查看相关节点或者边的上下游以及对应的自身服务实例，一步一步缩小问题范围。

### 三、最佳实践 ###

以上三个典型场景构成了完整的实践流程：通过架构感知观测应用实际运行架构是否和预期一致，如果有结构性问题，需要进一步排查结构异常的服务，如果没有结构性问题，我们可以进行下一步。通过异常发现观测是否有颜色异常的节点和边，如果没有其异常节点和边就最好，否则我们进行下一步，定位到特定的节点和边之后，开始进行关联分析，先分析自身实例是不是有问题，再看上下游是不是有问题。

Kubernetes 监控是如何支持最佳实践的呢？首先是Kubernetes监控集群拓扑的架构感知能力。Kubernetes 监控通过关联真实的网络请求绘制出了应用架构拓扑。当前提供 Service 和 Workload 两种视图，前者是 Service 之间的服务调用，后者是 Deployment 、Daemonset、Statefulset 之间的服务调用。

进入拓扑图，默认对节点进行分组收敛，集群内按命名空间分组，集群外按服务类型进行分组。展开分组之后可以看到对应的节点和节点关系，点击节点可以看到选定时间范围内的性能指标聚合值和时序值，这些值会按网络协议进行划分，点击边可以看到选定时间范围内的性能指标聚合值和时序值，这些值会按网络协议进行划分，再配合节点过滤，比如查看两个特定命名空间的架构关系，以及节点查询，快速查看一个节点，可以很好的对架构进行探索。

![3.png][]

再看 Kubernetes 监控的异常发现能力，Kubernetes 监控通过三个维度的异常条件，将节点和边绘制成异常的黄或者红的颜色。具体来说，这三个维度是性能指标异常，比如说错误率大于 10%，平均响应时间大于 500 毫秒；第二，资源指标异常，比如 CPU 使用率大于 70%，内存使用率大于 70%；第三，K8S 管控状态异常，比如 POD 一直无法到达 ready 状态，在分组收起的状态下会显示节点分组的异常占比，展开分组可以看到特定的节点变得异常。通过该能力，我们可以快速发现特定的微服务或者微服务关系的异常。

![4.png][]

Kubernetes 监控还具备关联分析能力，支持查看特定节点的上下游，提供 3D 视图同时查看节点关联的上下游关系和自身的实力状态，可以在一张图进行所有关联数据的探索，极大提升问题定位的效率。

![5.png][]

**四、Kubernetes  监控的产品价值**

阿里云 Kubernetes 监控是一套针对 Kubernetes 集群开发的一站式可观测性产品，它会关联起 Kubernetes 名下的所有指标、链路、日志和事件。主要具备六大特性：

*  代码无侵入：阿里云 Kubernetes 监控通过旁路技术，不需要对代码进行埋点即可获取到丰富的网络性能数据。
 *  语言无关：阿里云 Kubernetes 监控在内核层进行网络协议解析，支持任意语言、任意框架。
 *  高性能：阿里云 Kubernetes 监控基于 eBPF 技术，能以极低的消耗获取丰富的网络性能数据。
 *  资源关联：阿里云 Kubernetes 监控通过网络拓扑、资源拓扑展示相关资源的关联。
 *  数据多样：阿里云 Kubernetes 监控支持可观测的各种类型数据（监控指标、链路、日志和事件），涵盖端到端的软件栈。
 *  整体性：阿里云 Kubernetes 监控通过控制台的场景设计、关联起架构感知拓扑、应用监控、Prometheus 监控、云拨测、健康巡检、事件中心、日志服务和云服务。

那么 Kubernetes 监控、应用性能监控、Prometheus 监控有什么异同点呢？下图清晰的表达了这三者的关系和区别，应用性能监控主要关注应用逻辑，框架与编程语言，而 Kubernetes 监控关注的是系统网络和容器界面，同时会向上关联应用性能监控。Prometheus 监控是基础设施，Kubernetes 监控和应用性能监控的指标类数据将会存储在 Prometheus 监控中。

![6.png][]

[原文链接][Link 1]  
本文为阿里云原创内容，未经允许不得转载。

[1.png]: /images/20220828/ac301431f8e04daa8ecee817c5e01a06.png
[2.png]: /images/20220828/4209c9abcef441119fbae399c7d2a52d.png
[3.png]: /images/20220828/67c6bdb2c2294983b62db74098562e85.png
[4.png]: /images/20220828/b05a71fd91504dd69abd7f9494295ef2.png
[5.png]: /images/20220828/f70a709b08f74d4e9039631036a943f4.png
[6.png]: /images/20220828/7330927fe7c94c1f86b31d455f5f34e3.png
[Link 1]: http://click.aliyun.com/m/1000296934/