4

G行探索全栈云容器环境降本增效之路——基础篇

 1 year ago
source link: https://www.51cto.com/article/775525.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

G行探索全栈云容器环境降本增效之路——基础篇

作者：王雷硕 2023-12-05 07:31:26
本文首先介绍容器环境各层使用资源的背景，通过生产环境的资源使用实践，分析造成资源使用率低于预期的原因，最后提出相应解决方案。

资源使用背景

当前众多金融企业开始将业务应用进行容器化部署，以期实现业务应用开发的敏捷迭代、运行环境的快速部署、业务负载的弹性伸缩、应用系统的全生命周期管理等效果。助力企业金融科技创新和金融场景创新，拓宽金融业行业边界，让金融服务内容更加多元，挖掘用户更多潜在需求，提升用户黏性和服务体验，全面增强企业竞争力。

当前上云用云作为G行数字化转型的关键一步已走到决定性阶段。从内部来看，随着上云由外围系统过渡到核心系统，用云进入深水区，目标从如何上云用云，变成如何用好云。安全可靠、控制成本和优化性能是目前G行云使用方案需要关注的三个重要维度。从外部来看，一方面全球经济下行处于下行期，另一方面近期一些互联网头部企业相继发生系统崩溃事件，促使业界对云使用的资源优化和安全运行讨论又一次达到高峰。

在云资源降本增效的过程中，我们目标是要降本不降质，不能以降低系统稳定性、效率、安全运营等为代价。本文基于有效保障业务平稳运行的前提下，探索常见容器环境的资源优化方法，对如何提升资源利用率，控制云成本做出思考和总结。

资源使用背景

为方便理解，我们将容器环境应用架构分为如图1所示的应用层、调度层、资源层。逐一阐述各层资源使用情况。

图1 容器环境应用基础架构
图1 容器环境应用基础架构

Kubernetes 使用了Request（请求）和Limit（限额）来描述容器对CPU和内存资源的需求。

Request：容器预留的资源量。即便容器没有实际使用到这些资源，Kubernetes也会为容器预留好这些资源，其他容器无法在资源池内申请这些资源。

Limit：限制容器使用的资源上限。容器在实际运行的时候不能超过的资源阈值。如果容器使用的资源超过了这个值，就会触发K8s后续对应的操作。对于CPU来说，由于CPU 是可压缩资源，所以如果容器使用的CPU超过了 limit 设置的值，会导致CPU节流服务降级，影响应用处理速度。但对于内存这种不可压缩资源，如果内存的使用量超过了limit的值，则会触发OOMKilled。

G行在业务的实际使用中，为大部分服务设置Request和Limit，同时Limit是Request的2倍以上（Limit比Request大，实际是对物理资源的一种超卖）。在图2中，从G行某集群工作节点CPU使用线性图可以看出，CPU限制率为209.14%，节点上的应用超卖109.14%。通过应用资源配置进行一定程度的超卖，增加Pod的部署密度，可以有效提升集群整体的利用率。

图2 集群工作节点应用CPU超卖情况
图2 集群工作节点应用CPU超卖情况

在Kubernetes中，调度是指将Pod放置到合适的节点上，以便节点上的Kubelet能够运行这些Pod。原生Kubernetes调度器Kube-scheduler给一个Pod做调度选择时包含两个阶段—预选和优选。

预选阶段会将所有满足Pod调度需求的节点选出来。其中PodFitsResurces策略会检查候选节点的可用资源是否满足Pod的Request资源请求。

优选阶段会对每个通过预选的节点优先级打分。其中LeastRequestedPriority策略会优先从预选节点列表选择资源占用最小的节点。BalancedResourceAllocation策略会优先从预选节点选择CPU和内存占用率最均衡的节点。

从原生Kubernetes调度器的策略可以看出，Pod请求值Request配置的准确性直接影响集群节点资源利用率和集群负载的均衡性。

Node节点资源并不能完全被Pod所使用，这就引入了一个问题，Kubernetes如何划分节点上的计算资源。Kubernetes将节点上的计算资源分为如图3所示几部分，其中：

  • System Reserved：系统保留的计算资源，不能被Kubernetes调度和使用，比如 sshd 等等。
  • Kubernetes Reserved：Kubernetes为Dockerd、Kubelet、Kube-proxy等保留的计算资源，这部分保证Kubernetes正常工作。
  • Eviction Thread：当节点内存或磁盘资源紧张时达到阈值，kubelet会根据Pod 的 QoS优先级回收Pod占用的资源。
  • Fragments Resource：通常情况下，Node节点上会剩余一些资源碎片，这些资源无法满足调度Pod的资源需求。
  • Node Allocatable Capacity: 能够被Kubernetes调度和使用的计算资源，它的计算方法为：[Node Allocatable Capacity] = [Node Capacity] - [System Reserved] - [Kubernetes Reserved] - [Eviction Thread] - [Fragments Resource]
图3 Node节点维度的计算资源
图3 Node节点维度的计算资源

资源未能充分使用原因

  • 采用传统资源评估分配方法进行云上资源分配

容器资源规格Resource Request和Limit的填写让Kubernetes的使用者困惑，应用管理员需要预留较多的冗余资源，来应对流量的波动，保障业务运行的稳定性，导致资源冗余性有余，利用率不足。在图4中，某教学类系统CPU请求率为2%到5%（请求率=使用值/请求值），资源规格Request值设置有冗余，资源利用率有一定的提升空间。

图4 教学类项目资源使用率
图4 教学类项目资源使用率
  • 对容器的自动弹性能力保持谨慎，按需自动扩缩容未能有效运用

