共计 3226 个字符，预计需要花费 9 分钟才能阅读完成。
简介：随着 Kubernetes 的一直实际落地，咱们常常会遇到负载平衡、集群调度、程度扩大等问题。归根到底，这些问题背地都暴露出流量散布不均的问题。那么，咱们该如何发现资源应用，解决流量散布不均问题呢？明天，咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。
作者|炎寻
大家好，我是阿里云云原生利用平台的炎寻，很快乐能与大家持续分享 Kubernetes 监控系列公开课。前两期公开课咱们讲到了 Vol.1《通过 Kubernetes 监控摸索利用架构，发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异样》。
如何应用 Kubernetes 监控的拓扑来摸索利用架构，应用产品采集的监控数据配置告警来发现服务性能问题。明天咱们将进行第三讲《应用 Kubernetes 监控发现资源应用，流量散布不平均的问题》，大家能够钉钉搜寻钉群 31588365，退出 Kubernetes 监控答疑群进行交换。
随着 Kubernetes 的一直实际落地，咱们常常会遇到越来越多问题，诸如负载平衡、集群调度、程度扩大等问题。归根到底，这些问题背地都暴露出流量散布不均的问题。那么，咱们该如何发现资源应用，解决流量散布不均问题呢？明天，咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。
零碎架构面临的挑战一：负载平衡
通常来说，对于一个业务零碎，架构会有很多层，每层蕴含很多组件，比方服务接入、中间件、存储，咱们心愿每个组件的负载都是平衡的，这样性能和稳定性都是最高的，但在多语言多通信协议场景下，疾速发现以下问题具备肯定难度，比方：
- 应用服务器解决的申请是否平均？
- 应用服务器对中间件服务实例的拜访流量是否平均？
- 数据库各个分库分表实例读写流量是否平均？
- …
咱们在理论工作实际中会遇到的典型场景就是负载不平衡，线上的流量转发策略或者流量转发组件本身有问题，导致应用服务各个实例接管到的申请量不平衡，局部实例解决的流量显著高于其余节点，导致这部分实例的性能绝对于其余实例来说显著好转，那么路由到这部分实例上的申请无奈失去及时的响应，造成零碎整体的性能和稳定性升高。
除了服务端不平均场景之外，云上用户大多应用云服务实例，在实践中会呈现应用服务各个实例解决的流量平均，但拜访云服务实例的节点呈现流量不平均，导致云服务实例整体性能和稳定性降落。通常在利用运行时整体链路梳理和特定问题节点上下游剖析时，会进入该场景。
那么，咱们如何疾速发现问题、解决问题呢？针对这一问题，咱们能够从服务负载、申请负载这两个方面对客户端、服务端进行问题发现，判断各个组件实例服务负载和对外申请负载是否平衡。
（1）服务端负载
对于服务端负载平衡问题排查，咱们须要理解服务详情，对任意特定的 Service，Deployment，DaemonSet，StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情性能，咱们能够看到 Pod 列表局部会列出后端的所有 Pod，在表格中咱们列出了每个 Pod 在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，咱们能够分明地看到后端的流量是否平均。
（2）客户端负载
对于客户端负载平衡问题排查，Kubernetes 监控提供集群拓扑性能，对于任意特定的 Service，Deployment，DaemonSet，StatefulSet，咱们都能够查看其关联的拓扑，入选定关联关系之后，点击表格化会列出所有与问题实体关联的网络拓扑，表格每一项都是应用服务节点对外申请的拓扑关系，在表格中咱们会展现每一对拓扑关系在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，能够分明地看到特定节点作为客户端对特定的服务端拜访是否流量平均。
零碎架构面临的挑战二：集群调度
在 Kubernetes 集群部署场景下，将 Pod 散发到某个节点的过程称之为调度，对于每个 Pod 来说，其调度过程蕴含了“依据过滤条件找候选节点”以及“找最好的节点”两个步骤，“依据过滤条件找候选节点”除了依据 Pod 和 node 的污点，忍耐关系来过滤节点，还有一点十分重要的就是依据资源预留的量来过滤，比方节点的 CPU 只有 1 核的预留，那么对于一个申请 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了依据 Pod 和 node 的亲和性来抉择，个别是在过滤出来的节点外面抉择最闲暇的。
基于下面的实践，咱们在实际过程中常常会遇到一些问题：
- 为什么集群资源使用率很低却无奈调度 Pod？
- 为什么局部节点资源使用率显著高于其余节点？
- 为什么只有局部节点资源无奈调度？
- …
咱们在理论工作实际中会遇到的典型场景就是资源热点问题，特定节点频繁产生 Pod 调度问题，整个集群资源利用率极低然而无奈调度 Pod。如图，咱们能够看到 Node1、Node2 曾经调度满了 Pod，Node3 没有任何 Pod 调度下来，这个问题对跨 region 容灾高可用，整体的性能都有影响。咱们通常在 Pod 调度失败会进入到该场景。
那么，咱们该如何解决呢？
对于 Pod 无奈调度的问题排查，咱们通常应该关注到上面三个要点：
- 节点有 Pod 数量调度下限
- 节点有 CPU 申请调度下限
- 节点有内存申请调度下限
Kubernetes 监控提供的集群节点列表展现以上三个要点。通过排序去查看各个节点是否平均来查看资源热点问题。比方，某个节点 CPU 申请率靠近 100%，那么就意味着任何对 CPU 有申请的 Pod 都无奈调度到该节点上，如果说只有个别节点的 CPU 申请率靠近 100%，其余节点都非常闲暇，就须要检查一下该节点的资源容量和 Pod 散布，进一步排查问题。
除了节点有资源热点问题之外，容器也有资源热点问题。如图，对于一个多正本服务来说，其容器的资源应用散布也可能有资源热点问题，次要体现在 CPU 和内存应用上，CPU 在容器环境中是可压缩资源，达到下限之后只会限度，不会对容器自身生命周期造成影响，而内存在容器环境中是不可压缩资源，达到下限之后会呈现 OOM，因为每个节点运行的时候尽管解决的申请量统一，然而不同申请不同参数导致的 CPU 和内存耗费可能不一样，那么这样会导致局部容器的资源呈现热点，对生命周期和主动扩缩容都会造成影响。
针对容器的资源热点问题，通过实践剖析，咱们须要关注的要点如下：
- CPU 是可压缩资源
- 内存是不可压缩资源
- Requests 用于调度
- Limits 用于运行时资源限度隔离
Kubernetes 监控在服务详情的 Pod 列表展现以上四个要点，反对排序，通过查看各个 Pod 是否平均来查看资源热点问题，比方某个 Pod CPU 应用 / 申请率靠近 100%，那么就意味着可能触发主动扩缩容，如果说只有个别 Pod 的 CPU 应用 / 申请率靠近 100%，其余节点都非常闲暇，就须要查看解决逻辑，进一步排查问题。
零碎架构面临的挑战三：单点问题
对于单点问题而言，其本质就是高可用问题。高可用问题解法只有一个，就是冗余，多节点，多 region，多 zone，多机房，越扩散越好，越冗余越好。除此之外，在流量增长，组件压力增大的状况下，零碎各组件是否能够程度扩大也成为一个重要的议题。
单点问题，应用服务只有最多 1 个节点，当该节点因为网络或者其余问题中断，无奈通过重启解决时，零碎解体，与此同时，因为只有一个节点，当流量增长超过一个节点的解决能力时，零碎整体的性能体现会重大好转，单点问题会影响零碎的性能和高可用能力，针对该问题，Kubernetes 监控反对查看 Service，Daemonset，StatefulSet，Deployment 的正本数，疾速定位单点问题。
通过下面的介绍咱们能够看到 Kubernetes 监控能够从服务端，客户端多视角反对多语言多通信协议场景下的负载平衡问题排查，与此同时容器，节点，服务的资源热点问题排查，最初通过正本数检查和流量剖析反对单点问题排查。在后续的迭代过程中，咱们会将这些检查点作为场景开关，一键开启之后主动查看，报警。
原文链接
本文为阿里云原创内容，未经容许不得转载。
