前言

容器技术的发展让软件交付和运维变得更加标准化、轻量化、自动化。这使得动态调整负载的容量变成一件非常简单的事情。在kubernetes中,通常只需要修改对应的replicas数目即可完成。当负载的容量调整变得如此简单后,我们再回过头来看下应用的资源画像。对于大部分互联网的在线应用而言,负载的峰谷分布是存在一定规律的。例如下图是一个典型web应用的负载曲线。从每天早上8点开始,负载开始飙高,在中午12点到14点之间,负载会回落;14点到18点会迎来第二个高峰;在18点之后负载会逐渐回落到最低点。

资源的波峰和波谷之间相差3~4倍左右的容量,低负载的时间会维持8个小时左右。如果使用纯静态的容量规划方式进行应用管理与部署,我们可以计算得出资源浪费比为25% (计算方式:1 - (1x8+4x16)/4x24 = 0.25 )。而当波峰和波谷之间的差别到达10倍的时候,资源浪费比就会飙升至57%(计算方式:1 - (1x8+10x16)/10x24 = 0.57 )。

那么当我们面对这么多的资源浪费时,是否可以通过弹性的方式来解决呢?标准的HPA是基于指标阈值进行伸缩的,常见的指标主要是CPU、内存,当然也可以通过自定义指标例如QPS、连接数等进行伸缩。但是这里存在一个问题,因为基于资源的伸缩存在一定的时延,这个时延主要包含:采集时延(分钟级) + 判断时延(分钟级) + 伸缩时延(分钟级)。而对于上图中,我们可以发现负载的峰值毛刺还是非常尖锐的,这有可能会由于HPA分钟级别的伸缩时延造成负载数目无法及时变化,短时间内应用的整体负载飙高,响应时间变慢。特别是对于一些游戏业务而言,由于负载过高带来的业务抖动会造成玩家非常差的体验。

为了解决这个场景,阿里云容器服务提供了kube-cronhpa-controller,专门应对资源画像存在周期性的场景。开发者可以根据资源画像的周期性规律,定义time schedule,提前扩容好资源,而在波谷到来后定时回收资源。底层再结合cluster-autoscaler的节点伸缩能力,提供资源成本的节约。

使用方式

cronhpa是基于CRD的方式开发的controller,使用cronhpa的方式非常简单,整体的使用习惯也尽可能的和HPA保持一致。代码仓库地址

1. 安装CRD

kubectl apply -f config/crds/autoscaling_v1beta1_cronhorizontalpodautoscaler.yaml

2. 安装RBAC授权

# create ClusterRole
kubectl apply -f config/rbac/rbac_role.yaml # create ClusterRolebinding and ServiceAccount
kubectl apply -f config/rbac/rbac_role_binding.yaml

3. 部署kubernetes-cronhpa-controller

kubectl apply -f config/deploy/deploy.yaml

4. 验证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

运行一个cronhpa的demo

安装了kubernetes-cronhpa-controller后,我们可以通过一个简单的demo进行功能的验证。在部署前,我们先看下一个标准的cronhpa的定义。

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内看到负载数目的两次变化。

1. 部署demo应用与cronhpa的配置

kubectl apply -f examples/deployment_cronhpa.yaml

2. 检查demo应用副本数目

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

3. 查看cronhpa的状态 ,确认cronhpa的job已提交

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>

4. 等待一段时间,查看cronhpa的运行状态。

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中发现负载的定时伸缩已经生效。

最后

kubernetes-cronhpa-controller可以很好的解决拥有周期性资源画像的负载弹性,结合底层的cluster-autoscaler可以降低大量的资源成本。目前kubernetes-cronhpa-controller已经正式开源,更详细的用法与文档请查阅代码仓库的文档,欢迎开发者提交issue与pr。


本文作者:莫源

原文链接

本文为云栖社区原创内容,未经允许不得转载。

