江华县网站开发,旅游网站推荐排行榜,灵感集网站,精准营销算法简介#xff1a; 随着 Kubernetes 的不断实践落地#xff0c;我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底#xff0c;这些问题背后都暴露出流量分布不均的问题。那么#xff0c;我们该如何发现资源使用#xff0c;解决流量分布不均问题呢#xff1f;今天…简介 随着 Kubernetes 的不断实践落地我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底这些问题背后都暴露出流量分布不均的问题。那么我们该如何发现资源使用解决流量分布不均问题呢今天我们就借助三个具体场景聊聊这一问题以及相应的解决方案。
作者炎寻
大家好我是阿里云云原生应用平台的炎寻很高兴能与大家继续分享 Kubernetes 监控系列公开课。前两期公开课我们讲到了 Vol.1《通过 Kubernetes 监控探索应用架构发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异常》。 如何使用 Kubernetes 监控的拓扑来探索应用架构使用产品采集的监控数据配置告警来发现服务性能问题。今天我们将进行第三讲《使用 Kubernetes 监控发现资源使用流量分布不均匀的问题》大家可以钉钉搜索钉群 31588365加入 Kubernetes 监控答疑群进行交流。
随着 Kubernetes 的不断实践落地我们经常会遇到越来越多问题诸如负载均衡、集群调度、水平扩展等问题。归根到底这些问题背后都暴露出流量分布不均的问题。那么我们该如何发现资源使用解决流量分布不均问题呢今天我们就借助三个具体场景聊聊这一问题以及相应的解决方案。
系统架构面临的挑战一负载均衡 通常来说对于一个业务系统架构会有很多层每层包含很多组件比如服务接入、中间件、存储我们希望每个组件的负载都是均衡的这样性能和稳定性都是最高的但在多语言多通信协议场景下快速发现以下问题具备一定难度比如
应用服务器处理的请求是否均匀应用服务器对中间件服务实例的访问流量是否均匀数据库各个分库分表实例读写流量是否均匀…
我们在实际工作实践中会遇到的典型场景就是负载不均衡线上的流量转发策略或者流量转发组件自身有问题导致应用服务各个实例接收到的请求量不均衡部分实例处理的流量显著高于其他节点导致这部分实例的性能相对于其他实例来说显著恶化那么路由到这部分实例上的请求无法得到及时的响应造成系统整体的性能和稳定性降低。 除了服务端不均匀场景之外云上用户大多使用云服务实例在实践中会出现应用服务各个实例处理的流量均匀但访问云服务实例的节点出现流量不均匀导致云服务实例整体性能和稳定性下降。通常在应用运行时整体链路梳理和特定问题节点上下游分析时会进入该场景。
那么我们如何快速发现问题、解决问题呢 针对这一问题我们可以从服务负载、请求负载这两个方面对客户端、服务端进行问题发现判断各个组件实例服务负载和对外请求负载是否均衡。
1服务端负载 对于服务端负载均衡问题排查我们需要了解服务详情对任意特定的 ServiceDeploymentDaemonSetStatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情功能我们可以看到 Pod 列表部分会列出后端的所有 Pod在表格中我们列出了每个 Pod 在选择时间段内的请求数聚合值和请求数时序通过对请求数一列进行排序我们可以清楚地看到后端的流量是否均匀。 2客户端负载
对于客户端负载均衡问题排查Kubernetes 监控提供集群拓扑功能对于任意特定的 ServiceDeploymentDaemonSetStatefulSet我们都可以查看其关联的拓扑当选定关联关系之后点击表格化会列出所有与问题实体关联的网络拓扑表格每一项都是应用服务节点对外请求的拓扑关系在表格中我们会展示每一对拓扑关系在选择时间段内的请求数聚合值和请求数时序通过对请求数一列进行排序可以清楚地看到特定节点作为客户端对特定的服务端访问是否流量均匀。
系统架构面临的挑战二集群调度
在 Kubernetes 集群部署场景下将 Pod 分发到某个节点的过程称之为调度对于每个 Pod 来说其调度过程包含了“根据过滤条件找候选节点”以及“找最好的节点”两个步骤“根据过滤条件找候选节点”除了根据 Pod 和 node 的污点忍受关系来过滤节点还有一点非常重要的就是根据资源预留的量来过滤比如节点的 CPU 只有 1 核的预留那么对于一个请求 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了根据 Pod 和 node 的亲和性来选择一般是在过滤出来的节点里面选择最空闲的。 基于上面的理论我们在实践过程中经常会遇到一些问题
为什么集群资源使用率很低却无法调度 Pod为什么部分节点资源使用率显著高于其他节点为什么只有部分节点资源无法调度…
我们在实际工作实践中会遇到的典型场景就是资源热点问题特定节点频繁发生 Pod 调度问题整个集群资源利用率极低但是无法调度 Pod。如图我们可以看到 Node1、Node2 已经调度满了 PodNode3 没有任何 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监控支持查看 ServiceDaemonsetStatefulSetDeployment 的副本数快速定位单点问题。
通过上面的介绍我们可以看到 Kubernetes 监控可以从服务端客户端多视角支持多语言多通信协议场景下的负载均衡问题排查与此同时容器节点服务的资源热点问题排查最后通过副本数检查和流量分析支持单点问题排查。在后续的迭代过程中我们会将这些检查点作为场景开关一键开启之后自动检查报警。
原文链接 本文为阿里云原创内容未经允许不得转载。
