容器技术的发展让软件交付和运维变得更加标准化、轻量化、自动化。这使得动态调整负载的容量变成一件很是简单的事情。在kubernetes中,一般只须要修改对应的replicas数目便可完成。当负载的容量调整变得如此简单后,咱们再回过头来看下应用的资源画像。对于大部分互联网的在线应用而言,负载的峰谷分布是存在必定规律的。例以下图是一个典型web应用的负载曲线。从天天早上8点开始,负载开始飙高,在中午12点到14点之间,负载会回落;14点到18点会迎来第二个高峰;在18点以后负载会逐渐回落到最低点。nginx
资源的波峰和波谷之间相差3~4倍左右的容量,低负载的时间会维持8个小时左右。若是使用纯静态的容量规划方式进行应用管理与部署,咱们能够计算得出资源浪费比为25% (计算方式:1 - (1*8+4*16)/4*24 = 0.25 )。而当波峰和波谷之间的差异到达10倍的时候,资源浪费比就会飙升至57%(计算方式:1 - (1*8+10*16)/10*24 = 0.57 )。git
那么当咱们面对这么多的资源浪费时,是否能够经过弹性的方式来解决呢?标准的HPA是基于指标阈值进行伸缩的,常见的指标主要是CPU、内存,固然也能够经过自定义指标例如QPS、链接数等进行伸缩。可是这里存在一个问题,由于基于资源的伸缩存在必定的时延,这个时延主要包含:采集时延(分钟级) + 判断时延(分钟级) + 伸缩时延(分钟级)。而对于上图中,咱们能够发现负载的峰值毛刺仍是很是尖锐的,这有可能会因为HPA分钟级别的伸缩时延形成负载数目没法及时变化,短期内应用的总体负载飙高,响应时间变慢。特别是对于一些游戏业务而言,因为负载太高带来的业务抖动会形成玩家很是差的体验。github
为了解决这个场景,阿里云容器服务提供了kube-cronhpa-controller
,专门应对资源画像存在周期性的场景。开发者能够根据资源画像的周期性规律,定义time schedule,提早扩容好资源,而在波谷到来后定时回收资源。底层再结合cluster-autoscaler
的节点伸缩能力,提供资源成本的节约。web
cronhpa
是基于CRD的方式开发的controller,使用cronhpa
的方式很是简单,总体的使用习惯也尽量的和HPA保持一致。代码仓库地址api
kubectl apply -f config/crds/autoscaling_v1beta1_cronhorizontalpodautoscaler.yaml
# create ClusterRole kubectl apply -f config/rbac/rbac_role.yaml # create ClusterRolebinding and ServiceAccount kubectl apply -f config/rbac/rbac_role_binding.yaml
kubernetes-cronhpa-controller
kubectl apply -f config/deploy/deploy.yaml
kubernetes-cronhpa-controller
安装状态kubectl get deploy kubernetes-cronhpa-controller -n kube-system -o wide kubernetes-cronhpa-controller git:(master) kubectl get deploy kubernetes-cronhpa-controller -n kube-system NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE kubernetes-cronhpa-controller 1 1 1 1 49s
安装了kubernetes-cronhpa-controller
后,咱们能够经过一个简单的demo进行功能的验证。在部署前,咱们先看下一个标准的cronhpa的定义。app
apiVersion: autoscaling.alibabacloud.com/v1beta1 kind: CronHorizontalPodAutoscaler metadata: labels: controller-tools.k8s.io: "1.0" name: cronhpa-sample namespace: default spec: scaleTargetRef: apiVersion: apps/v1beta2 kind: Deployment name: nginx-deployment-basic jobs: - name: "scale-down" schedule: "30 */1 * * * *" targetSize: 1 - name: "scale-up" schedule: "0 */1 * * * *" targetSize: 3
其中scaleTargetRef
字段负责描述伸缩的对象,jobs
中定义了扩展的crontab
定时任务。在这个例子中,设定的是每分钟的第0秒扩容到3个Pod,每分钟的第30s缩容到1个Pod。若是执行正常,咱们能够在30s内看到负载数目的两次变化。运维
kubectl apply -f examples/deployment_cronhpa.yaml
kubectl get deploy nginx-deployment-basic kubernetes-cronhpa-controller git:(master) kubectl get deploy nginx-deployment-basic NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment-basic 2 2 2 2 9s
kubectl describe cronhpa cronhpa-sample Name: cronhpa-sample Namespace: default Labels: controller-tools.k8s.io=1.0 Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling.alibabacloud.com/v1beta1","kind":"CronHorizontalPodAutoscaler","metadata":{"annotations":{},"labels":{"controll... API Version: autoscaling.alibabacloud.com/v1beta1 Kind: CronHorizontalPodAutoscaler Metadata: Creation Timestamp: 2019-04-14T10:42:38Z Generation: 1 Resource Version: 4017247 Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sample UID: 05e41c95-5ea2-11e9-8ce6-00163e12e274 Spec: Jobs: Name: scale-down Schedule: 30 */1 * * * * Target Size: 1 Name: scale-up Schedule: 0 */1 * * * * Target Size: 3 Scale Target Ref: API Version: apps/v1beta2 Kind: Deployment Name: nginx-deployment-basic Status: Conditions: Job Id: 38e79271-9a42-4131-9acd-1f5bfab38802 Last Probe Time: 2019-04-14T10:43:02Z Message: Name: scale-down Schedule: 30 */1 * * * * State: Submitted Job Id: a7db95b6-396a-4753-91d5-23c2e73819ac Last Probe Time: 2019-04-14T10:43:02Z Message: Name: scale-up Schedule: 0 */1 * * * * State: Submitted Events: <none>
kubernetes-cronhpa-controller git:(master) kubectl describe cronhpa cronhpa-sample Name: cronhpa-sample Namespace: default Labels: controller-tools.k8s.io=1.0 Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling.alibabacloud.com/v1beta1","kind":"CronHorizontalPodAutoscaler","metadata":{"annotations":{},"labels":{"controll... API Version: autoscaling.alibabacloud.com/v1beta1 Kind: CronHorizontalPodAutoscaler Metadata: Creation Timestamp: 2019-04-15T06:41:44Z Generation: 1 Resource Version: 15673230 Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sample UID: 88ea51e0-5f49-11e9-bd0b-00163e30eb10 Spec: Jobs: Name: scale-down Schedule: 30 */1 * * * * Target Size: 1 Name: scale-up Schedule: 0 */1 * * * * Target Size: 3 Scale Target Ref: API Version: apps/v1beta2 Kind: Deployment Name: nginx-deployment-basic Status: Conditions: Job Id: 84818af0-3293-43e8-8ba6-6fd3ad2c35a4 Last Probe Time: 2019-04-15T06:42:30Z Message: cron hpa job scale-down executed successfully Name: scale-down Schedule: 30 */1 * * * * State: Succeed Job Id: f8579f11-b129-4e72-b35f-c0bdd32583b3 Last Probe Time: 2019-04-15T06:42:20Z Message: Name: scale-up Schedule: 0 */1 * * * * State: Submitted Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Succeed 5s cron-horizontal-pod-autoscaler cron hpa job scale-down executed successfully
此时能够在event中发现负载的定时伸缩已经生效。ide
kubernetes-cronhpa-controller
能够很好的解决拥有周期性资源画像的负载弹性,结合底层的cluster-autoscaler
能够下降大量的资源成本。目前kubernetes-cronhpa-controller
已经正式开源,更详细的用法与文档请查阅代码仓库的文档,欢迎开发者提交issue与pr。阿里云
原文连接
本文为云栖社区原创内容,未经容许不得转载。spa