开发者学堂课程【使用Kubernetes监控发现资源使用，流量分布不均匀的问题：使用 Kubernetes 监控发现资源使用流量分布不均匀的问题】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/949/detail/14761
使用 Kubernetes 监控发现资源使用流量分布不均匀的问题
内容介绍：
一、课程介绍
二、背景介绍
三、Demo 环节
四、产品价值
一、课程介绍
1、背景介绍
2、典型场景
3、最佳实践
首先是背景介绍，说明系统架构在资源流量不均场景下所面临的挑战，然后是典型场景，介绍在实际工作实践中会遇到的问题，最后是最佳实践，描述如何使用 Kubernetes 监控来处理这些场景，快速定位、发现问题。
二、背景介绍
1、系统架构面临的挑战一：负载均衡
通常来说对于一个业务系统架构会分为很多层，每层包含很多组件，比如服务接入、中间件、存储，我们希望每个组件的负载都是均衡的，这样性能和稳定性都是最高的，但是在多语言、多通信协议场景下，快速发现以下问题，具备一定难度，比如应用服务器处理的请求是否均匀；应用服务器对中间件服务实例的访问流量是否均匀；数据库的分库分表实例读写流量是否均匀。
在实践中会遇到的典型问题就是负载不均衡，线上的流量转发策略或者流量转发组件自身有问题，导致应用服务各个实例接收到的请求量不均衡，部分实例处理的流量显著高于其他节点，导致这部分实例的性能，相对于其他实力来说显著恶化，那么路由到这部分实力上的请求无法得到及时的响应，造成系统整体的性能和稳定性降低，以上描述的是服务端不均匀的场景。
除此之外，云上用户大多使用云服务实力，在实践中会出现应用服务本身任何实例处理的流量是均匀的，但是访问云服务实例的节点出现流量不均匀的场景，导致云服务实例整体的性能和稳定性下降，进而影响上层业务的性能和稳定性，通常我们在应用运行时进行整体链路梳理和特定问题节点上下游分析时，我们会进入到这样的一个场景。
l 如何快速发发现负载不均衡的问题
(1) 对于服务端负载均衡问题排查，Kubernetes 监控提供服务详情
功能。
对于任意特定的 service deployment ，都可以进入到其详情页，其 Pod 列表部分会列出后端的所有 Pod,在表格中每一项都列出了每个 port 在选定时间段内的请求数据、值以及请求数的持续，通过对请求数一列进行排序，我们可以清楚的看到后端的流量是否均匀，从而发现服务端负载不均衡的问题。
(2) 对于客户端负载均衡问题排查 Kubernetes 监控提供集群拓扑功
能
对于任意特定的 service deployment ，都可以查看其关联的拓朴，当选定关联关系之后，点击表格会列出所有与该实体关联的网络拓朴，表格的每一项都是应用服务节点对外请求的拓扑关系。在表格中，对每一对拓扑关系都展示了在选定时间段内的请求数据和值以及请求数持续，通过对请求数一列进行排序，我们可以清楚的看到特定节点作为客户端对特定的服务端访问是否流量均匀。
2、系统架构面临的挑战二：集群调度
在 Kubernetes 集群部署场景下，将 pod 分发到某个节点的过程称之为调度，对于每个 pod 来说，其调度过程包含了根据过滤条件找候选节点以及找最好的节点，两个步骤。
步骤一：根据过滤条件找候选节点
除了根据 pod 和 node 的污点和忍受关系来过滤节点之外，还有一点非常重要的就是根据资源预留的量来过滤，比如节点 cpu 只有一盒的预留，则对于一个请求两盒的 pod 来说，该节点将被过滤掉。
步骤二：找最好的节点
除了根据 pod 和 note 的亲和性来选择，一般会在过滤出来的节点里面选择最空闲的，基于上面的理论，在实践过程中经常会遇到以下问题：
1) 为什么集群资源使用率很低却无法调度 pod?
2) 为什么部分节点资源利用率显著高于其他节点？
3) 为什么只有部分节点资源无法进行调度？
l 在实际工作实践中会遇到的问题就是资源热点问题，特定节点频繁发生 pod 调度问题,整个集群资源利用率极低，但是无法调度 pod。
如图我们可以看到 Node1、Node2已经调度满了，而 Node3没有任何 pod 调度上去,这个问题对跨 Region 整体的性能都有影响。
通常出现了 pod 调度失败会进入到该场景，那如何快速发现定位这个问题呢？
对于 pod 无法调度的问题排查，根据上面的调度理论，我们应该关注到三个要点：
1) 节点有 pod 的数量调度上限
2) 节点有 cpu 请求调度上限
3) 节点有内存请求调度上限
Kubernetes 监控提供集群节点列表展示以上三个要点，支持排序，通过查看各个节点是否均匀来查看资源热点问题。比如某个节点 cpu 请求率接近100%，就意味着任何对 cpu 有请求的 pod 都无法调度到该节点上，即使他的 cpu 使用率低于30%；如果说只有个别节点的 cpu 请求率接近100%，其他节点十分空闲，那么需要进一步检查该节点的资源总量和 pod 分布来进一步排查问题。
除了节点有资源热点问题之外，容器也有资源热点问题
如图对于一个多副本服务来说，其容器的资源使用分布也可能有资源热点问题，主要体现在 cpu 和内存使用上。cpu在容器环境中是可压缩资源，达到上限之后只会限制，不会对容器本身生命周期造成影响，而内存在容器环境中是不可压缩资源，达到上限之后会出现 oom。对于每个节点运行的时候，虽然处理的请求量一致，但是不同请求不同参数导致的 cpu 和内存消耗可能不一样，这样就会导致部分容器出现资源热点问题，对生命周期和自动扩缩容都会造成影响。
如何快速发现定位容器的资源热点问题呢？
针对容器的资源热点问题，通过理论分析，需要关注的要点如下：
1) cpu 是可压缩资源
2) 内存是不可压缩资源资源
3) 资源请求用于调度
4) 资源限制用于运行时的资源限制合理
Kubernetes 监控在服务详情的 pod 列表展示以上四个要点，支持排序，通过查看各个 pod 是否均匀来查看资源热点问题。比如某个 pod 的 cpu 使用相对请求的比率接近100%，那么就意味着可能触发自动扩缩容；如果说只有个别节点的 cpu 请求相对使用的比率接近100%，其他节点都十分空闲，那么就需要检查处理逻辑，进一步排查问题。
3、系统架构面临的挑战三：单点问题
单点问题本质是高可用问题，高可用问题的解法本质只有一个，就是冗余。通过多节点多危险多区域多机房的方式进行冗余，越分散越好，越冗余越好。
除此之外，在流量增长、组件压力增大的情况下，系统各组件是否可以水平扩展也成为一个重要议题。
比如应用服务只有最多一个节点，当该节点因为网络或者其他问题中断无法通过重启解决时，系统将崩溃，与此同时，因为只有一个节点，当流量增长超过一个各节点的处理能力时，系统整体的性能会严重恶化，所以单点问题会严重影响系统的性能和高可用能力，针对该问题 Kubernetes 监控支持查看资源的副本数，用于快速定位单点问题。
三、Demo 环节
本环节介绍 Kubernetes 监控解决以上三个场景的产品能力。
1、负载均衡问题
进入到 Kubernetes 的监控集群盖的页面，如果发现某个 service 错误率比较高，若想查看是否是负载均衡导致的问题，可以点击 service 名称进入到 service 的详情页，
下拉移动到 pod 列表区域，在该区域通过对请求数进行排序来查看是否流量均匀。操作后可以看到该集群的 getDNS服务流量处理是均匀的。
从服务端的角度观察均匀之后，移动到拓扑区域，通过查看它的下游，点击表格化，每一项都会展示 Kubernetes DNS service 和外部服务的拓扑关系，通过对请求数进行排序，可以查看该 service 对外请求的均匀情况，
可以看到 Kubernetes 对外部的 DNS 服务的请求也是均匀的，由此可以判断 Kubernetes DNS 无论是从服务端还是客户端视角都达到了负载均衡状态。
2、集群调度的问题
进入到集群资源概览页面，向下拖动到 node 资源概览部分，查看全部 note，在这里可以看到每个 note 的 pod 数、CPU 请求率和内存请求率，通过对这些进行排序，可以看到部分节点请求率显著高于其他节点。
在这种情况下，我们可以进入到该节点，进一步分析其 pod 分布，对 pod 的 cpu 请求率和内存请求率进行排序，找到贪婪的 pod 对其进行处理，即可解决资源热点问题。
3、单点问题
回到集群资源页面，以 KubeDNS 为例，进入到其详情页面，切换到 deployment，进入到 KubeDNS，通过查看YAML 可以查看到其副本数，没有单点问题。
与此同时，可以查看其扩展列表区域，可以看到容器的资源没有产生热点。
四、产品价值
通过上面的介绍，可以看到 Kubernetes 监控可以从服务端、客户端多视角支持多语言、多通信协议场景下的负载均衡问题排查，与此同时，也支持容器节点服务的资源热点问题排查，最后通过副本数检查和流量分析，支持单点问题排查，在后续的迭代过程中，将会把这些检查点作为场景开关，支持一键开启之后自动检查报警。
