Kubernetes弹性弹性全场景解读(八) – 守时弹性组件支撑HPA兼容

前语

在之前的文章中,咱们介绍了kubernetes-cronhpa-controller是怎样经过设置守时的办法触发容器的水平副本弹性,可是在实践的场景下,尽管守时弹性关于负载有规矩的运用比较友爱,可是运用为了防止突发的流量冲击,仍是会装备HPA来做最终的保证的。那么CronHPA与HPA之间该怎样挑选呢?

守时弹性组件兼容HPA

在选择什么时分需求CronHPA,什么时分运用HPA的时分,咱们在考虑是否能够将CronHPA与HPA一同运用,假如一同运用会有什么需求处理的问题呢?首要咱们先看CronHPA的模板界说

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: CronHorizontalPodAutoscaler
metadata:
labels:
controller-tools.k8s.io: "1.0"
name: cronhpa-sample
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment-basic
jobs:
- name: "scale-down"
schedule: "30 */1 * * * *"
targetSize: 1
- name: "scale-up"
schedule: "0 */1 * * * *"
targetSize: 3

在CronHPA中是经过scaleTargetRef字段来获取弹性目标的,并经过jobs的crontab规矩守时弹性实例的副本。

那么咱们再来看下HPA的模板界说

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment-basic
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50

HPA也是经过scaleTargetRef来界说弹性的目标,并经过资源利用率来判别弹性的状况。假如一起设置CronHPA与HPA,那么就会呈现HPA与CronHPA一起操作一个scaleTargetRef的场景,而两者之间又彼此独立无法感知,这样就会呈现两个controller各自作业,后履行的会掩盖先履行的成果。

Kubernetes弹性弹性全场景解读(八) - 守时弹性组件支撑HPA兼容
这个问题的实质是两个controller无法彼此感知,然后造成了反常,当回过头来看这个问题的时分,其实咱们能够发现HPA前期也有相同的问题,开发者假如期望经过用两个监控目标一起作用到HPA的时分,假如设置两个HPA目标,会呈现相似的问题,在处理这个问题的时分,是经过在HPA目标中界说metrics字段,将多个metrics合并到一个HPA目标中来完成的,例如:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment-basic
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 50

当两个metrics触发弹性的个数不同的时分,会依据稳定性榜首的准则,优先弹出更多的副本或许在缩容时保存更多的副本。那么是否CronHPA和HPA也能够经过这个计划进行整合,答案是Yes and No。由于确实能够经过alibaba-cloud-metrics-adapter将守时的数据经过External Metrics的办法进行转化,然后经过HPA中运用External Metrics的办法进行整合和匹配。可是这样会带来的成果便是,咱们需求经过HPA的结构去表达CronHPA的规矩,然后再经过Metrics Adapter的模型去转化时刻信息与副本核算。从模型上来看,这个办法看似兼容了HPA,可是实践上对守时弹性的可读性、学习本钱、犯错确诊、审计与离线都带来了新的应战。

那么是否还有其他的办法能够完成CronHPA与HPA的兼容呢?咱们将视角放回scaleTargetRef,还记得HPA是怎样弹性Deployment的Pod吗,是HPA将Deployment装备在了scaleTargetRef的字段下,然后Deployment经过本身界说查找到了ReplicaSet,在经过ReplicaSet调整了实在的副本数目。
Kubernetes弹性弹性全场景解读(八) - 守时弹性组件支撑HPA兼容
那么从这个视点动身,咱们有了一个斗胆的主意,是否能够将scaleTargetRef设置为HPA目标,然后经过HPA目标来寻觅实在的scaleTargetRef
Kubernetes弹性弹性全场景解读(八) - 守时弹性组件支撑HPA兼容

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: CronHorizontalPodAutoscaler
metadata:
labels:
controller-tools.k8s.io: "1.0"
name: cronhpa-sample
spec:
scaleTargetRef:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
name:  nginx-deployment-basic-hpa
jobs:
- name: "scale-down"
schedule: "30 */1 * * * *"
targetSize: 1
runOnce: true
- name: "scale-up"
schedule: "0 */1 * * * *"
targetSize: 3
runOnce: true

这样规划的优点是,首要CronHPA能够感知HPA当时的状况,清晰的知晓HPA的min、max、desired的数值,一起也知道HPA scaleTargetRef所对应的当时replicas。那么本着稳定性准则,咱们要怎样控制HPA呢?

hpa(min/max) cronhpa deployment result 场景
1/10 5 5 hpa(1/10) deployment 5 守时和当时共同,无需改动
1/10 4 5 hpa(1/10) deployment 5 当时高于守时,保存当时副本
1/10 6 5 hpa(6/10) deployment 6 守时高于当时,保存守时副本
守时高于HPA下限,修正HPA下限
5/10 4 5 hpa(4/10) deployment 5 守时低于当时,保存当时副本
守时低于HPA下限,修正HPA下限
5/10 11 5 hpa(11/11) deployment 11 守时高于当时,保存守时副本
守时高于HPA上限,修正HPA上限

如上图所以,CronHPA会经过调整HPA的办法进行感知,CronHPA要到达的副本和当时副本取大值,来判别是否要扩容以及修正HPA的上限。CronHPA要到达的副本和HPA的装备取小值,判别是否要修正HPA的下限。简略而言,CronHPA不会直接调整Deployment的副本数目,而是经过HPA来操作Deployment,这样就能够防止HPA和CronHPA的抵触问题了。

最终

守时弹性CronHPA和HPA都是在线事务场景下非常重要的功用,不管运用何种的兼容与适配的办法,稳定性榜首的准则是不能改动的,开发者假如对CronHPA感兴趣,欢迎提交PR