到目前為止Kubernetes對基于cpu使用率的水平pod自動伸縮支持比較良好,但根據(jù)自定義metrics的HPA支持并不完善,并且使用起來也不方便。
下面介紹一個(gè)基于Prometheus和Alertmanager實(shí)現(xiàn)Kubernetes Pod 自動伸縮的方案,該方案支持任意自定義metrics。思路比較簡單:由Prometheus負(fù)責(zé)收集需要的性能指標(biāo)(如:當(dāng)前鏈接的并發(fā)數(shù),當(dāng)前cpu的使用率等),根據(jù)定義好的告警規(guī)則生成告警事件,然后將告警事件傳遞給Alertmanager,由alertmanager觸發(fā)webhook來實(shí)現(xiàn)最終的pod伸縮功能,如下圖所示:
Prometheus中Alert rules的配置示例:
ALERT HpaTrigger
IF app_active_task_count > 30
FOR 30m
LABELS {serverity = "page",trigger="hpa",action = "scale-out",value = "{{$value}}", deployment="test", namespace = "{{$labels.namespace}}"}
ANNOTATIONS {
summary = "Instance {{$labels.namespace}}: scale-out",
description = "{{$labels.namespace}} auto scale-out"
}
上述規(guī)則表示應(yīng)用的活動任務(wù)數(shù)持續(xù)30分鐘都大于30的話,就需要創(chuàng)建新的pod以應(yīng)對過多的任務(wù)數(shù)。但此處并不會直接觸發(fā)水平Pod自動伸縮功能,prometheus根據(jù)告警規(guī)則只會生成一個(gè)告警事件,并將該事件傳遞給alertmanager,由alertmanager決定如何處理該告警。
Alertmanager配置示例:
global:
route:
receiver: 'email' #全局配置,默認(rèn)將收到的告警事件路由給email接收器
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- receiver: 'auto-hpa' #將trigger=hpa的告警路由給auto-hpa
match:
trigger: hpa
receivers:
- name: 'email'
email_configs:
- to: ops@test.com
from: monitor@test.com
smarthost: smtpserver:port
auth_username: "username"
auth_identity: "username"
auth_password: "password"
require_tls: true
- name: "auto-hpa"
webhook_configs:
- url: 'http://YOUR_WEBHOOK_IP:PORT/hpa' #自定義webhook url地址。
send_resolved: true
Alertmanager接受到相應(yīng)的告警之后,會將獲取到的具體metics值(此處metric name為app_active_task_count)和在告警規(guī)則中定義的LABELS信息合并為一個(gè)json數(shù)據(jù),以POST方式發(fā)送給我我們定義好的webhook url。
webhook Python腳本示例:
from flask import Flask,request
import json
app = Flask(__name__)
@app.route("/hpa",methods=["POST"])
def hpa():
content = request.get_json()
#分析content字段,提取相關(guān)數(shù)據(jù),調(diào)用k8s api實(shí)現(xiàn)水平pod自動伸縮的功能
#.......
#.......
print content
if __name__ == "__main__":
app.run("0.0.0.0")
這里我省略了具體調(diào)用k8s api實(shí)現(xiàn)pod伸縮的邏輯。Alertmanager將所有的信息以json格式post給我們自定義的腳本了,具體怎么處理,就看業(yè)務(wù)需求了。