云平台中 HPA（horizontal pod autoscalers）水平自动伸缩

今天和大家分享云平台中的 HPA（horizontal pod autoscalers）水平自动伸缩。

虽然通常我们可以部署 Deployment 时设置 pod 的数量。但是这样设置不够灵活，在不同的运行环境，会导致资源的浪费，而随着吞吐量的上升，又需要不同的设置。

HPA 即通过检测 pod CPU 的负载，解决 deployment 里某 pod 负载太重，动态伸缩 pod 的数量来负载均衡。

HPA 可以检测 pod cpu 的使用情况，通知 deployment 增加或者减少所管理 pod 副本的数量。

1、假如已经部署好了一个工作负载，deployment/kms. 现在需要配置 HPA。设置 kms 的 pod 数量最小为 2，最大为 10 执行命令：kubectl autoscale deployment kms --min=2 --max=10

当我们手动强行设置 pod 数为 1 时，kms 的 pod 数量会马上删除一个，然后又重新创建一个新的 pod，始终维持到最小数量 2。

从步骤 1 来看，只是 为 POD 限定了一个可设置的范围，也没多神奇的地方。步骤 2 将进一步根据 POD 负载指标，来设置自动扩容策略。

假如 POD 的 CUP 利用率超过 80% 自动扩容，则这样设置 kms 的 HPA kubectl autoscale deployment kms --min=2 --max=10 --cpu-percent=80

这里设置了 cpu-percent=80，表示 pod 的 cpu 利用率超过了百分之 80 会自动扩容，最小规格 2 个 pod，每超过 80%，再自动扩容，直到 pod 最大数 10。

自动扩容，不是无限扩容，也会参考当前集群总体资源来设置一个合理的区间阈值。

HPA 虽然能通过各自策略，实现 POD 的配置自动伸缩，主要是仰仗 SVC 的强大的负载均衡。

k8s 中 svc 有三种类型，分别为 ClusterIP、NodePort、LoadBalancer；但是当 SVC 的类型是 ClusterIP 时，明显的 POD 端启动多个或者减少时，对服务的持续访问影响最小；而 Deployment 的部署方式，通常用在无状态部署，相当于访问每个 POD 提供的功能效果是一样的。即 Deployment 部署的应用，最适合 HPA 自动扩容的方式。

而当：SVC 是 NodePort 对集群节点端口有依赖；SVC 是 LoadBalancer 时对 IP 资源有要求；或者通过 SatefulSet (有状态) 方式部署的应用，每个 POD 都有编号，pod 的主机名会映射到 DNS，相当于每个 POD 的都是不一样的。则这些场景的云应用，采用 HPA 自动扩容的方式又不太适用。

今天的分享就到这了，主要是对 POD 的自动化扩容提供了一种方法 HPA，以及对它使用的场景进行了简单分析。就当前的部署来看，大部分都是 deployment 方式，还是能使用上的。

杭州溪塔科技有限公司 | （Rivtower Techonology Co.,Ltd.）是以开源为内核领先的区块链底层技术公司。公司自主研发设计了包括开源联盟链底层 CITA 、云原生区块链开发框架 CITA-Cloud、企业级区块链管理平台 RivSpace 、 数据要素确权流转平台 RivTrust 等区块链底层产品生态，并在金融，政务，能源，工业互联网领域广泛应用，是国家级新型数字基础设施星火•链网核心合作伙伴，在共识算法、智能合约、隐私保护等领域申请 200 余项发明专利。