关于腾讯云:在腾讯云容器服务-TKE-中利用-HPA-实现业务的弹性伸缩

6次阅读

共计 2595 个字符，预计需要花费 7 分钟才能阅读完成。

Kubernetes Pod 程度主动扩缩（Horizontal Pod Autoscaler，以下简称 HPA）能够基于 CPU 利用率、内存利用率和其余自定义的度量指标主动扩缩 Pod 的正本数量，以使得工作负载服务的整体度量程度与用户所设定的目标值匹配。本文将介绍和应用腾讯云容器服务 TKE 的 HPA 性能实现 Pod 主动程度扩缩容。

HPA 主动伸缩个性使容器服务具备非常灵活的自适应能力，可能在用户设定内疾速扩容多个 Pod 副原本应答业务负载的急剧飙升，也能够在业务负载变小的状况下依据理论状况适当缩容来节俭计算资源给其余的服务，整个过程自动化毋庸人为干涉，非常适合服务稳定较大，服务数量多且须要频繁扩缩容的业务场景，如：电商服务、线上教育、金融服务等。

Pod 程度主动扩缩个性由 Kubernetes API 资源和控制器实现。资源利用指标决定控制器的行为，控制器会周期性的依据 Pod 资源利用状况调整服务 Pod 的正本数量，以使得工作负载的度量程度与用户所设定的目标值匹配。其扩缩容流程和阐明如下：

提醒：目前这一性能处于 beta 版本，且 Pod 主动程度扩缩不适用于无奈扩缩的对象，比方 DaemonSet 资源。

HPA Controller：管制 HPA 扩缩逻辑的管制组件。

Metrics Aggregator：度量指标聚合器。通常状况下，控制器将从一系列的聚合 API（metrics.k8s.io、custom.metrics.k8s.io 和 external.metrics.k8s.io）中获取度量值。metrics.k8s.io API 通常由 Metrics 服务器提供，社区版可提供根本的 CPU、内存度量类型，相比于社区版，TKE 应用自定义 Metrics Server 采集可反对更宽泛的的 HPA 的度量指标触发类型，提供包含 CPU、内存、硬盘、网络和 GPU 相干指标，理解更多具体内容参阅 TKE 主动伸缩指标阐明。

提醒：控制器也能够间接从 Heapster 获取指标。但自 Kubernetes 1.11 起，从 Heapster 获取指标个性的形式已废除。

HPA 计算指标正本数算法 ：TKE HPA 扩缩容算法请参考工作原理，更多具体算法请参阅算法细节。

已注册腾讯云账户。
已登录腾讯云容器服务控制台。
已创立 TKE 集群。对于创立集群，详情请参见创立集群。

第 1 步：部署测试工作负载

以 Deployment 资源类型的工作负载为例，创立一个单正本数，服务类型为 WEB 服务的 “hpa-test” 工作负载，在 TKE 控制台创立 Deployment 类型工作负载办法请参阅 Deployment 治理。本示例创立后果如下图所示：

第 2 步：配置 HPA

在 TKE 控制台为测试工作负载绑定一个 HPA 配置，对于如何绑定配置 HPA 请参阅 HPA 操作步骤，本示例配置当网络出带宽达到 0.15Mbps（150Kbps）时触发扩容的策略。

第 3 步：性能验证

在集群中启动一个长期 Pod 对配置的 HPA 性能进行测试（模仿客户端）：

kubectl run -it --image alpine hpa-test --restart=Never --rm /bin/sh

在长期 Pod 中运行上面命令短时间内模仿大量申请拜访 “hpa-test” 服务使进口流量带宽增大：

# hpa-test.default.svc.cluster.local 为服务在集群中的域名，当须要进行脚本时按 Ctrl+C 即可
while true; do wget -q -O - hpa-test.default.svc.cluster.local; done

在测试 Pod 中执行模仿申请命令后，通过观察下图中工作负载的 Pod 数量监控能够看到，在 16:21 分时工作负载扩容正本数量至 2 个，由此可推断出曾经触发了 HPA 的扩容事件。

再通过下图的工作负载的网络进口带宽监控能够看出在 16:21 右左时网络进口带宽增至大略 199 Kbps，曾经超过 HPA 设定的网络进口带宽目标值，进一步证实此时触发 HPA 扩缩容算法扩容了一个正本数来满足设定的目标值，故工作负载的正本数量变成了 2 个。

留神：HPA 扩缩容算法不只以公式计算维度去管制扩缩容逻辑，而会多维度去掂量是否须要扩容或缩容，详情能够参阅算法细节，所以在理论状况中可能和预期会稍有偏差。

接下来模仿缩容过程，在 16：24 左右手动进行执行模仿申请的命令，从下图监控看到此时网络进口带宽值降落到扩容前地位，依照 HPA 的逻辑，此时曾经满足工作负载缩容的条件。

但从下图工作负载的 Pod 数量监控能够看出，工作负载在 16:30 分时才触发了 HPA 的缩容，这是因为触发了 HPA 缩容有默认 5 分钟的容忍工夫的算法，以避免度量指标短时间稳定导致的频繁的扩缩容，详情请参阅冷却 / 提早反对。从下图能够看出工作负载正本数在进行命令 5 分钟后依照 HPA 扩缩容算法缩容到了最后设定的 1 个正本数。

当 TKE 产生 HPA 扩缩容事件时，会在对应的 HPA 实例的事件列表展现，如下图所示。须要留神的是事件告诉列表的工夫分为“首次呈现工夫”和“最初呈现工夫”，“首次呈现工夫”示意雷同事件第一次呈现的工夫，”最初呈现工夫”为雷同事件呈现的最新工夫，所以从下图事件列表“最初呈现工夫”字段能够看到本示例扩容事件工夫点是 16:21:03，缩容事件工夫是 16.29:42，工夫点与工作负载监控看到的工夫点相吻合。

此外，工作负载事件列表也会记录 HPA 产生时工作负载的增删正本数事件，从下图能够看出工作负载扩缩容工夫点与 HPA 事件列表的工夫点也是吻合的，减少正本数工夫点是 16:21:03，缩小正本数工夫点是 16: 29:42。

在本示例中次要演示了 TKE 的 HPA 性能，应用 TKE 自定义的网络进口带宽度量类型作为工作负载 HPA 的扩缩容度量指标，当工作负载理论度量值超过 HPA 配置的度量目标值时，HPA 依据扩容算法计算出适合的正本数实现程度扩容，保障工作负载的度量指标满足预期，保障工作负载衰弱稳固运行；当理论度量值远低于 HPA 配置的度量目标值时，HPA 会在容忍工夫后计算适合的正本数实现程度缩容，适当开释闲置资源，达到晋升资源利用率的目标，并且整个过程在 HPA 和工作负载事件列表都会有相应的事件记录，使整个工作负载程度扩缩容全程可追溯。