Kubernetes弹性伸缩全场景解读(五) - 定时伸缩组件发布与开源的更多相关文章

  1. Kubernetes 弹性伸缩全场景解读(五) - 定时伸缩组件发布与开源

    作者| 阿里云容器技术专家刘中巍(莫源) 导读:Kubernetes弹性伸缩系列文章为读者一一解析了各个弹性伸缩组件的相关原理和用法.本篇文章中,阿里云容器技术专家莫源将为你带来定时伸缩组件  kub ...

  2. Kubernetes 弹性伸缩全场景解读(二)- HPA 的原理与演进

    前言 在上一篇文章 Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家 ...

  3. Kubernetes 弹性伸缩全场景解析 (四)- 让核心组件充满弹性

    前言 在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析.在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践.今天我们要讲解的是 ...

  4. Kubernetes 弹性伸缩全场景解析 (一)- 概念延伸与组件布局

    传统弹性伸缩的困境 弹性伸缩是Kubernetes中被大家关注的一大亮点,在讨论相关的组件和实现方案之前.首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实 ...

  5. Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局

    传统弹性伸缩的困境 弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前.首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划 ...

  6. Kubernetes 弹性伸缩全场景解析(三) - HPA 实践手册

    在上一篇文章中,给大家介绍和剖析了 HPA 的实现原理以及演进的思路与历程.本文我们将会为大家讲解如何使用 HPA 以及一些需要注意的细节. autoscaling/v1 实践 v1 的模板可能是大家 ...

  7. Mybatis系列全解(五):全网最全!详解Mybatis的Mapper映射文件

    封面:洛小汐 作者:潘潘 若不是生活所迫,谁愿意背负一身才华. 前言 上节我们介绍了 < Mybatis系列全解(四):全网最全!Mybatis配置文件 XML 全貌详解 >,内容很详细( ...

  8. 终于开始了,微软的野心将通过全场景开发平台dotnet 5体现得淋漓尽致!

      本文已经同步到微信公众号「极客起源」 . 现在都在谈论全场景开发,也就是用一套开发工具,可以开发包括但不限于桌面.移动.IOT.游戏.Web等平台的应用.这样对于开发人员是非常爽的.本文将介绍微软 ...

  9. 乘风破浪,遇见华为鸿蒙智能终端系统(HarmonyOS 2),打造面向全场景的分布式操作系统

    什么是鸿蒙智能终端系统(HarmonyOS 2) HarmonyOS 是新一代的智能终端操作系统,为不同设备的智能化.互联与协同提供了统一的语言.带来简洁,流畅,连续,安全可靠的全场景交互体验. ht ...

随机推荐

  1. java httpclient中文乱码解决方案,看注释

    @RequestMapping("getpage") public ModelAndView admin_checkurl(HttpServletRequest request) ...

  2. springmvc配置不拦截静态资源

    <mvc:resources mapping="/js/**" location="/js/"/>

  3. MySQL数据库的全局锁和表锁

    1.概念 数据库锁设计的初衷是处理并发问题.作为多用户共享的资源,当出现并发访问的时候,数据库需要合理地控制资源的访问规则.而锁就是用来实现这些访问规则的重要数据结构. 2.锁的分类 根据加锁的范围, ...

  4. Breakpoint 断点只生效一次

  5. cf round480D Perfect Groups

    题意:给一个序列,对于每一个连续的区间,区间内的数至少分成几个组,使得每个组内的数任意2个相乘是一个完全平方数(包括0). 输出每个组数的个数. $n \leq 5000 , |a_i| \leq 1 ...

  6. LintCode_469 等价二叉树

    题目 检查两棵二叉树是否等价.等价的意思是说,首先两棵二叉树必须拥有相同的结构,并且每个对应位置上的节点上的数都相等. 样例 1 1 / \ / \ 2 2 and 2 2 / / 4 4 就是两棵等 ...

  7. 2017年Android SDK下载安装及配置教程(附带原文地址)

    首先声明: Unity版本5.6.3f1 最近试着在Unity中利用高通做AR开发时,发布项目文件需要发布到Android平台,遇到一些问题,看了网上的一些资料,踩了一些坑,现在总结出来,希望有相同的 ...

  8. 关于chrome浏览器的帐号密码自动填充以及出现的黄色背景色填充问题

    不知道大家平时做项目的时候有木有关注这个问题,其实之前做项目遇到过类似的问题,但是因为是单独的chrome浏览器的填充,而且是样式问题稍微严重点,也就没在意.然而在近期的项目中有遇到了这个问题,最为一 ...

  9. 备考2019年6月份PMP考试-分享一些考试笔记(二)

    最新比较经典的100道试题,有备考的小伙伴可以练练手,文章末尾附答案. 1     一个项目经理在运作一个数据中心安装项目.他发现相关方很恼火,因为他超出了预算,原因是人员费用要高于原先的计划.另外项 ...

  10. 计算机组成原理作业一 熟悉MIPS指令

    第一题 .data outputd: .asciiz "Alpha","November","First","alpha" ...