由于CronHPA和HPA两者无法相互感知,如果您的应用使用YAML同时配置了CronHPA和HPA,可能会出现两种配置独立工作,后执行操作覆盖了先执行操作的现象。为了解决这个问题,ACK提供了CronHPA兼容HPA的方案——当检测到两者同时存在时,将HPA作为CronHPA的扩缩容对象,从而实现对该HPA定义对象(例如Deployment)的定时扩缩容。
如果您的HPA和CronHPA均通过容器服务管理控制台创建,可忽略本操作。ACK会自动为您实现兼容。
从CronHPA和HPA的定义模板了解为什么会产生冲突
CronHPA定义模板 | HPA定义模板 |
|
|
对比CronHPA和HPA的定义模板,可以发现:
CronHPA和HPA都是通过
scaleTargetRef
字段来获取伸缩对象。CronHPA通过
jobs
的crontab
规则定时伸缩副本数。HPA通过资源(Resource)利用率判断伸缩的情况。
因此,如果应用同时配置了CronHPA和HPA,CronHPA和HPA可能会同时操作一个scaleTargetRef
。为了解决这个问题,需要使CronHPA能够感知HPA的当前状态。
解决方案
为了解决CronHPA和HPA无法相互感知的问题,ACK支持将HPA作为CronHPA的扩缩容对象。在HPA的定义模板中,HPA将Deployment配置在scaleTargetRef
字段下,Deployment再通过自身的定义查找ReplicaSet,ReplicaSet再调整真实的副本数量。
通过将HPA作为CronHPA的scaleTargetRef
,CronHPA可以明确知晓并综合考虑CronHPA任务当前的目标副本数,HPA中的minReplicas
、maxReplicas
和desiredReplicas
数值,以及HPA中scaleTargetRef
对象的当前副本数。
但CronHPA不会直接调整Deployment的副本数目,而是通过HPA来修改Deployment配置,避免HPA和CronHPA发生冲突。
CronHPA兼容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: false
- name: "scale-up"
schedule: "0 */1 * * * *"
targetSize: 3
runOnce: false
兼容示例与规则说明
以下根据不同的场景,说明CronHPA兼容HPA的规则。
表格涉及字段说明如下:
HPA(min/max):HPA定义的最小和最大的副本数(minReplicas、maxReplicas)。
CronHPA目标副本数:CronHPA任务的目标副本数。
当前副本数:应用扩缩前的副本数。
副本数:应用执行扩缩容后的副本数。
扩缩容条件 | 扩缩容结果 | 兼容规则说明 | ||
HPA(min/max) | CronHPA目标副本数 | 当前副本数 | ||
1/10 | 5 | 5 |
| 当CronHPA中的目标副本数和当前副本数一致时,HPA中的minReplicas和maxReplicas以及当前的副本数无需变更。 |
1/10 | 4 | 5 |
| 当CronHPA中的目标副本数低于当前副本数时,保留当前副本数。 |
1/10 | 6 | 5 |
|
|
5/10 | 4 | 5 |
|
|
5/10 | 11 | 5 |
|
|
相关文档
关于HPA和CronHPA的详细信息,请参见使用容器水平伸缩(HPA)、使用容器定时水平伸缩(CronHPA)。