系统架构面临的三大挑战，看 Kubernetes 监控如何解决？

2021-11-02 742

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生网关 MSE Higress，422元/月

服务治理 MSE Sentinel/OpenSergo，Agent数量不受限

应用实时监控服务-应用监控，每月50GB免费额度

简介： 随着 Kubernetes 的不断实践落地，我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底，这些问题背后都暴露出流量分布不均的问题。那么，我们该如何发现资源使用，解决流量分布不均问题呢？今天，我们就借助三个具体场景聊聊这一问题以及相应的解决方案。

作者｜炎寻

审核&校对：白玙

编辑&排版：雯燕

大家好，我是阿里云云原生应用平台的炎寻，很高兴能与大家继续分享 Kubernetes 监控系列公开课。前两期公开课我们讲到了 Vol.1《通过 Kubernetes 监控探索应用架构，发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异常》。

如何使用 Kubernetes 监控的拓扑来探索应用架构，使用产品采集的监控数据配置告警来发现服务性能问题。今天我们将进行第三讲《使用 Kubernetes 监控发现资源使用，流量分布不均匀的问题》，大家可以钉钉搜索钉群 31588365，加入 Kubernetes 监控答疑群进行交流。

随着 Kubernetes 的不断实践落地，我们经常会遇到越来越多问题，诸如负载均衡、集群调度、水平扩展等问题。归根到底，这些问题背后都暴露出流量分布不均的问题。那么，我们该如何发现资源使用，解决流量分布不均问题呢？今天，我们就借助三个具体场景聊聊这一问题以及相应的解决方案。

系统架构面临的挑战一：负载均衡

图片 1.png

通常来说，对于一个业务系统，架构会有很多层，每层包含很多组件，比如服务接入、中间件、存储，我们希望每个组件的负载都是均衡的，这样性能和稳定性都是最高的，但在多语言多通信协议场景下，快速发现以下问题具备一定难度，比如：

应用服务器处理的请求是否均匀？
应用服务器对中间件服务实例的访问流量是否均匀？
数据库各个分库分表实例读写流量是否均匀？
…

我们在实际工作实践中会遇到的典型场景就是负载不均衡，线上的流量转发策略或者流量转发组件自身有问题，导致应用服务各个实例接收到的请求量不均衡，部分实例处理的流量显著高于其他节点，导致这部分实例的性能相对于其他实例来说显著恶化，那么路由到这部分实例上的请求无法得到及时的响应，造成系统整体的性能和稳定性降低。

图片 2.png

除了服务端不均匀场景之外，云上用户大多使用云服务实例，在实践中会出现应用服务各个实例处理的流量均匀，但访问云服务实例的节点出现流量不均匀，导致云服务实例整体性能和稳定性下降。通常在应用运行时整体链路梳理和特定问题节点上下游分析时，会进入该场景。

那么，我们如何快速发现问题、解决问题呢？针对这一问题，我们可以从服务负载、请求负载这两个方面对客户端、服务端进行问题发现，判断各个组件实例服务负载和对外请求负载是否均衡。

（1）服务端负载

图片 3.png

对于服务端负载均衡问题排查，我们需要了解服务详情，对任意特定的 Service，Deployment，DaemonSet，StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情功能，我们可以看到 Pod 列表部分会列出后端的所有 Pod，在表格中我们列出了每个 Pod 在选择时间段内的请求数聚合值和请求数时序，通过对请求数一列进行排序，我们可以清楚地看到后端的流量是否均匀。

图片 4.png

（2）客户端负载

对于客户端负载均衡问题排查，Kubernetes 监控提供集群拓扑功能，对于任意特定的 Service，Deployment，DaemonSet，StatefulSet，我们都可以查看其关联的拓扑，当选定关联关系之后，点击表格化会列出所有与问题实体关联的网络拓扑，表格每一项都是应用服务节点对外请求的拓扑关系，在表格中我们会展示每一对拓扑关系在选择时间段内的请求数聚合值和请求数时序，通过对请求数一列进行排序，可以清楚地看到特定节点作为客户端对特定的服务端访问是否流量均匀。

系统架构面临的挑战二：集群调度

