作者|?阿里云容器技術專家劉中巍（莫源）

導讀：Kubernetes彈性伸縮系列文章為讀者一一解析了各個彈性伸縮組件的相關原理和用法。本篇文章中，阿里云容器技術專家莫源將為你帶來定時伸縮組件??kubernetes-cronhpa-controller??的相關介紹與具體操作，目前該組件已經正式開源，歡迎大家一起交流探討。

前言

容器技術的發展讓軟件交付和運維變得更加標準化、輕量化、自動化。這使得動態調整負載的容量變成一件非常簡單的事情。在 Kubernetes 中，通常只需要修改對應的 replicas 數目即可完成。當負載的容量調整變得如此簡單后，我們再回過頭來看下應用的資源畫像。

對于大部分互聯網的在線應用而言，負載的峰谷分布是存在一定規律的。例如下圖是一個典型 web 應用的負載曲線。從每天早上 8 點開始，負載開始飆高，在中午 12 點到 14 點之間，負載會回落；14 點到 18 點會迎來第二個高峰；在 18 點之后負載會逐漸回落到最低點。



資源的波峰和波谷之間相差 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

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-samplenamespace: default spec:scaleTargetRef:apiVersion: apps/v1beta2kind: Deploymentname: nginx-deployment-basicjobs:- 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:38ZGeneration: 1Resource Version: 4017247Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sampleUID: 05e41c95-5ea2-11e9-8ce6-00163e12e274 Spec:Jobs:Name: scale-downSchedule: 30 */1 * * * *Target Size: 1Name: scale-upSchedule: 0 */1 * * * *Target Size: 3Scale Target Ref:API Version: apps/v1beta2Kind: DeploymentName: nginx-deployment-basic Status:Conditions:Job Id: 38e79271-9a42-4131-9acd-1f5bfab38802Last Probe Time: 2019-04-14T10:43:02ZMessage:Name: scale-downSchedule: 30 */1 * * * *State: SubmittedJob Id: a7db95b6-396a-4753-91d5-23c2e73819acLast Probe Time: 2019-04-14T10:43:02ZMessage:Name: scale-upSchedule: 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:44ZGeneration: 1Resource Version: 15673230Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/cronhorizontalpodautoscalers/cronhpa-sampleUID: 88ea51e0-5f49-11e9-bd0b-00163e30eb10 Spec:Jobs:Name: scale-downSchedule: 30 */1 * * * *Target Size: 1Name: scale-upSchedule: 0 */1 * * * *Target Size: 3Scale Target Ref:API Version: apps/v1beta2Kind: DeploymentName: nginx-deployment-basic Status:Conditions:Job Id: 84818af0-3293-43e8-8ba6-6fd3ad2c35a4Last Probe Time: 2019-04-15T06:42:30ZMessage: cron hpa job scale-down executed successfullyName: scale-downSchedule: 30 */1 * * * *State: SucceedJob Id: f8579f11-b129-4e72-b35f-c0bdd32583b3Last Probe Time: 2019-04-15T06:42:20ZMessage:Name: scale-upSchedule: 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?彈性伸縮系列文章目錄

• Kubernetes?彈性伸縮全場景解讀（一）- 概念延伸與組件布局
  
• Kubernetes?彈性伸縮全場景解讀（二）-?HPA?的原理與演進
  
• Kubernetes?彈性伸縮全場景解讀（三）-?HPA?實踐手冊
  
• Kubernetes?彈性伸縮全場景解讀（四）-?讓核心組件充滿彈性

---

掃描下方二維碼添加小助手，與 8000 位云原生愛好者討論技術趨勢，實戰進階！進群暗號：公司-崗位-城市**

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Kubernetes 弹性伸缩全场景解读（五） - 定时伸缩组件发布与开源的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。