经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 数据库/运维 » Kubernetes » 查看文章
Kubernetes 弹性伸缩全场景解读（五） - 定时伸缩组件发布与开源
来源：cnblogs　　作者：阿里巴巴云原生　　时间：2019/9/2 9:14:40　　对本文有异议


file
作者|?阿里云容器技术专家刘中巍（莫源）

导读：Kubernetes弹性伸缩系列文章为读者一一解析了各个弹性伸缩组件的相关原理和用法。本篇文章中，阿里云容器技术专家莫源将为你带来定时伸缩组件??kubernetes-cronhpa-controller??的相关介绍与具体操作，目前该组件已经正式开源，欢迎大家一起交流探讨。

前言


容器技术的发展让软件交付和运维变得更加标准化、轻量化、自动化。这使得动态调整负载的容量变成一件非常简单的事情。在 Kubernetes 中，通常只需要修改对应的 replicas 数目即可完成。当负载的容量调整变得如此简单后，我们再回过头来看下应用的资源画像。


对于大部分互联网的在线应用而言，负载的峰谷分布是存在一定规律的。例如下图是一个典型 web 应用的负载曲线。从每天早上 8 点开始，负载开始飙高，在中午 12 点到 14 点之间，负载会回落；14 点到 18 点会迎来第二个高峰；在 18 点之后负载会逐渐回落到最低点。



file



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


那么当我们面对这么多的资源浪费时，是否可以通过弹性的方式来解决呢？


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


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

使用方式


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

1. 安装 CRD

  1. kubectl apply -f config/crds/autoscaling_v1beta1_cronhorizontalpodautoscaler.yaml

2. 安装 RBAC 授权

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

3. 部署?kubernetes-cronhpa-controller

  1. kubectl apply -f config/deploy/deploy.yaml

4. 验证?kubernetes-cronhpa-controller?安装状态

  1. kubectl get deploy kubernetes-cronhpa-controller -n kube-system -o wide 
  2. kubernetes-cronhpa-controller git:(master)  kubectl get deploy kubernetes-cronhpa-controller -n kube-system
  3. NAME                            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  4. kubernetes-cronhpa-controller   1         1         1            1           49s

运行一个 cronhpa 的 demo


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

  1. apiVersion: autoscaling.alibabacloud.com/v1beta1
  2. kind: CronHorizontalPodAutoscaler
  3. metadata:
  4.   labels:
  5.     controller-tools.k8s.io: "1.0"
  6.   name: cronhpa-sample
  7.   namespace: default 
  8. spec:
  9.    scaleTargetRef:
  10.       apiVersion: apps/v1beta2
  11.       kind: Deployment
  12.       name: nginx-deployment-basic
  13.    jobs:
  14.    - name: "scale-down"
  15.      schedule: "30 */1 * * * *"
  16.      targetSize: 1
  17.    - name: "scale-up"
  18.      schedule: "0 */1 * * * *"
  19.      targetSize: 3


其中?scaleTargetRef?字段负责描述伸缩的对象，jobs?中定义了扩展的?crontab?定时任务。在这个例子中，设定的是每分钟的第 0 秒扩容到 3 个 Pod，每分钟的第 30s 缩容到 1 个 Pod。如果执行正常，我们可以在 30s 内看到负载数目的两次变化。

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

  1. kubectl apply -f examples/deployment_cronhpa.yaml

