1. 程式人生 > >Kubernetes 彈性伸縮全場景解讀(五) - 定時伸縮元件釋出與開源

Kubernetes 彈性伸縮全場景解讀(五) - 定時伸縮元件釋出與開源



作者| 阿里雲容器技術專家劉中巍(莫源)

導讀: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-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 彈性伸縮系列文章目錄

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


掃描下方二維碼新增小助手,與 8000 位雲原生愛好者討論技術趨勢,實戰進階!進群暗號:公司-崗位-城市**

相關推薦

Kubernetes 彈性伸縮場景解讀 - 定時伸縮元件釋出開源

作者| 阿里雲容器技術專家劉中巍(莫源) 導讀:Kubernetes彈性伸縮系列文章為讀者一一解析了各個彈性伸縮元件的相關原理和用法。本篇文章中,阿里雲容器技術專家莫源將為你帶來定時伸縮元件  kubernetes-cronhpa-controller &nbs

Kubernetes彈性伸縮場景解讀

前言 容器技術的發展讓軟體交付和運維變得更加標準化、輕量化、自動化。這使得動態調整負載的容量變成一件非常簡單的事情。在kube

Kubernetes 彈性伸縮場景解讀

導讀:Kubernetes彈性伸縮系列文章為讀者一一解析了各個彈性伸縮元件的相關原理和用法。本篇文章中,阿里雲容器技術專

Kubernetes彈性伸縮場景解讀 - HPA的原理演進

前言 在上一篇文章中,我們介紹了在Kubernetes在處理彈性伸縮時的設計理念以及相關元件的佈局,在今天這篇文章中,會為大家介紹在Kubernetes中彈性伸縮最常用的元件HPA(Horizontal Pod Autoscaler)。HPA是通過計算Pod的實際工作負載進行重新容量規劃的元件,在資源池符合

Kubernetes 彈性伸縮場景解讀- HPA 的原理演進

前言 在上一篇文章 Kubernetes 彈性伸縮全場景解析 (一):概念延伸與元件佈局中,我們介紹了在 Kubernetes 在

Kubernetes 彈性伸縮場景解析 - 概念延伸元件佈局

傳統彈性伸縮的困境 彈性伸縮是Kubernetes中被大家關注的一大亮點,在討論相關的元件和實現方案之前。首先想先給大家擴充下彈性伸縮的邊界與定義,傳統意義上來講,彈性伸縮主要解決的問題是容量規劃與實際負載的矛盾。 如上圖所示,藍色的水位線表示叢集的容量隨著負載的提高不斷的增長,紅色的曲線表示叢集的

Kubernetes彈性伸縮場景解析 - HPA實踐手冊

前言 在上一篇文章中,給大家介紹和剖析了HPA的實現原理以及演進的思路與歷程。在本文中,我們會為大家講解如何使用HPA以及一些需要注意的細節。 autoscaling/v1實踐 v1的模板可能是大家平時見到最多的也是最簡單的,v1版本的HPA只支援一種指標 —— CPU。傳統意義上,彈性伸縮最少也會支

Kubernetes 彈性伸縮場景解析 - 讓核心組件充滿彈性

ces param serve try ingress ont 整體 per 區間 前言 在本系列的前三篇中,我們介紹了彈性伸縮的整體布局以及HPA的一些原理,HPA的部分還遺留了一些內容需要進行詳細解析。在準備這部分內容的期間,會穿插幾篇彈性伸縮組件的最佳實踐。今天我們要

Kubernetes 彈性伸縮場景解析 :概念延伸元件佈局

傳統彈性伸縮的困境 彈性伸縮是 Kubernetes 中被大家關注的一大亮點,在討論相關的元件和實現方案之前。首先想先給大家擴充下

kubernetes 1.8 高可用安裝

k8s 1.8 calico 網絡5安裝網絡組件calico安裝前需要確認kubelet配置是否已經增加--network-plugin=cni如果沒有配置就加到kubelet配置文件裏Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-

