基于Kubernetes的hpa实现pod实例数量的自动伸缩
Pod 是在 体系中，承载用户业务负载的一种资源。Pod 们运行的好坏，是用户们最为关心的事情。在业务流量高峰时，手动快速扩展 Pod 的实例数量，算是玩转 的基本操作。实际上这个操作还可以更加自动化，运维人员可以事先设置好规则，让 Pod 实例的数量，在指定情况下自动的调整实例的数量，这一操作依靠 Pod 来实现。
场景描述
如果企业应用的最终用户是人，那么它的访问压力情况，都会有潮汐特征。好比一款供企业内部人员使用的OA系统，工作日的流量远比休息日高，工作时间的流量远比下班时间高。那么可否让这款 OA 系统根据流量的大小，自动调整实例的数量。令其忙时启动足够数量的实例抵御访问压力，闲时自动降低实例数量，将资源留给其他企业应用。
下图是某个业务系统，在 24 小时内的性能监控曲线。其吞吐率和在线人数曲线都可以反映出一定的潮汐特性：
关于 hpa
在 1.2 版本开始支持了 Pod （hpa） ，来应对 Pod 实例的自动伸缩场景。它可以基于实例的 CPU 使用率来决定是否为 Pod 进行实例数量的扩容。我们知道 Pod 的副本数量是被其控制器的配置所决定的，比如 、、 。所以，hpa 是在获取了 Pod 实际 CPU 使用率这一指标，和扩展实例的目标指标对比后，操作了其控制器来实现副本数量的扩缩的。
了解了以上内容后，我们起码可以知道，在使用 hpa 进行自动伸缩的设置之前， 集群和 Pod 的控制器都应该符合一定的先决条件。
创建 hpa
创建 hpa 之前， 我们需要确保 Pod 控制器中规定了CPU资源限额。我当前使用的案例，使用了 控制器。其 Pod 的 CPU 资源限额给到 500m。
体系中，CPU 是一种可以再分的资源，1000m = 1 Core
kubectl get deployment demo-java -n my-namespace -o yaml
返回的结果中，包含了事先设置的资源限额信息：
spec:resources:limits:cpu: 200mmemory: 1Girequests:cpu: 200m
最简单的创建 hpa 的方式，是使用 命令进行操作。下面的示例，意味着在 Pod 的 CPU 使用率超过 50% 之后，将会触发自动伸缩，最多伸缩到 3 个实例。
kubectl autoscale deployment demo-java -n my-namespace --cpu-percent=50 --min=1 --max=3
返回结果：
horizontalpodautoscaler.autoscaling/demo-java autoscaled
创建完成后，我们可以查看 hpa 资源的状态：
kubectl get hpa -n my-namespace
返回结果中，自动伸缩已经被触发，所有实例的综合 CPU 使用率，已经低于设定的值：
hpa 资源只需要被设定一次，就会始终监控 Pod 指标，并根据设定进行自动伸缩
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
demo-java Deployment/demo-java 49%/50% 1 3 2 3m34s
查看 Pod 实际 CPU 使用量，可以得出相应的使用率计算值，和 hpa 中的显示是相符的。
kubectl top pod -n my-namespace
NAME CPU(cores) MEMORY(bytes)
demo-java-7d6d7d4c9c-lz8sw 197m 87Mi
demo-java-7d6d7d4c9c-52sdl 1m 90Mi
另一种创建 hpa 的方式，是通过 yaml 文件进行定义。我们可以将已存在的 hpa 资源导出，便可以了解这一资源的定义方式。
kubectl get hpa demo-java -n my-namespace -o yaml > hpa.yaml
其定义方式可以归结如下：
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:name: demo-javanamespace: my-namespace
spec:maxReplicas: 3minReplicas: 1scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: demo-javatargetCPUUtilizationPercentage: 50
通过命令，可以将这一yaml文件加载进 集群：
kubectl apply -f hpa.yaml
