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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 容器技术的发展让软件交付和运维变得更加标准化、轻量化、自动化。这使得动态调整负载的容量变成一件非常简单的事情,在kubernetes中,通常只需要调整对应的replicas数目即可完成。当负载的容量调整变得如何简单后,我们再回过头来看下应用的资源画像。

前言

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

image

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

目录
相关文章
|
23天前
|
弹性计算 人工智能 Serverless
阿里云ACK One:注册集群云上节点池(CPU/GPU)自动弹性伸缩,助力企业业务高效扩展
在当今数字化时代,企业业务的快速增长对IT基础设施提出了更高要求。然而,传统IDC数据中心却在业务存在扩容慢、缩容难等问题。为此,阿里云推出ACK One注册集群架构,通过云上节点池(CPU/GPU)自动弹性伸缩等特性,为企业带来全新突破。
|
1月前
|
存储 Kubernetes 持续交付
介绍一下Kubernetes的应用场景
【10月更文挑战第18天】介绍一下Kubernetes的应用场景。
137 3
|
3月前
|
存储 Kubernetes API
在K8S中,etcd 适应的场景?
在K8S中,etcd 适应的场景?
|
3月前
|
运维 Kubernetes 大数据
Kubernetes 的架构问题之在Serverless Container场景下尚不支持资源超售如何解决
Kubernetes 的架构问题之在Serverless Container场景下尚不支持资源超售如何解决
63 0
|
3月前
|
弹性计算 Kubernetes 算法
AHPA:Kubernetes弹性伸缩的预言家,揭秘未来资源使用的神秘面纱!
【8月更文挑战第8天】在云原生应用中,Kubernetes已成为部署标准。面对不断扩大的集群与应用规模,有效资源管理和弹性伸缩成为关键。AHPA(自适应历史感知预测算法)作为先进的预测技术,通过分析历史数据预测资源需求并自动调整Kubernetes资源分配。以一个在线零售平台为例,通过AHPA识别流量周期性变化,在节假日高峰期前自动增加Pod数量,保证服务稳定;而在平峰期减少Pod数量,节省资源。AHPA为Kubernetes提供了智能化的弹性伸缩方案,提高了应用稳定性和资源利用率。
76 7
|
3月前
|
存储 缓存 Kubernetes
在K8S中,有状态服务与无状态服务都是怎么使用pv和pvc?(可以通过应用场景说明一下)
在K8S中,有状态服务与无状态服务都是怎么使用pv和pvc?(可以通过应用场景说明一下)
|
3月前
|
存储 Kubernetes 监控
在K8S中,K8S本身优势、适应场景及其特点有什么?
在K8S中,K8S本身优势、适应场景及其特点有什么?
|
3月前
|
存储 Kubernetes 负载均衡
在K8S中,etcd适应的场景有哪些?
在K8S中,etcd适应的场景有哪些?
|
5月前
|
Kubernetes 网络协议 Cloud Native
Kubernetes网络问题排查分享两则(1)——calico特定场景下的网络性能问题
在对Kubernetes项目[kosmos](https://github.com/kosmos-io/kosmos)与Calico网络性能进行对比测试时,发现kosmos在跨集群容器网络的性能显著优于Calico的集群内网络(约6Gbit/s对比2.9Gbit/s)。物理机网络测试达到9.38Gbit/s,显示Calico有68%的性能损耗。问题定位到网卡的checksum/offload参数,尝试用`ethtool`调整后虽短暂提升,但随后恢复原状。转载自:https://mp.weixin.qq.com/s/XsQZCSqZAXJK46zqc7IpLw
|
5月前
|
Kubernetes 安全 测试技术
超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?
超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?

相关产品

  • 容器服务Kubernetes版
  • 下一篇
    无影云桌面