VSCode外掛開發攻略跳轉到定義、自動補、懸停提示

更多文章請戳VSCode外掛開發全攻略系列目錄導航。 跳轉到定義 跳轉到定義其實很簡單,通過vscode.languages.registerDefinitionProvider註冊一個provider,這個provider如果返回了new vscode.Location()就表示當前游標所在單詞支援跳轉

Mybatis攔截器實現通用mapper及ORM實現-- springboot+mybatis多資料來源設定

本篇實際上和mybatisext專案並沒有太大關係了,但在實際專案中脫離不開多個數據源,尤其是主從分離,同樣網上一些資料大同小異而且大部分並不能真正解決問題,所以單獨提出來說一下 假設我們就是要解決一個主從分離,資料來源定義在了application.properties中

線性表資料結構解讀雜湊表結構-HashMap

    前面的部落格中,我給大家分析過陣列和連結串列兩種線性表資料結構。陣列儲存區間連續,查詢方便,但是插入和刪除效率低下;連結串列儲存區間離散,插入刪除方便,但是查詢困難。大家肯定會問,有沒有一種結構,既能做到查詢便捷,又能做到插入刪除方便呢?答案就是我們今天

STM32F407VG 定時

博客 計數 led eba reset gpio onf cpu bsp 一、定時器節本分類和主要特點 1.STM32定時器分類: 1)看門狗定時器 2)SysTick定時器 3)RTC定時器 4)通用定時器 a)通用定時器TIM2~TIM5,

ROS系統MoveIt玩轉雙臂機器人系列--淺議機器人運動學D-H建模

就是 bubuko 一行 法線 物理 坐標系 圖1 net 機械臂 一、概述   機器人運動學研究的是機械臂各個連桿之間的位移關系、速度關系和加速度關系。比較經典的一本書推薦大家讀讀熊有倫的《機器人技術基礎》下載網址在這。本篇博文將從剛體的位姿描述講起,逐步過渡到D-H法

SpringSpring緩存機制Redis的結合

jedispool gen ali 插入數據 sco com generate ret 提高   一、Redis和數據庫的結合   使用Redis可以優化性能,但是存在Redis的數據和數據庫同步的問題。   例如,T1時刻以將 key1 保存數據到 Redis,T2時刻刷

WPF自定義控制元件の使用者控制元件完結

原文: WPF自定義控制元件(五)の使用者控制元件(完結) 使用者控制元件,WPF中是繼承自UserControl的控制元件,我們可以在裡面融合我們的業務邏輯。 示例:(一個厭惡選擇的使用者控制元件) 後端: using iMicClassBase; using iMicClassBase.B

Vue.js—— Vue基礎元件的自動化全域性註冊

在使用vue構建專案的過程中,我們會設定一些通用的元件,他可能只包含了一個按鈕或者其他的一個小功能,但是會被我們在不同的元件頁面頻繁呼叫。此時若是每一個元件頁面都進行引用,將會有很多重複冗雜的程式碼,可以改為全域性註冊。具體如下: 1. 將這些通用基礎元件放置在同一個資料夾下:如

jdk原始碼解析——虛擬機器效能監控故障處理工具

前面有一定的瞭解jvm、這裡就瞭解一下怎麼檢視虛擬機器,也就是對jvm的一個監控。 這裡主要講解jvm的相關工具以及使用: 1定義問題的思路 給一個系統定位問題的時候,知識,經驗是關鍵基礎,資料是依據,工具是運用知識處理資料的手段。這裡說的資料包括:執行日誌,異常堆疊,

理解JVM:Java記憶體模型執行緒

Java記憶體模型 JMM(Java Memory Model)是JVM定義的記憶體模型,用來遮蔽各種硬體和作業系統的記憶體訪問差異。 * 主記憶體:所有的變數都儲存在主記憶體(Main Memory,類比實體記憶體)中。 * 工作記憶體:每條執行緒有自己