Pod的擴(kuò)縮容
實(shí)際生產(chǎn)系統(tǒng), 會(huì)遇到某個(gè)服務(wù)需要擴(kuò)容的場(chǎng)景锭汛,也可能會(huì)遇到由于資源緊張或者工作負(fù)載降低而需要減少服務(wù)實(shí)例數(shù)量的場(chǎng)景夏醉。
此時(shí)可以利用Deployment/RC的Scale機(jī)制來(lái)完成這些工作微驶。
Kubernetes對(duì)Pod的擴(kuò)縮容操作提供了手動(dòng)和自動(dòng)兩種模式.
手動(dòng)模式通過(guò)執(zhí)行kubectl scale命令或通過(guò)RESTful API對(duì)一個(gè)Deployment/RC進(jìn)行Pod副本數(shù)量的設(shè)置,即可一鍵完成判耕。
自動(dòng)模式則需要用戶根據(jù)某個(gè)性能指標(biāo)或者自定義業(yè)務(wù)指標(biāo)跛梗,并指定Pod副本數(shù)量的范圍寻馏,系統(tǒng)將自動(dòng)在這個(gè)范圍內(nèi)根據(jù)性能指標(biāo)的變化進(jìn)行調(diào)整。
手動(dòng)擴(kuò)縮容機(jī)制
以Deployment nginx為例:
# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
[root@k8s-master01 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-56bbb744cc-lb28h 1/1 Running 1 24h
nginx-deployment-56bbb744cc-nwhgk 1/1 Running 1 24h
nginx-deployment-56bbb744cc-z2k5h 1/1 Running 1 24h
# 通過(guò)kubectl scale命令可以將Pod副本數(shù)量從初始的3個(gè)更新為5個(gè):
[root@k8s-master01 pod]# kubectl scale deployment/nginx-deployment --replicas 5
deployment.apps/nginx-deployment scaled
[root@k8s-master01 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-56bbb744cc-5sr67 0/1 ContainerCreating 0 1s
nginx-deployment-56bbb744cc-lb28h 1/1 Running 1 24h
nginx-deployment-56bbb744cc-nwhgk 1/1 Running 1 24h
nginx-deployment-56bbb744cc-wxn5c 0/1 ContainerCreating 0 1s
nginx-deployment-56bbb744cc-z2k5h 1/1 Running 1 24h
# 將--replicas設(shè)置為比當(dāng)前Pod副本數(shù)量更小的數(shù)字,系統(tǒng)將會(huì)“殺掉”一些運(yùn)行中的Pod茄袖,以實(shí)現(xiàn)應(yīng)用集群縮容:
[root@k8s-master01 pod]# kubectl scale deployment/nginx-deployment --replicas 1
deployment.apps/nginx-deployment scaled
[root@k8s-master01 pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-56bbb744cc-z2k5h 1/1 Running 1 24h
自動(dòng)擴(kuò)縮容機(jī)制
Kubernetes從1.1版本開(kāi)始操软,新增了名為Horizontal Pod Autoscaler(HPA)的控制器,用于實(shí)現(xiàn)基于CPU使用率進(jìn)行自動(dòng)Pod擴(kuò)縮容的功能宪祥。
HPA控制器基于Master的kube-controller-manager服務(wù)啟動(dòng)參數(shù)--horizontal-pod-autoscaler-sync-period定義的探測(cè)周期(默認(rèn)值為15s)聂薪,周期性地監(jiān)測(cè)目標(biāo)Pod的資源性能指標(biāo),并與HPA資源對(duì)象中的擴(kuò)縮容條件進(jìn)行對(duì)比蝗羊,在滿足條件時(shí)對(duì)Pod副本數(shù)量進(jìn)行調(diào)整藏澳。
HPA的工作原理
Kubernetes中的某個(gè)Metrics Server(Heapster或自定義Metrics Server)持續(xù)采集所有Pod副本的指標(biāo)數(shù)據(jù)。
HPA控制器通過(guò)Metrics Server的API(Heapster的API或聚合API)獲取這些數(shù)據(jù)耀找,基于用戶定義的擴(kuò)縮容規(guī)則進(jìn)行計(jì)算翔悠,得到目標(biāo)Pod副本數(shù)量业崖。
當(dāng)目標(biāo)Pod副本數(shù)量與當(dāng)前副本數(shù)量不同時(shí),HPA控制器就向Pod的副本控制器(Deployment蓄愁、RC或ReplicaSet)發(fā)起scale操作双炕,調(diào)整Pod的副本數(shù)量,完成擴(kuò)縮容操作撮抓。
指標(biāo)的類型
Master的kube-controller-manager服務(wù)持續(xù)監(jiān)測(cè)目標(biāo)Pod的某種性能指標(biāo)妇斤,以計(jì)算是否需要調(diào)整副本數(shù)量。
目前Kubernetes支持的指標(biāo)類型如下丹拯。
- Pod資源使用率:Pod級(jí)別的性能指標(biāo)站超,通常是一個(gè)比率值,例如CPU使用率乖酬。
- Pod自定義指標(biāo):Pod級(jí)別的性能指標(biāo)死相,通常是一個(gè)數(shù)值,例如接收的請(qǐng)求數(shù)量咬像。
- Object自定義指標(biāo)或外部自定義指標(biāo):通常是一個(gè)數(shù)值算撮,需要容器應(yīng)用以某種方式提供,例如通過(guò)HTTP URL“/metrics”提供施掏,或者使用外部服務(wù)提供的指標(biāo)采集URL钮惠。
Kubernetes從1.11版本開(kāi)始茅糜,棄用F甙拧!蔑赘! 基于Heapster組件完成Pod的CPU使用率采集的機(jī)制狸驳,全面轉(zhuǎn)向基于Metrics Server完成數(shù)據(jù)采集。
Metrics Server將采集到的Pod性能指標(biāo)數(shù)據(jù)通過(guò)聚合API(Aggregated API)如metrics.k8s.io缩赛、custom.metrics.k8s.io和external.metrics.k8s.io提供給HPA控制器進(jìn)行查詢耙箍。
擴(kuò)縮容算法詳解
Autoscaler控制器從聚合API獲取到Pod性能指標(biāo)數(shù)據(jù)之后,基于下面的算法計(jì)算出目標(biāo)Pod副本數(shù)量酥馍,與當(dāng)前運(yùn)行的Pod副本數(shù)量進(jìn)行對(duì)比辩昆,決定是否需要進(jìn)行擴(kuò)縮容操作:
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desireMetricValue)]
即當(dāng)前副本數(shù) ×(當(dāng)前指標(biāo)值/期望的指標(biāo)值),將結(jié)果向上取整旨袒。
以CPU請(qǐng)求數(shù)量為例汁针,如果用戶設(shè)置的期望指標(biāo)值為100m,當(dāng)前實(shí)際使用的指標(biāo)值為200m砚尽,則計(jì)算得到期望的Pod副本數(shù)量應(yīng)為兩個(gè)(200/100=2)施无。如果設(shè)置的期望指標(biāo)值為50m,計(jì)算結(jié)果為0.5必孤,則向上取整值為1猾骡,得到目標(biāo)Pod副本數(shù)量應(yīng)為1個(gè)。
當(dāng)計(jì)算結(jié)果與1非常接近時(shí),可以設(shè)置一個(gè)容忍度讓系統(tǒng)不做擴(kuò)縮容操作兴想。容忍度通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-tolerance進(jìn)行設(shè)置幢哨,默認(rèn)值為0.1(即10%),表示基于上述算法得到的結(jié)果在[-10% - +10%]區(qū)間內(nèi)嫂便,即[0.9 - 1.1]嘱么,控制器都不會(huì)進(jìn)行擴(kuò)縮容操作。
也可以將期望指標(biāo)值(desiredMetricValue)設(shè)置為指標(biāo)的平均值類型顽悼,例如targetAverageValue或targetAverageUtilization曼振,此時(shí)當(dāng)前指標(biāo)值(currentMetricValue)的算法為所有Pod副本當(dāng)前指標(biāo)值的總和除以Pod副本數(shù)量得到的平均值。
此外蔚龙,存在幾種Pod異常的情況冰评,如下所述。
- Pod正在被刪除(設(shè)置了刪除時(shí)間戳):將不會(huì)計(jì)入目標(biāo)Pod副本數(shù)量木羹。
- Pod的當(dāng)前指標(biāo)值無(wú)法獲得:本次探測(cè)不會(huì)將這個(gè)Pod納入目標(biāo)Pod副本數(shù)量甲雅,后續(xù)的探測(cè)會(huì)被重新納入計(jì)算范圍。
- 如果指標(biāo)類型是CPU使用率坑填,則對(duì)于正在啟動(dòng)但是還未達(dá)到Ready狀態(tài)的Pod抛人,也暫時(shí)不會(huì)納入目標(biāo)副本數(shù)量范圍∑旯澹可以通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-initial-readiness-delay設(shè)置首次探測(cè)Pod是否Ready的延時(shí)時(shí)間妖枚,默認(rèn)值為30s。另一個(gè)啟動(dòng)參數(shù)--horizontal-pod-autoscaler-cpuinitialization-period設(shè)置首次采集Pod的CPU使用率的延時(shí)時(shí)間苍在。
在計(jì)算“當(dāng)前指標(biāo)值/期望的指標(biāo)值”(currentMetricValue / desiredMetricValue)時(shí)將不會(huì)包括上述這些異常Pod
當(dāng)存在缺失指標(biāo)的Pod時(shí)绝页,系統(tǒng)將更保守地重新計(jì)算平均值。系統(tǒng)會(huì)假設(shè)這些Pod在需要縮容(Scale Down)時(shí)消耗了期望指標(biāo)值的100%寂恬,在需要擴(kuò)容(Scale Up)時(shí)消耗了期望指標(biāo)值的0%续誉,這樣可以抑制潛在的擴(kuò)縮容操作。
此外初肉,如果存在未達(dá)到Ready狀態(tài)的Pod酷鸦,并且系統(tǒng)原本會(huì)在不考慮缺失指標(biāo)或NotReady的Pod情況下進(jìn)行擴(kuò)展,則系統(tǒng)仍然會(huì)保守地假設(shè)這些Pod消耗期望指標(biāo)值的0%牙咏,從而進(jìn)一步抑制擴(kuò)容操作臼隔。
如果在HorizontalPodAutoscaler中設(shè)置了多個(gè)指標(biāo),系統(tǒng)就會(huì)對(duì)每個(gè)指標(biāo)都執(zhí)行上面的算法眠寿,在全部結(jié)果中以期望副本數(shù)的最大值為最終結(jié)果躬翁。如果這些指標(biāo)中的任意一個(gè)都無(wú)法轉(zhuǎn)換為期望的副本數(shù)(例如無(wú)法獲取指標(biāo)的值),系統(tǒng)就會(huì)跳過(guò)擴(kuò)縮容操作盯拱。
最后盒发,在HPA控制器執(zhí)行擴(kuò)縮容操作之前例嘱,系統(tǒng)會(huì)記錄擴(kuò)縮容建議信息(Scale Recommendation)∧ⅲ控制器會(huì)在操作時(shí)間窗口(時(shí)間范圍可以配置)中考慮所有的建議信息拼卵,并從中選擇得分最高的建議。這個(gè)值可通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-downscale-stabilization-window進(jìn)行配置蛮艰,默認(rèn)值為5min腋腮。這個(gè)配置可以讓系統(tǒng)更為平滑地進(jìn)行縮容操作,從而消除短時(shí)間內(nèi)指標(biāo)值快速波動(dòng)產(chǎn)生的影響壤蚜。
HorizontalPodAutoscaler配置詳解
Kubernetes將HorizontalPodAutoscaler資源對(duì)象提供給用戶來(lái)定義擴(kuò)縮容的規(guī)則即寡。
HorizontalPodAutoscaler資源對(duì)象處于Kubernetes的API組“autoscaling”中,目前包括v1和v2兩個(gè)版本
其中autoscaling/v1僅支持基于CPU使用率的自動(dòng)擴(kuò)縮容袜刷,autoscaling/v2則用于支持基于任意指標(biāo)的自動(dòng)擴(kuò)縮容配置聪富,包括基于資源使用率、Pod指標(biāo)著蟹、其他指標(biāo)等類型的指標(biāo)數(shù)據(jù)墩蔓,當(dāng)前版本為autoscaling/v2beta2。
下面對(duì)HorizontalPodAutoscaler的配置和用法進(jìn)行說(shuō)明萧豆。
(1)基于autoscaling/v1版本的HorizontalPodAutoscaler配置奸披,僅可以設(shè)置CPU使用率:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
主要參數(shù)如下
- scaleTargetRef:目標(biāo)作用對(duì)象,可以是Deployment涮雷、ReplicationController或ReplicaSet阵面。
- targetCPUUtilizationPercentage:期望每個(gè)Pod的CPU使用率都為50%,該使用率基于Pod設(shè)置的CPU Request值進(jìn)行計(jì)算份殿,例如該值為200m膜钓,那么系統(tǒng)將維持Pod的實(shí)際CPU使用值為100m嗽交。
- minReplicas和maxReplicas:Pod副本數(shù)量的最小值和最大值卿嘲,系統(tǒng)將在這個(gè)范圍內(nèi)進(jìn)行自動(dòng)擴(kuò)縮容操作,并維持每個(gè)Pod的CPU使用率為50%夫壁。
為了使用autoscaling/v1版本的HorizontalPodAutoscaler拾枣,需要預(yù)先安裝Heapster組件或Metrics Server,用于采集Pod的CPU使用率盒让。
Heapster從Kubernetes 1.11版本開(kāi)始進(jìn)入棄用階段梅肤,不再對(duì)Heapster進(jìn)行詳細(xì)說(shuō)明。
(2)基于autoscaling/v2beta2的HorizontalPodAutoscaler配置:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
主要參數(shù)如下邑茄。
- scaleTargetRef:目標(biāo)作用對(duì)象姨蝴,可以是Deployment、ReplicationController或ReplicaSet肺缕。
- minReplicas和maxReplicas:Pod副本數(shù)量的最小值和最大值左医,系統(tǒng)將在這個(gè)范圍內(nèi)進(jìn)行自動(dòng)擴(kuò)縮容操作授帕,并維持每個(gè)Pod的CPU使用率為50%。
- metrics:目標(biāo)指標(biāo)值浮梢。在metrics中通過(guò)參數(shù)type定義指標(biāo)的類型跛十;通過(guò)參數(shù)target定義相應(yīng)的指標(biāo)目標(biāo)值,系統(tǒng)將在指標(biāo)數(shù)據(jù)達(dá)到目標(biāo)值時(shí)(考慮容忍度的區(qū)間秕硝,見(jiàn)前面算法部分的說(shuō)明)觸發(fā)擴(kuò)縮容操作芥映。
可以將metrics中的type(指標(biāo)類型)設(shè)置為以下三種,可以設(shè)置一個(gè)或多個(gè)組合远豺,如下所述奈偏。
(1)Resource:基于資源的指標(biāo)值,可以設(shè)置的資源為CPU和內(nèi)存躯护。
(2)Pods:基于Pod的指標(biāo)霎苗,系統(tǒng)將對(duì)全部Pod副本的指標(biāo)值進(jìn)行平均值計(jì)算。
(3)Object:基于某種資源對(duì)象(如Ingress)的指標(biāo)或應(yīng)用系統(tǒng)的任意自定義指標(biāo)榛做。
Resource類型的指標(biāo)可以設(shè)置CPU和內(nèi)存唁盏。
- 對(duì)于CPU使用率,在target參數(shù)中設(shè)置averageUtilization定義目標(biāo)平均CPU使用率检眯。
- 對(duì)于內(nèi)存資源厘擂,在target參數(shù)中設(shè)置AverageValue定義目標(biāo)平均內(nèi)存使用值。
指標(biāo)數(shù)據(jù)可以通過(guò)API“metrics.k8s.io”進(jìn)行查詢锰瘸,要求預(yù)先啟動(dòng)Metrics Server服務(wù)刽严。
Pods類型和Object類型都屬于自定義指標(biāo)類型,指標(biāo)的數(shù)據(jù)通常需要搭建自定義Metrics Server和監(jiān)控工具進(jìn)行采集和處理避凝。指標(biāo)數(shù)據(jù)可以通過(guò)API“custom.metrics.k8s.io”進(jìn)行查詢舞萄,要求預(yù)先啟動(dòng)自定義Metrics Server服務(wù)。
類型為Pods的指標(biāo)數(shù)據(jù)來(lái)源于Pod對(duì)象本身管削,其target指標(biāo)類型只能使用AverageValue倒脓,示例如下:
metrics:
- type: Pods
pods:
metric:
name: packets-per-second
target:
type: AverageValue
averageValue: 1k
其中,設(shè)置Pod的指標(biāo)名為packets-per-second含思,在目標(biāo)指標(biāo)平均值為1000時(shí)觸發(fā)擴(kuò)縮容操作崎弃。
類型為Object的指標(biāo)數(shù)據(jù)來(lái)源于其他資源對(duì)象或任意自定義指標(biāo),其target指標(biāo)類型可以使用Value或AverageValue(根據(jù)Pod副本數(shù)計(jì)算平均值)進(jìn)行設(shè)置含潘。下面對(duì)幾種常見(jiàn)的自定義指標(biāo)給出示例和說(shuō)明饲做。
例1,設(shè)置指標(biāo)的名稱為requests-per-second遏弱,其值來(lái)源于Ingress “main-route”盆均,將目標(biāo)值(value)設(shè)置為2000,即在Ingress的每秒請(qǐng)求數(shù)量達(dá)到2000個(gè)時(shí)觸發(fā)擴(kuò)縮容操作:
metrics:
- type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
kind: Ingress
name: main-route
target:
type: Value
value: 2k
例2漱逸,設(shè)置指標(biāo)的名稱為http_requests泪姨,并且該資源對(duì)象具有標(biāo)簽“verb=GET”居砖,在指標(biāo)平均值達(dá)到500時(shí)觸發(fā)擴(kuò)縮容操作
metrics:
- type: Object
object:
metric:
name: 'http_requests'
selector: 'verb=GET'
target:
type: AverageValue
AverageValue: 500
還可以在同一個(gè)HorizontalPodAutoscaler資源對(duì)象中定義多個(gè)類型的指標(biāo),系統(tǒng)將針對(duì)每種類型的指標(biāo)都計(jì)算Pod副本的目標(biāo)數(shù)量驴娃,以最大值為準(zhǔn)進(jìn)行擴(kuò)縮容操作奏候。例如:
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: AverageUtilization
averageUtilization: 50
- type: Pods
pods:
metric:
name: packets-per-second
targetAverageValue: 1k
- type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
kind: Ingress
name: main-route
target:
kind: Value
value: 10k
從1.10版本開(kāi)始,Kubernetes引入了對(duì)外部系統(tǒng)指標(biāo)的支持唇敞。例如蔗草,用戶使用了公有云服務(wù)商提供的消息服務(wù)或外部負(fù)載均衡器,希望基于這些外部服務(wù)的性能指標(biāo)(如消息服務(wù)的隊(duì)列長(zhǎng)度疆柔、負(fù)載均衡器的QPS)對(duì)自己部署在Kubernetes中的服務(wù)進(jìn)行自動(dòng)擴(kuò)縮容操作咒精。這時(shí),就可以在metrics參數(shù)部分設(shè)置type為External來(lái)設(shè)置自定義指標(biāo)旷档,然后就可以通過(guò)API“external.metrics.k8s.io”查詢指標(biāo)數(shù)據(jù)了模叙。當(dāng)然,這同樣要求自定義Metrics Server服務(wù)已正常工作鞋屈。
例3范咨,設(shè)置指標(biāo)的名稱為queue_messages_ready,具有queue=worker_tasks標(biāo)簽在目標(biāo)指標(biāo)平均值為30時(shí)觸發(fā)自動(dòng)擴(kuò)縮容操作:
- type: External
external:
metric:
name: queue_messages_ready
selector: "queue=worker_tasks"
target:
type: AverageValue
averageValue: 30
在使用外部服務(wù)的指標(biāo)時(shí)厂庇,要安裝渠啊、部署能夠?qū)拥終ubernetes HPA模型的監(jiān)控系統(tǒng),并且完全了解監(jiān)控系統(tǒng)采集這些指標(biāo)的機(jī)制权旷,后續(xù)的自動(dòng)擴(kuò)縮容操作才能完成替蛉。
Kubernetes推薦盡量使用type為Object的HPA配置方式,這可以通過(guò)使用Operator模式拄氯,將外部指標(biāo)通過(guò)CRD(自定義資源)定義為API資源對(duì)象來(lái)實(shí)現(xiàn)躲查。
基于自定義指標(biāo)的HPA實(shí)踐
通過(guò)一個(gè)完整的示例,對(duì)如何搭建和使用基于自定義指標(biāo)的HPA體系進(jìn)行說(shuō)明译柏。
基于自定義指標(biāo)進(jìn)行自動(dòng)擴(kuò)縮容時(shí)镣煮,需要預(yù)先部署自定義Metrics Server,目前可以使用基于Prometheus艇纺、Microsoft Azure怎静、Datadog Cluster等系統(tǒng)的Adapter實(shí)現(xiàn)自定義Metrics Server,未來(lái)還將提供基于Google Stackdriver的實(shí)現(xiàn)自定義Metrics Server黔衡。讀者可以參考官網(wǎng) https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custommetrics-api 的說(shuō)明。
基于Prometheus監(jiān)控系統(tǒng)對(duì)HPA的基礎(chǔ)組件部署和HPA配置進(jìn)行詳細(xì)說(shuō)明腌乡。
基于Prometheus的HPA架構(gòu)如圖
關(guān)鍵組件包括如下:
- Prometheus:定期采集各Pod的性能指標(biāo)數(shù)據(jù)盟劫。
- Custom Metrics Server:自定義Metrics Server,用Prometheus Adapter進(jìn)行具體實(shí)現(xiàn)与纽。它從Prometheus服務(wù)采集性能指標(biāo)數(shù)據(jù)侣签,通過(guò)Kubernetes的Metrics Aggregation層將自定義指標(biāo)API注冊(cè)到Master的API Server中塘装,以/apis/custom.metrics.k8s.io路徑提供指標(biāo)數(shù)據(jù)。
- HPA Controller:Kubernetes的HPA控制器影所,基于用戶定義的HorizontalPodAutoscaler進(jìn)行自動(dòng)擴(kuò)縮容操作蹦肴。
接下來(lái)對(duì)整個(gè)系統(tǒng)的部署過(guò)程進(jìn)行說(shuō)明。
(1)在Master的API Server啟動(dòng)Aggregation層猴娩,通過(guò)設(shè)置kube-apiserver服務(wù)的下列啟動(dòng)參數(shù)進(jìn)行開(kāi)啟阴幌。
- --requestheader-client-ca-file=/etc/kubernetes/ssl_keys/ca.crt:客戶端CA證書(shū)。
- --requestheader-allowed-names=:允許訪問(wèn)的客戶端common names列表卷中,通過(guò)header中由--requestheader-username-headers參數(shù)指定的字段獲取矛双。客戶端common names的名稱需要在client-ca-file中進(jìn)行配置蟆豫,將其設(shè)置為空值時(shí)议忽,表示任意客戶端都可以訪問(wèn)。
- --requestheader-extra-headers-prefix=X-Remote-Extra-:請(qǐng)求頭中需要檢查的前綴名十减。
- --requestheader-group-headers=X-Remote-Group:請(qǐng)求頭中需要檢查的組名栈幸。
- --requestheader-username-headers=X-Remote-User:請(qǐng)求頭中需要檢查的用戶名。
- --proxy-client-cert-file=/etc/kubernetes/ssl_keys/kubelet_client.crt:在請(qǐng)求期間驗(yàn)證Aggregator的客戶端CA證書(shū)帮辟。
- --proxy-client-key-file=/etc/kubernetes/ssl_keys/kubelet_client.key:在請(qǐng)求期間驗(yàn)證Aggregator的客戶端私鑰侦镇。
配置kube-controller-manager服務(wù)中HPA的相關(guān)啟動(dòng)參數(shù)(可選配置)如下。
- --horizontal-pod-autoscaler-sync-period=10s:HPA控制器同步Pod副本數(shù)量的時(shí)間間隔织阅,默認(rèn)值為15s壳繁。
- --horizontal-pod-autoscaler-downscale-stabilization=1m0s:執(zhí)行縮容操作的等待時(shí)長(zhǎng),默認(rèn)值為5min荔棉。
- --horizontal-pod-autoscaler-initial-readiness-delay=30s:等待Pod達(dá)到Ready狀態(tài)的時(shí)延闹炉,默認(rèn)值為30min。
- --horizontal-pod-autoscaler-tolerance=0.1:擴(kuò)縮容計(jì)算結(jié)果的容忍度润樱,默認(rèn)值為0.1渣触,表示[-10% - +10%]。
(2)部署Prometheus壹若,這里使用Operator模式進(jìn)行部署嗅钻。
首先,使用下面的YAML配置文件部署prometheus-operator:
# 1. prometheus-operator
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
k8s-app: prometheus-operator
name: prometheus-operator
spec:
replicas: 1
selector:
matchLabels:
k8s-app: prometheus-operator
template:
metadata:
labels:
k8s-app: prometheus-operator
spec:
containers:
- image: quay.io/coreos/prometheus-operator:v0.17.0
imagePullPolicy: IfNotPresent
name: prometheus-operator
ports:
- containerPort: 8080
name: http
resources:
limits:
cpu: 200m
memory: 100Mi
requests:
cpu: 100m
memory: 50Mi