在 Kubernetes 集群部署场景下，将 Pod 分发到某个节点的过程称之为调度，对于每个 Pod 来说，其调度过程包含了“根据过滤条件找候选节点”以及“找最好的节点”两个步骤，“根据过滤条件找候选节点”除了根据 Pod 和 node 的污点，忍受关系来过滤节点，还有一点非常重要的就是根据资源预留的量来过滤，比如节点的 CPU 只有 1 核的预留，那么对于一个请求 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了根据 Pod 和 node 的亲和性来选择，一般是在过滤出来的节点里面选择最空闲的。

图片 5.png

基于上面的理论，我们在实践过程中经常会遇到一些问题：

为什么集群资源使用率很低却无法调度 Pod？
为什么部分节点资源使用率显著高于其他节点？
为什么只有部分节点资源无法调度？
…

我们在实际工作实践中会遇到的典型场景就是资源热点问题，特定节点频繁发生 Pod 调度问题，整个集群资源利用率极低但是无法调度 Pod。如图，我们可以看到 Node1、Node2 已经调度满了 Pod，Node3 没有任何 Pod 调度上去，这个问题对跨 region 容灾高可用，整体的性能都有影响。我们通常在 Pod 调度失败会进入到该场景。

那么，我们该如何处理呢？

图片 6.png

对于 Pod 无法调度的问题排查，我们通常应该关注到下面三个要点：

节点有 Pod 数量调度上限
节点有 CPU 请求调度上限
节点有内存请求调度上限

图片 7.png

Kubernetes 监控提供的集群节点列表展示以上三个要点。通过排序去查看各个节点是否均匀来查看资源热点问题。比如，某个节点 CPU 请求率接近 100%，那么就意味着任何对 CPU 有请求的 Pod 都无法调度到该节点上，如果说只有个别节点的 CPU 请求率接近 100%，其他节点都十分空闲，就需要检查一下该节点的资源容量和 Pod 分布，进一步排查问题。

除了节点有资源热点问题之外，容器也有资源热点问题。如图，对于一个多副本服务来说，其容器的资源使用分布也可能有资源热点问题，主要体现在 CPU 和内存使用上，CPU 在容器环境中是可压缩资源，达到上限之后只会限制，不会对容器本身生命周期造成影响，而内存在容器环境中是不可压缩资源，达到上限之后会出现 OOM，由于每个节点运行的时候虽然处理的请求量一致，但是不同请求不同参数导致的 CPU 和内存消耗可能不一样，那么这样会导致部分容器的资源出现热点，对生命周期和自动扩缩容都会造成影响。

针对容器的资源热点问题，通过理论分析，我们需要关注的要点如下：

CPU 是可压缩资源
内存是不可压缩资源
Requests 用于调度
Limits 用于运行时资源限制隔离

图片 8.png

Kubernetes 监控在服务详情的 Pod 列表展示以上四个要点，支持排序，通过查看各个 Pod 是否均匀来查看资源热点问题，比如某个 Pod CPU 使用/请求率接近 100%，那么就意味着可能触发自动扩缩容，如果说只有个别 Pod 的 CPU 使用/请求率接近 100%，其他节点都十分空闲，就需要检查处理逻辑，进一步排查问题。

系统架构面临的挑战三：单点问题

对于单点问题而言，其本质就是高可用问题。高可用问题解法只有一个，就是冗余，多节点，多 region，多 zone，多机房，越分散越好，越冗余越好。除此之外，在流量增长，组件压力增大的情况下，系统各组件是否可以水平扩展也成为一个重要的议题。

图片 9.png

单点问题，应用服务只有最多 1 个节点，当该节点因为网络或者其他问题中断，无法通过重启解决时，系统崩溃，与此同时，因为只有一个节点，当流量增长超过一个节点的处理能力时，系统整体的性能表现会严重恶化，单点问题会影响系统的性能和高可用能力，针对该问题，Kubernetes监控支持查看 Service，Daemonset，StatefulSet，Deployment 的副本数，快速定位单点问题。

通过上面的介绍我们可以看到 Kubernetes 监控可以从服务端，客户端多视角支持多语言多通信协议场景下的负载均衡问题排查，与此同时容器，节点，服务的资源热点问题排查，最后通过副本数检查和流量分析支持单点问题排查。在后续的迭代过程中，我们会将这些检查点作为场景开关，一键开启之后自动检查，报警。

目前，Kubernetes 监控免费使用中。点击阅读原文，开启 ARMS 即可使用。
Kubernetes 监控答疑钉钉群（群号：31588365）

钉群二维码裁剪后 .png