2. 检查 demo 应用副本数目

  1. kubectl get deploy nginx-deployment-basic 
  2. kubernetes-cronhpa-controller git:(master)  kubectl get deploy nginx-deployment-basic
  3. NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  4. nginx-deployment-basic   2         2         2            2           9s

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

  1. kubectl describe cronhpa cronhpa-sample 
  2. Name:         cronhpa-sample
  3. Namespace:    default
  4. Labels:       controller-tools.k8s.io=1.0
  5. Annotations:  kubectl.kubernetes.io/last-applied-configuration:
  6.                 {"apiVersion":"autoscaling.alibabacloud.com/v1beta1","kind":"CronHorizontalPodAutoscaler","metadata":{"annotations":{},"labels":{"controll...
  7. API Version:  autoscaling.alibabacloud.com/v1beta1
  8. Kind:         CronHorizontalPodAutoscaler
  9. Metadata:
  10.   Creation Timestamp:  2019-04-14T10:42:38Z
  11.   Generation:          1
  12.   Resource Version:    4017247
  13.   Self Link:           /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sample
  14.   UID:                 05e41c95-5ea2-11e9-8ce6-00163e12e274
  15. Spec:
  16.   Jobs:
  17.     Name:         scale-down
  18.     Schedule:     30 */1 * * * *
  19.     Target Size:  1
  20.     Name:         scale-up
  21.     Schedule:     0 */1 * * * *
  22.     Target Size:  3
  23.   Scale Target Ref:
  24.     API Version:  apps/v1beta2
  25.     Kind:         Deployment
  26.     Name:         nginx-deployment-basic
  27. Status:
  28.   Conditions:
  29.     Job Id:           38e79271-9a42-4131-9acd-1f5bfab38802
  30.     Last Probe Time:  2019-04-14T10:43:02Z
  31.     Message:
  32.     Name:             scale-down
  33.     Schedule:         30 */1 * * * *
  34.     State:            Submitted
  35.     Job Id:           a7db95b6-396a-4753-91d5-23c2e73819ac
  36.     Last Probe Time:  2019-04-14T10:43:02Z
  37.     Message:
  38.     Name:             scale-up
  39.     Schedule:         0 */1 * * * *
  40.     State:            Submitted
  41. Events:               <none>

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

  1. kubernetes-cronhpa-controller git:(master) kubectl describe cronhpa cronhpa-sample
  2. Name:         cronhpa-sample
  3. Namespace:    default
  4. Labels:       controller-tools.k8s.io=1.0
  5. Annotations:  kubectl.kubernetes.io/last-applied-configuration:
  6.                 {"apiVersion":"autoscaling.alibabacloud.com/v1beta1","kind":"CronHorizontalPodAutoscaler","metadata":{"annotations":{},"labels":{"controll...
  7. API Version:  autoscaling.alibabacloud.com/v1beta1
  8. Kind:         CronHorizontalPodAutoscaler
  9. Metadata:
  10.   Creation Timestamp:  2019-04-15T06:41:44Z
  11.   Generation:          1
  12.   Resource Version:    15673230
  13.   Self Link:           /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sample
  14.   UID:                 88ea51e0-5f49-11e9-bd0b-00163e30eb10
  15. Spec:
  16.   Jobs:
  17.     Name:         scale-down
  18.     Schedule:     30 */1 * * * *
  19.     Target Size:  1
  20.     Name:         scale-up
  21.     Schedule:     0 */1 * * * *
  22.     Target Size:  3
  23.   Scale Target Ref:
  24.     API Version:  apps/v1beta2
  25.     Kind:         Deployment
  26.     Name:         nginx-deployment-basic
  27. Status:
  28.   Conditions:
  29.     Job Id:           84818af0-3293-43e8-8ba6-6fd3ad2c35a4
  30.     Last Probe Time:  2019-04-15T06:42:30Z
  31.     Message:          cron hpa job scale-down executed successfully
  32.     Name:             scale-down
  33.     Schedule:         30 */1 * * * *
  34.     State:            Succeed
  35.     Job Id:           f8579f11-b129-4e72-b35f-c0bdd32583b3
  36.     Last Probe Time:  2019-04-15T06:42:20Z
  37.     Message:
  38.     Name:             scale-up
  39.     Schedule:         0 */1 * * * *
  40.     State:            Submitted
  41. Events:
  42.   Type    Reason   Age   From                            Message
  43.   ----    ------   ----  ----                            -------
  44.   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?弹性伸缩系列文章目录


扫描下方二维码添加小助手，与 8000 位云原生爱好者讨论技术趋势，实战进阶！进群暗号：公司-岗位-城市**
file

原文链接：http://www.cnblogs.com/alisystemsoftware/p/11436077.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Kubernetes热门文章

  • 【Azure K8S | AKS】在AKS集群中创建 PVC(PersistentVolumeClaim)和 PV(PersistentVolume) 示例
  • 无法访问k8s.gcr.io下载镜像问题解决办法
  • Kubernetes(k8s)访问控制：身份认证
  • Prometheus服务发现之kubernetes_sd_config
  • Arthas排查Kubernetes中应用频繁挂掉重启异常
  • Kubernetes客户端认证——基于CA证书的双向认证方式
  • k8s中kubeconfig的配置以及使用详解
  • Centos7 安装部署 Kubernetes(k8s) 高可用集群
  • Kubernetes 证书详解
  • 案例分享-full gc导致k8s pod重启

    • Kubernetes推荐文章

  • 修改kubeadm证书过期时间及更新k8s集群证书
  • 探究kubernetes 探针参数periodSeconds和timeoutSeconds
  • 从 Helm 到 Operator：Kubernetes应用管理的进化
  • 深入理解Prometheus: Kubernetes环境中的监控实践
  • k8s集群搭建及对一些组件的简单理解（二）
  • K8s高可用集群二进制部署-V1.20
  • Kubernetes容器生命周期 —— 钩子函数详解（postStart、preStop）
  • Kubernetes 审计（Auditing）
  • Thanos解码：打造企业级云原生监控解决方案
  • k8s使用rbd作为存储

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号