在应用层开启弹性能力赋能业务是我们需要重点考虑的问题。容器秒级启动的特性，让我们可以在业务中利用弹性扩缩容按需分配资源。G行在研究探索过程中发现在线类交易业务流量存在波峰波谷现象，若此类业务开启弹性扩缩容，会避免大量资源浪费。图5为某在线交易项目微服务模块的CPU使用率情况，我们可以看到该业务每天会有突发性流量高峰，其他时间段流量处于较低的水平，有明显的流量波峰和波谷的特征。非常适合利用容器的极速弹性能力实现资源优化。

图5 在线交易项目微服务模块CPU使用率
图5 在线交易项目微服务模块CPU使用率
  • 原生调度无法满足实际使用场景

Kubernetes默认使用原生调度器Kube-scheduler，它的主要职责是为一个新创建出来的 Pod，寻找一个最合适的 Node节点。G行在探索过程中发现由于原生 Kubernetes 调度器只能基于资源的 Resource Request 进行调度，有些节点 Pod 的真实资源使用率，往往与其所申请资源的Request差异很大，这直接导致集群负载不均的问题和部分节点的资源使用不充分。Kubernetes 原生调度与资源绑定功能已经无法满足复杂的算力场景。图6为某集群节点的CPU使用率，从中可以看到使用原生调度器的场景下每个节点的CPU使用率并不均匀并且存在个别节点资源使用不充分的情况。

图6 集群节点CPU使用率
图6 集群节点CPU使用率
  • 资源碎片使资源池无法充分利用

由于 Kubernetes 调度程序无法预测未来的 Pod 大小和节点添加，随着时间的推移，最终会导致任何节点都无法满足Pod的资源调度，即使节点上可能剩余很多资源。这样就产生一个假的资源紧张现象。结合图7和图8展示的G行某集群节点CPU资源使用情况和Pod业务资源规格可以看出节点计算资源总量为16核，已请求13.15核，但业务的请求规格为4核，这直接导致节点有至少2核的资源碎片无法被其他Pod调度。

图7 G行某集群节点CPU使用情况
图7 G行某集群节点CPU使用情况
图8 G行某集群Pod业务资源规格

资源优化措施

通过分析上面影响资源利用率的原因做出以下相应改进措施。

  • 结合云的特性优化资源评估方法，规范调配常驻资源

针对使用方普遍存在的过度申请冗余资源的情况。在资源申请方面，G行通过非功能测试评估业务部门未来一段时间的业务规划，梳理出合规并有一定冗余量的资源规格；在资源优化方面，通过持续收集容器的资源用量，进行汇总分析，根据历史数据和智能算法为每个容器生成资源规格的合理推荐值，沉淀形成资源评估分配规范标准；在资源运营方面，强化资源使用跟踪，监控资源运行数据，按日发布资源利用率情况，按月发布项目运营分析报告及综合效能评分，协助各项目组优化资源部署，提升资源效能。

从图9展示的资源利用率变化趋势图可以看出，针对某电子化项目资源利用率低的问题做出整改措施后，利用率有明显的上升变化。

图9 某电子化项目资源使用优化趋势图
图9 某电子化项目资源使用优化趋势图
  • 在充分测试后，有效推进弹性技术赋能业务

在线类业务的使用量会根据负载情况出现波动，所以在设置资源规格时应该充分考虑周期性特点使用弹性资源，以便业务在流量谷底可以降低资源使用，而在高峰之前又能及时提升能力。Kubernetes提供了自动扩展功能，如基于指标的自动水平弹性扩缩容HPA，可以根据工作负载的 CPU 或内存使用率自动扩缩 Pod 副本数，通过使用弹性能力实现资源按需分配。

从图10和图11可以看到某业务在CPU负载超过目标阈值45秒后，Pod自动扩容到3副本。弹性扩缩容帮助业务减少冗余资源的设置、规避容量风险。

图10 扩容CPU平均使用率
图10 扩容CPU平均使用率
图11 扩容Pod副本数
图11 扩容Pod副本数
  • 调度感知实际资源负载

由于原生Kubernetes调度器依赖于Request 静态配置，而不是基于实际节点的负载情况调度Pod，因此会出现集群各个节点负载不均衡的现象。我们期望动态获取当前节点  的实时资源水位，据此打分从而干预调度结果，平衡各个计算节点的资源使用，充分发挥资源池的资源供给。

  • 资源碎片再平衡

原生Kubernetes调度器会根据当时集群的资源描述做出最佳的调度决定，但基于静态数据的调度有时并不能适应之后资源的动态变化，我们期望通过识别和迁移节点间的特定 Pod 来实现可用资源片段的整合，解决资源池的资源碎片，更充分利用好现有资源，节省不必要的开支。

本文首先介绍容器环境各层使用资源的背景，通过生产环境的资源使用实践，分析造成资源使用率低于预期的原因，最后提出相应解决方案。

云上资源优化并不是盲目追求低成本，而是在业务价值得到保障前提下有效提高投入产出比。优化需要统筹多方指标达到最优解，任何时候都不能忽视系统安全性、稳定性、可扩展性和性能，这样才能取得最优效果。总之，上云用云是个循序渐进的过程，云上资源优化也是反复迭代过程，需要覆盖业务上云全周期形成闭环、持续跟踪、持续分析、持续优化最终达到最佳效果。

本文是介绍G行全栈云容器环境降本增效之路的入门文章，之后会不定期更新系列文章介绍G行容器云资源优化实践和效益，助力充分发挥云效能，服务好广大客户。

责任编辑：武晓燕 来源： 匠心独运维妙维效

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK