建站
咨詢
售后
建站咨詢
新聞中心
目錄：
實(shí)踐1:基于autoscaling cpu指標(biāo)的擴(kuò)容與縮容
實(shí)踐2:基于prometheus自定義指標(biāo)QPS的擴(kuò)容與縮容
Pod自動(dòng)擴(kuò)容/縮容（HPA）Horizontal Pod Autoscaler（HPA，Pod水平自動(dòng)伸縮），根據(jù)資源利用率或者自定義指標(biāo)自動(dòng)調(diào)整replication controller, deployment 或 replica set，實(shí)現(xiàn)部署的自動(dòng)擴(kuò)展和縮減，讓部署的規(guī)模接近于實(shí)際服務(wù)的負(fù)載。HPA不適于無(wú)法縮放的對(duì)象，例如DaemonSet。
HPA主要是對(duì)pod資源的一個(gè)計(jì)算，對(duì)當(dāng)前的副本數(shù)量增加或者減少。
HPA大概是這樣的，我們需要?jiǎng)?chuàng)建一個(gè)hpa的規(guī)則，設(shè)置這樣的一個(gè)規(guī)則對(duì)pod實(shí)現(xiàn)一個(gè)擴(kuò)容或者縮容，主要針對(duì)deployment,當(dāng)你當(dāng)前設(shè)置的資源利用率超出你設(shè)置的預(yù)值，它會(huì)幫你擴(kuò)容縮容這些副本。
1、HPA基本原理
Kubernetes 中的 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ò)縮容操作。如圖所示。
在彈性伸縮中，冷卻周期是不能逃避的一個(gè)話題， 由于評(píng)估的度量標(biāo)準(zhǔn)是動(dòng)態(tài)特性，副本的數(shù)量可能會(huì)不斷波動(dòng)。有時(shí)被稱為顛簸， 所以在每次做出擴(kuò)容縮容后，冷卻時(shí)間是多少。
來(lái)看這張圖，首先hpa要?jiǎng)?chuàng)建一個(gè)規(guī)則，就像我們之前創(chuàng)建ingress的規(guī)則一樣，里面定義好一個(gè)擴(kuò)容縮容的一個(gè)范圍然后指定好對(duì)象，指定好它的預(yù)值，hpa本身就是一個(gè)控制器，循環(huán)的控制器，它會(huì)不斷的從metrics server 中去獲取這個(gè)指標(biāo)，判斷這個(gè)預(yù)值是不是到達(dá)你設(shè)置規(guī)則的預(yù)值，如果是的話，就會(huì)去執(zhí)行這個(gè)scale幫你擴(kuò)容這個(gè)副本，如果長(zhǎng)期處于一個(gè)低使用率的情況下，它會(huì)幫你縮容這個(gè)副本，這個(gè)metrics server的資源來(lái)源是來(lái)自于cadvisor去拿的，想一下cadvisor可以提供那些指標(biāo)，hpa可以拿到的，比如cpu,內(nèi)存的使用率，主要采集你這些的利用率，所以hpa在早期已經(jīng)支持了對(duì)CPU的彈性伸縮
Hpa就是k8s中這個(gè)pod水平擴(kuò)容的一個(gè)控制器，但是要實(shí)現(xiàn)
Pod的擴(kuò)容，他需要一定的條件，他要拿一定的指標(biāo)，這里是有預(yù)值的，他要判斷你的指標(biāo)，是不是超出這個(gè)預(yù)值，對(duì)你進(jìn)行縮容擴(kuò)容，所以要想得到這個(gè)指標(biāo)，你還需要裝一個(gè)組件，metrics server,在之前呢這個(gè)組件的實(shí)現(xiàn)是由heapster heapstar現(xiàn)在已經(jīng)是慢慢棄用了，基本上不怎么去使用heapstat了，所以metrics server來(lái)提供這些數(shù)據(jù)，提供這些資源的利用率。
比如有三個(gè)副本，來(lái)實(shí)現(xiàn)三個(gè)pod的伸縮，所以有東西去判定資源的利用率，比如基于cpu的，計(jì)算3個(gè)pod的資源利用率，例如3個(gè)pod的資源利用率是50%,拿到這個(gè)值之后，你就要去使用這個(gè)hpa,這個(gè)里面會(huì)定義個(gè)預(yù)值，有個(gè)規(guī)則，這個(gè)預(yù)值設(shè)置60%，它會(huì)周期性的與cpu去匹配，如果超出這個(gè)60%，那么就去擴(kuò)容，這里還有定義擴(kuò)容pod副本的數(shù)量
比如我這組pod的訪問(wèn)量是異常的，比如受到一些小我的cpu就超過(guò)50%，如果沒(méi)有限制去大擴(kuò)容到多大的副本，它會(huì)無(wú)限的增大，之前3個(gè)副本可能一下就增加了10個(gè)副本，甚至50個(gè)，那么很快就能拖死整個(gè)集群，所以在hpa中都設(shè)置3個(gè)指標(biāo)，第一個(gè)設(shè)置，pod的區(qū)間值，這個(gè)大能擴(kuò)容多少個(gè)pod,最小是多少個(gè)pod,比如1-10，最小可以創(chuàng)建1個(gè)，大可以創(chuàng)建10個(gè)，這是一個(gè)縮容擴(kuò)容的一個(gè)范圍值，接下來(lái)就是一個(gè)預(yù)值的判斷，第三個(gè)就是操作哪個(gè)對(duì)象，哪一組pod,這三個(gè)都是要在hpa中去判斷的
那么在什么情況下，去縮容擴(kuò)容
擴(kuò)容就是資源不夠了超過(guò)這個(gè)60%了，但是在這個(gè)區(qū)間它是由個(gè)狀態(tài)轉(zhuǎn)化的，一個(gè)是擴(kuò)容的狀態(tài)，一個(gè)是縮容的狀態(tài)，這兩個(gè)狀態(tài)就好比現(xiàn)在的資源利用率60%了，進(jìn)行擴(kuò)容了，有3個(gè)副本就擴(kuò)容到10個(gè)副本了，這是沒(méi)問(wèn)題的，然后馬上這個(gè)值下來(lái)了，之前是到了70%-80%了，現(xiàn)在一下到了20%,從10直接縮容到5個(gè)，這兩個(gè)是有狀態(tài)轉(zhuǎn)化的，所以hpa得基于保證說(shuō)不可能狀態(tài)轉(zhuǎn)化的區(qū)間頻率太高，如果太高就會(huì)出現(xiàn)好比時(shí)好時(shí)壞，間歇性的突發(fā)，并不是一直的突發(fā)，它會(huì)導(dǎo)致一會(huì)擴(kuò)一會(huì)縮，最后導(dǎo)致這個(gè)應(yīng)用不穩(wěn)定，所以hpa就有一個(gè)冷卻的機(jī)制，第一次擴(kuò)容之后，第二次要想擴(kuò)容必須經(jīng)過(guò)這個(gè)冷卻時(shí)間，那么默認(rèn)是3分鐘，縮容呢，第一次后，第二次縮容要等5分鐘之后，這就是一個(gè)默認(rèn)的一個(gè)值，來(lái)保障你當(dāng)前業(yè)務(wù)的穩(wěn)定性，是通過(guò)kube-controller-manager組件啟動(dòng)參數(shù)設(shè)置的
在 HPA 中，默認(rèn)的擴(kuò)容冷卻周期是 3 分鐘，縮容冷卻周期是 5 分鐘。
可以通過(guò)調(diào)整kube-controller-manager組件啟動(dòng)參數(shù)設(shè)置冷卻時(shí)間：
? --horizontal-pod-autoscaler-downscale-delay ：擴(kuò)容冷卻
? --horizontal-pod-autoscaler-upscale-delay ：縮容冷卻2、HPA的演進(jìn)歷程
目前 HPA 已經(jīng)支持了 autoscaling/v1、autoscaling/v2beta1和autoscaling/v2beta2 三個(gè)大版本 。
目前大多數(shù)人比較熟悉是autoscaling/v1，這個(gè)版本只支持CPU一個(gè)指標(biāo)的彈性伸縮。
這個(gè)也比較簡(jiǎn)單，創(chuàng)建一個(gè)規(guī)則，使用采集的組件就能用了，
而autoscaling/v2beta1增加了支持自定義指標(biāo)，除了cadvisor暴露的指標(biāo)外，還支持自定義指標(biāo)，比如像第三方提供的QPS,或者基于其他的一些資源進(jìn)行擴(kuò)容，就是支持一些第三方的一些組件了。
autoscaling/v2beta2又額外增加了外部指標(biāo)支持。
而產(chǎn)生這些變化不得不提的是Kubernetes社區(qū)對(duì)監(jiān)控與監(jiān)控指標(biāo)的認(rèn)識(shí)認(rèn)識(shí)與轉(zhuǎn)變。從早期Heapster到Metrics Server再到將指標(biāo)邊界進(jìn)行劃分，一直在豐富監(jiān)控生態(tài)。
所以有這些指標(biāo)的變化，k8s對(duì)監(jiān)控的認(rèn)識(shí)進(jìn)行了轉(zhuǎn)變，因?yàn)閺椥陨炜s，在k8s中含金量還是比較高的，之前是沒(méi)有太好的方案，所以在這一塊也不是應(yīng)用很多，然后再到社區(qū)對(duì)這一塊進(jìn)行完善，現(xiàn)在應(yīng)用的也逐漸增多了。
實(shí)例
V1版本就是一個(gè)cpu的一個(gè)限制，其實(shí)早期也會(huì)內(nèi)存也進(jìn)行開(kāi)放，后期只針對(duì)cpu進(jìn)行了限制，因?yàn)橹槐┞禼pu，是因?yàn)楸┞秲?nèi)存并不是使用彈性伸縮的一個(gè)指標(biāo)，因?yàn)橄褚粋€(gè)內(nèi)存都會(huì)有一些應(yīng)用去管理，比如java，內(nèi)存都是有一個(gè)jvm去管理，所以使用內(nèi)存擴(kuò)容的一個(gè)指標(biāo)，并不是很好，所以只暴露了cpu的指標(biāo)，cpu還是比較準(zhǔn)確的，pod，cpu利用率上來(lái)之后，負(fù)載高了，流量高了，所以這塊參考價(jià)值比較大的，所以只使用cpu,在這里指定一個(gè)百分比就行。
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50：v2beta2版本
就支持了很多的自定義的東西，比如resource,pods.object,external
可以根據(jù)cpu做一些pod暴露指標(biāo)方面的工作，也可以針對(duì)第三方的一些指標(biāo)，還有一些第三方的指標(biāo)，像消息隊(duì)列之類的，
V2支持的更多了
2.5 基于CPU指標(biāo)縮放
1、 Kubernetes API Aggregation
在 Kubernetes 1.7 版本引入了聚合層，允許第三方應(yīng)用程序通過(guò)將自己注冊(cè)到kube-apiserver上，仍然通過(guò) API Server 的 HTTP URL 對(duì)新的 API 進(jìn)行訪問(wèn)和操作。為了實(shí)現(xiàn)這個(gè)機(jī)制，Kubernetes 在 kube-apiserver 服務(wù)中引入了一個(gè) API 聚合層（API Aggregation Layer），用于將擴(kuò)展 API 的訪問(wèn)請(qǐng)求轉(zhuǎn)發(fā)到用戶服務(wù)的功能。
要使用v1版本基于cpu指標(biāo)縮放，首先要開(kāi)啟API的聚合，在k8s1.7版本中去引入的，它引入是想讓第三方的應(yīng)用程序注冊(cè)進(jìn)來(lái)，都能注冊(cè)到api中，去訪問(wèn)這個(gè)api時(shí)就能調(diào)用這個(gè)組件了，這張圖，首先api的聚合時(shí)從API server去啟用的，上面當(dāng)作API server ，下面當(dāng)作組件，APIserver它本身就是以后端聚合層后面的，只不過(guò)它都在這個(gè)里面實(shí)現(xiàn)了，實(shí)際上apiserver在聚合層后面，可以把聚合層當(dāng)作一個(gè)代理層，就像nginx代理web一樣，代理的話就可以代理多個(gè)了，就不局限于apiserver了，像metrics server,自己開(kāi)發(fā)的一個(gè)組件也能注冊(cè)進(jìn)來(lái)，然后讓他代理，它代理之后就可以訪問(wèn)api，從而訪問(wèn)到這個(gè)組件了，那么聚合層就像請(qǐng)求的url幫你轉(zhuǎn)發(fā)到后面的組件上，后面的組件都會(huì)對(duì)應(yīng)api，根據(jù)注冊(cè)到聚合層的api轉(zhuǎn)發(fā)，簡(jiǎn)而言之就是擴(kuò)展api的功能，就是方便自己開(kāi)發(fā)的組件，集成到這個(gè)api里面，就像調(diào)用api一樣調(diào)用你的組件，其實(shí)這就是一個(gè)聚合層的目的，在k8s中如果使用kubeadm部署的，默認(rèn)的聚合層已經(jīng)是啟用了，如果是二進(jìn)制的部署方式去部署的，那么要按二進(jìn)制的方式去啟動(dòng)聚合層，這個(gè)根據(jù)自己的環(huán)境去啟動(dòng)，因?yàn)槊總€(gè)人部署的二進(jìn)制都不一樣。
需要在kube-APIServer中添加啟動(dòng)參數(shù)，增加以下參數(shù)
vi /opt/kubernetes/cfg/kube-apiserver.conf
...
--requestheader-client-ca-file=/opt/kubernetes/ssl/ca.pem \
--proxy-client-cert-file=/opt/kubernetes/ssl/server.pem \
--proxy-client-key-file=/opt/kubernetes/ssl/server-key.pem \
--requestheader-allowed-names=kubernetes \
--requestheader-extra-headers-prefix=X-Remote-Extra- \
--requestheader-group-headers=X-Remote-Group \
--requestheader-username-headers=X-Remote-User \
--enable-aggregator-routing=true \
...第一行指定的根證書(shū)，就是訪問(wèn)聚合層也要有一定的認(rèn)證，不是誰(shuí)的都能訪問(wèn)，本身也有一定的安全機(jī)制存在，也就是一個(gè)可信任的ca
第二，三行代理的是客戶端的證書(shū)，大致的意思是放在聚合層進(jìn)行認(rèn)證的，來(lái)判斷你是否有機(jī)制來(lái)訪問(wèn)
第四行的就是允許的名稱，這個(gè)是提供的證書(shū)里面的，來(lái)判段這個(gè)名稱是不是能夠訪問(wèn)，這個(gè)我使用的是apiserver的證書(shū)，也可以使用ca單獨(dú)為這個(gè)生成一個(gè)新的證書(shū)
第五行，請(qǐng)求頭來(lái)判斷是否可以訪問(wèn)
第六行，就是啟動(dòng)聚合層的路由
重啟這個(gè)字段[root@k8s-master1 ~]# vim /opt/kubernetes/cfg/kube-apiserver.conf
將開(kāi)始聚合層的配置添加進(jìn)入
[root@k8s-master1 ~]# systemctl restart kube-apiserver
[root@k8s-master1 ~]# ps -ef |grep kube-apiserver2、部署 Metrics Server
Metrics Server是一個(gè)集群范圍的資源使用情況的數(shù)據(jù)聚合器。作為一個(gè)應(yīng)用部署在集群中。
Metric server從每個(gè)節(jié)點(diǎn)上Kubelet公開(kāi)的摘要API收集指標(biāo)。
Metrics server通過(guò)Kubernetes聚合器注冊(cè)在Master APIServer中。
它必須能拿到cpu的利用率，有這個(gè)才能做對(duì)比，要不要擴(kuò)容，所以要部署一個(gè)metrics server到集群中，讓它為hpa提供CPU的數(shù)據(jù)查詢，metrics server相當(dāng)于一個(gè)聚合器，它那的數(shù)據(jù)就是cadvisor 的數(shù)據(jù)，它將那些數(shù)據(jù)每個(gè)節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行聚合，這是它說(shuō)做的事，因?yàn)槟阋獢U(kuò)容，并不是一個(gè)副本去擴(kuò)容，并不是參考一個(gè)副本的指標(biāo)，要參考你當(dāng)前跑的pod的都要考慮，而每個(gè)上面都有cadvisor,那訪問(wèn)當(dāng)前的pod，就只訪問(wèn)到當(dāng)前的利用率，而cadvisor也沒(méi)有什么聚合的作用，要想對(duì)所有的pod的資源利用率做一個(gè)匯總，那么上面就有這個(gè)metrics server了，之前是有heapstar去做的，現(xiàn)在是由metrics server去做的，幫你去匯總，然后hpa從這個(gè)匯總信息里去拿整體cpu的利用率來(lái)判斷這個(gè)域，所以metrics server就是一個(gè)聚合器，
而且還會(huì)從每個(gè)節(jié)點(diǎn)上kubelet收集這些指標(biāo)，并通過(guò)k8s聚合器注冊(cè)在k8s中的apiserver中，所以metrics必須啟動(dòng)聚合器，所以metrics就能主動(dòng)的將自己注冊(cè)進(jìn)去，注冊(cè)進(jìn)去之后就可以metrics暴露的一個(gè)名稱來(lái)請(qǐng)求metrics，會(huì)根據(jù)你攜帶的名稱幫你轉(zhuǎn)發(fā)到后面的metrics的pod
git clone https://github.com/kubernetes-incubator/metrics-server
cd metrics-server/deploy/1.8+/
vi metrics-server-deployment.yaml # 添加2條啟動(dòng)參數(shù) ,把改修改的修改一下，默認(rèn)是https請(qǐng)求的，我們是直接https請(qǐng)求的api
image: zhaocheng172/metrics-server-amd64:v0.3.1
command:
- /metrics-server
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
imagePullPolicy: Always
volumeMounts:
- name: tmp-dir
mountPath: /tmp
nodeSelector:
beta.kubernetes.io/os: linux[root@k8s-master1 1.8+]# kubectl apply -f .
確保pod起來(lái)
[root@k8s-master1 1.8+]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-59fb8d54d6-7rmx2 1/1 Running 0 43m
kube-flannel-ds-amd64-4jjmm 1/1 Running 0 43m
kube-flannel-ds-amd64-9f9vq 1/1 Running 0 43m
kube-flannel-ds-amd64-gcf9s 1/1 Running 0 43m
metrics-server-64499fd8c6-xkc6c 1/1 Running 0 61s部署起來(lái)先看看metrics-server有沒(méi)有正常工作，先看一下pod有沒(méi)有錯(cuò)誤日志，再看看有沒(méi)有注冊(cè)到聚合層
通過(guò)kubectl get apiservers,查看有沒(méi)有注冊(cè)到,這里為true才算正常
[root@k8s-master1 1.8+]# kubectl get apiservices
v1beta1.metrics.k8s.io kube-system/metrics-server True 19s然后查看kubectl top node來(lái)查看node資源的利用率
[root@k8s-master1 1.8+]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master1 517m 25% 1021Mi 62%
k8s-node1 994m 49% 551Mi 33%
k8s-node2 428m 10% 2466Mi 32%也可以通過(guò)kubectl top pod來(lái)查看pod的資源利用率
[root@k8s-master1 1.8+]# kubectl top pod -n kube-system
NAME CPU(cores) MEMORY(bytes)
coredns-59fb8d54d6-7rmx2 13m 14Mi
kube-flannel-ds-amd64-4jjmm 15m 23Mi
kube-flannel-ds-amd64-9f9vq 7m 15Mi
kube-flannel-ds-amd64-gcf9s 9m 15Mi
metrics-server-64499fd8c6-xkc6c 3m 14Mi /也可以通過(guò)metrics api 的標(biāo)識(shí)來(lái)獲得資源使用率的指標(biāo)，比如容器的cpu和內(nèi)存使用率，這些度量標(biāo)準(zhǔn)既可以由用戶直接訪問(wèn)，通過(guò)kubectl top命令，也可以由集群中的控制器pod autoscaler用于進(jìn)行查看，hpa獲取這個(gè)資源利用率的時(shí)候它是通過(guò)接口的，它請(qǐng)求的接口就是api,所以也可以根據(jù)api去獲取這些數(shù)據(jù)，
測(cè)試：可以獲取這些數(shù)據(jù)，這些數(shù)據(jù)和top看到的都是一樣的，只不過(guò)這個(gè)是通過(guò)api 去顯示的,只不過(guò)是通過(guò)json去顯示的
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
[root@k8s-master1 1.8+]# kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
{"kind":"NodeMetricsList","apiVersion":"metrics.k8s.io/v1beta1","metadata":{"selfLink":"/apis/metrics.k8s.io/v1beta1/nodes"},"items":[{"metadata":{"name":"k8s-master1","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k8s-master1","creationTimestamp":"2019-12-12T03:45:06Z"},"timestamp":"2019-12-12T03:45:03Z","window":"30s","usage":{"cpu":"443295529n","memory":"1044064Ki"}},{"metadata":{"name":"k8s-node1","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k8s-node1","creationTimestamp":"2019-12-12T03:45:06Z"},"timestamp":"2019-12-12T03:45:00Z","window":"30s","usage":{"cpu":"285582752n","memory":"565676Ki"}},{"metadata":{"name":"k8s-node2","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k8s-node2","creationTimestamp":"2019-12-12T03:45:06Z"},"timestamp":"2019-12-12T03:45:01Z","window":"30s","usage":{"cpu":"425912654n","memory":"2524648Ki"}}]}將命令行輸出的格式轉(zhuǎn)換成json格式----jq命令[root@k8s-master1 1.8+]# kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes |jq
3、 autoscaing/v1 ( cpu指標(biāo)實(shí)踐 )
autoscaling/v1版本只支持CPU一個(gè)指標(biāo)。
首先部署一個(gè)應(yīng)用并指出一個(gè)service，我們一會(huì)測(cè)試一下進(jìn)行流量壓測(cè)，cpu達(dá)到60%的預(yù)值然后就進(jìn)行自動(dòng)擴(kuò)容副本，如果流量下來(lái)，然后就進(jìn)行自動(dòng)的縮容
[root@k8s-master1 hpa]# cat app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: nginx
name: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
cpu: 90m
memory: 90Mi
---
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80創(chuàng)建HPA策略
用命令生成kubectl autoscale –help
這里可以查看到使用的命令用-o yaml輸出出來(lái)—dry-run過(guò)濾空的字段
kubectl autoscale deployment foo --min=2 --max=10
kubectl autoscale deployment nginx --min=2 --max=10 -o yaml --dry-run > hpa-v1.yaml
[root@k8s-master1 hpa]# cat hpa-v1.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
maxReplicas: 6
minReplicas: 3
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
targetCPUUtilizationPercentage: 60
scaleTargetRef：表示當(dāng)前要伸縮對(duì)象是誰(shuí)
targetCPUUtilizationPercentage：當(dāng)整體的資源利用率超過(guò)60%的時(shí)候，會(huì)進(jìn)行擴(kuò)容。
Maxreplicas：是大擴(kuò)容到的副本量
Minreplicas：是最小縮容到的副本量查看擴(kuò)容狀態(tài)
[root@k8s-master1 hpa]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/60% 3 6 3 52m開(kāi)啟壓測(cè)，進(jìn)行對(duì)我們的cluster IP進(jìn)行測(cè)試
[root@k8s-master1 hpa]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 443/TCP 5h30m
nginx ClusterIP 10.0.0.211 80/TCP 48m 安裝壓測(cè)命令
yum install httpd-tools -y
[root@k8s-master1 hpa]# ab -n 1000000 -c 10000 http://10.0.0.211/index.html測(cè)試cpu已經(jīng)成功超出預(yù)值
[root@k8s-master1 hpa]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 148%/60% 3 6 6 56m大的副本量是6個(gè)，現(xiàn)在已經(jīng)成功自動(dòng)擴(kuò)容
[root@k8s-master1 hpa]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-969bfd4c9-g4zkc 1/1 Running 0 34m
nginx-969bfd4c9-hlcmc 1/1 Running 0 51s
nginx-969bfd4c9-mn2rd 1/1 Running 0 52m
nginx-969bfd4c9-rk752 1/1 Running 0 34m
nginx-969bfd4c9-zmmd8 1/1 Running 0 51s
nginx-969bfd4c9-zz5gp 1/1 Running 0 51s關(guān)閉壓測(cè)，過(guò)一會(huì)大概5分鐘之后就會(huì)自動(dòng)的縮容。
[root@k8s-master1 hpa]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-969bfd4c9-g4zkc 1/1 Running 0 39m
nginx-969bfd4c9-mn2rd 1/1 Running 0 57m
nginx-969bfd4c9-rk752 1/1 Running 0 39m
工作流程：hpa -> apiserver -> kube aggregation -> metrics-server -> kubelet(cadvisor)4、autoscaling/v2beta2（多指標(biāo)）
為滿足更多的需求， HPA 還有 autoscaling/v2beta1和 autoscaling/v2beta2兩個(gè)版本。
這兩個(gè)版本的區(qū)別是 autoscaling/v1beta1支持了 Resource Metrics（CPU）和 Custom Metrics（應(yīng)用程序指標(biāo)），而在 autoscaling/v2beta2的版本中額外增加了 External Metrics的支持。
為了滿足更多的需求，hpa還有v2beat1和v2beat2兩個(gè)版本，這個(gè)跨度也比較大，這個(gè)可以實(shí)現(xiàn)自定義指標(biāo)
[root@k8s-master1 hpa]# kubectl get hpa.v2beta2.autoscaling -o yaml > hpa-v2.yaml
apiVersion: v1
items:
- apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
namespace: default
spec:
maxReplicas: 6
minReplicas: 3
metrics:
- resource:
name: cpu
target:
averageUtilization: 60
type: Utilization
type: Resource
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx與上面v1版本效果一樣，只不過(guò)這里格式有所變化。
v2還支持其他另種類型的度量指標(biāo)，：Pods和Object。
type: Pods
pods:
metric:
name: packets-per-second
target:
type: AverageValue
averageValue: 1ktype: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
type: Value
value: 2kmetrics中的type字段有四種類型的值：Object、Pods、Resource、External。
? Resource：指的是當(dāng)前伸縮對(duì)象下的pod的cpu和memory指標(biāo)，只支持Utilization和AverageValue類型的目標(biāo)值。
? Object：指的是指定k8s內(nèi)部對(duì)象的指標(biāo)，數(shù)據(jù)需要第三方adapter提供，只支持Value和AverageValue類型的目標(biāo)值。
? Pods：指的是伸縮對(duì)象Pods的指標(biāo)，數(shù)據(jù)需要第三方的adapter提供，只允許AverageValue類型的目標(biāo)值。另外就是pod暴露的指標(biāo)，比如http的請(qǐng)求數(shù)，吞吐量，也就是http它本身暴露的出來(lái)的，但是暴露出來(lái)，它不能拿到這些指標(biāo)，還需要借助一些第三方的監(jiān)控，也就是使用hpa這里面值的判斷，這個(gè)提前是要通過(guò)kubectl apiservices里面看到注冊(cè)進(jìn)去，到聚合層，所有的hpa都是通過(guò)聚合層去拿到的，它其實(shí)是請(qǐng)求的api到聚合層，然后聚合層幫你代理到后面的組件，比如像metics-service ，它去幫你拿的，然后每個(gè)kubelet幫你收集的（cadvisor每個(gè)pod的資源利用率，它幫你做一個(gè)聚合，聚合之后通過(guò)聚合器暴露出來(lái)，然后來(lái)查詢?cè)O(shè)定的pod的資源利用率，并且做了一個(gè)平均，這樣就能通過(guò)hpa就能拿到之后的目標(biāo)值，然后hpa再幫你判斷，是否達(dá)到這個(gè)預(yù)值，到的話，幫你擴(kuò)容。
基于pod的實(shí)例，pod本身暴露的指標(biāo)，比較吞吐量，qps,如果目標(biāo)是1k也會(huì)觸發(fā)
Hpa ->apiserver->agg->聚合層->prometheus-adapter然后它注冊(cè)到聚合層里面來(lái)，prometheus本身就是一個(gè)監(jiān)控系統(tǒng)，它能采集到所有pod暴露的指標(biāo)，自己存儲(chǔ)起來(lái)，并且展示，adapter主要將自己注冊(cè)到聚合層里面并且它能轉(zhuǎn)換這個(gè)監(jiān)控指標(biāo)apiserver相應(yīng)的數(shù)據(jù)接口和prometheus的接口是不一樣的，adapter在這里存在的關(guān)鍵是數(shù)據(jù)格式的轉(zhuǎn)化，對(duì)接的不單純的是prometheus或者其他的監(jiān)控系統(tǒng)，要想實(shí)現(xiàn)自定義指標(biāo)完成數(shù)據(jù)的轉(zhuǎn)化和注冊(cè)，然后prometheus將每個(gè)pod展示出來(lái)
? External：指的是k8s外部的指標(biāo)，數(shù)據(jù)同樣需要第三方的adapter提供，只支持Value和AverageValue類型的目標(biāo)值。
? 工作流程：hpa -> apiserver -> kube aggregation -> prometheus-adapter -> prometheus -> pods
2.6 基于Prometheus自定義指標(biāo)縮放
資源指標(biāo)只包含CPU、內(nèi)存，一般來(lái)說(shuō)也夠了。但如果想根據(jù)自定義指標(biāo):如請(qǐng)求qps/5xx錯(cuò)誤數(shù)來(lái)實(shí)現(xiàn)HPA，就需要使用自定義指標(biāo)了，目前比較成熟的實(shí)現(xiàn)是 Prometheus Custom Metrics。自定義指標(biāo)由Prometheus來(lái)提供，再利用k8s-prometheus-adpater聚合到apiserver，實(shí)現(xiàn)和核心指標(biāo)（metric-server)同樣的效果。
資源一般就包含cpu、內(nèi)存就夠了，像公有云也是一樣都是基于cpu、內(nèi)存保守型的維度來(lái)實(shí)現(xiàn)的，但是我們可能會(huì)有一些特殊額需求，比如web的服務(wù)請(qǐng)求的QPS,或者這組web提供的這組數(shù)據(jù)，這也是很常見(jiàn)的需求，不過(guò)這類需求，并不是很多，它實(shí)現(xiàn)沒(méi)那么簡(jiǎn)單，目前很成熟的方案就是用prometheus來(lái)自定義這些指標(biāo)
它大概的流程是這樣的，api adapter注冊(cè)到apiserver中的通過(guò)apiservice就可以看到，然后到prometheus，然后從pod中獲取到這些指標(biāo)
1、部署Prometheus
Prometheus（普羅米修斯）是一個(gè)最初在SoundCloud上構(gòu)建的監(jiān)控系統(tǒng)。自2012年成為社區(qū)開(kāi)源項(xiàng)目，擁有非常活躍的開(kāi)發(fā)人員和用戶社區(qū)。為強(qiáng)調(diào)開(kāi)源及獨(dú)立維護(hù)，Prometheus于2016年加入云原生云計(jì)算基金會(huì)（CNCF），成為繼Kubernetes之后的第二個(gè)托管項(xiàng)目。
Prometheus 特點(diǎn)：
? 多維數(shù)據(jù)模型：由度量名稱和鍵值對(duì)標(biāo)識(shí)的時(shí)間序列數(shù)據(jù)
? PromSQL：一種靈活的查詢語(yǔ)言，可以利用多維數(shù)據(jù)完成復(fù)雜的查詢
? 不依賴分布式存儲(chǔ)，單個(gè)服務(wù)器節(jié)點(diǎn)可直接工作
? 基于HTTP的pull方式采集時(shí)間序列數(shù)據(jù)
? 推送時(shí)間序列數(shù)據(jù)通過(guò)PushGateway組件支持
? 通過(guò)服務(wù)發(fā)現(xiàn)或靜態(tài)配置發(fā)現(xiàn)目標(biāo)
? 多種圖形模式及儀表盤支持（grafana）
Prometheus組成及架構(gòu)
? Prometheus Server：收集指標(biāo)和存儲(chǔ)時(shí)間序列數(shù)據(jù)，并提供查詢接口
? ClientLibrary：客戶端庫(kù)
? Push Gateway：短期存儲(chǔ)指標(biāo)數(shù)據(jù)。主要用于臨時(shí)性的任務(wù)
? Exporters：采集已有的第三方服務(wù)監(jiān)控指標(biāo)并暴露metrics
? Alertmanager：告警
? Web UI：簡(jiǎn)單的Web控制臺(tái)
部署：
這里沒(méi)有詳細(xì)說(shuō)prometheus的部署，要是需要就看我前面一篇發(fā)表的文章
這里只需要部署一個(gè)服務(wù)端就可以，可以拿到pod的數(shù)據(jù)就可以，這里還有個(gè)pv的自動(dòng)供給，所以這里我提前部署好了，之前的文章我都寫(xiě)過(guò)，這里不做過(guò)多演示，
[root@k8s-master1 prometheus]# kubectl get pod,svc -n kube-system
NAME READY STATUS RESTARTS AGE
pod/coredns-59fb8d54d6-7rmx2 1/1 Running 0 25h
pod/grafana-0 1/1 Running 0 18m
pod/kube-flannel-ds-amd64-4jjmm 1/1 Running 0 25h
pod/kube-flannel-ds-amd64-9f9vq 1/1 Running 0 25h
pod/kube-flannel-ds-amd64-gcf9s 1/1 Running 0 25h
pod/metrics-server-64499fd8c6-xkc6c 1/1 Running 0 24h
pod/prometheus-0 2/2 Running 0 23m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/grafana NodePort 10.0.0.233 80:30007/TCP 18m
service/kube-dns ClusterIP 10.0.0.2 53/UDP,53/TCP 25h
service/metrics-server ClusterIP 10.0.0.67 443/TCP 24h
service/prometheus NodePort 10.0.0.115 9090:30090/TCP 23m 訪問(wèn)我的prometheus的30090，這里我沒(méi)有部署node節(jié)點(diǎn)上的node_experiod的組件所以沒(méi)有采集到，這個(gè)因?yàn)橛貌坏剑仪懊娴奈恼虏渴鹩性敿?xì)說(shuō)明，這里不做這個(gè)
3、基于QPS指標(biāo)實(shí)踐
部署一個(gè)應(yīng)用：
[root@k8s-master1 hpa]# cat hpa-qps.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: metrics-app
name: metrics-app
spec:
replicas: 3
selector:
matchLabels:
app: metrics-app
template:
metadata:
labels:
app: metrics-app
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "80"
prometheus.io/path: "/metrics"
spec:
containers:
- image: zhaocheng172/metrics-app
name: metrics-app
ports:
- name: web
containerPort: 80
resources:
requests:
cpu: 200m
memory: 256Mi
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 3
periodSeconds: 5
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 3
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: metrics-app
labels:
app: metrics-app
spec:
ports:
- name: web
port: 80
targetPort: 80
selector:
app: metrics-app該metrics-app暴露了一個(gè)Prometheus指標(biāo)接口，可以通過(guò)訪問(wèn)service看到：
[root@k8s-master1 hpa]# curl 10.0.0.107/metrics
HELP http_requests_total The amount of requests in total
TYPE http_requests_total counterhttp_requests_total 31。這一塊是我這個(gè)pod總共請(qǐng)求了多少的訪問(wèn)，累計(jì)值
HELP http_requests_per_second The amount of requests per second the latest ten seconds
TYPE http_requests_per_second gauge
http_requests_per_second 0.5 這個(gè)是10秒之內(nèi)的吞吐率，也就是有0.5個(gè)http請(qǐng)求，吞吐率和qps是不一樣的概念，qps是指一個(gè)范圍內(nèi)求的一個(gè)量，但是他們都是求當(dāng)前量化的一個(gè)指標(biāo)
現(xiàn)在去查看prometheus有沒(méi)有請(qǐng)求到那三個(gè)pod的數(shù)據(jù)
通過(guò)http_requests_total，可以看到我們?cè)趛aml中去定義的name_app: metrics-app
之前的如果也想被prometheus采集到，那么就需要去暴露這個(gè)指標(biāo)，這是其一，其二就是采集這個(gè)指標(biāo)，所有的pod的數(shù)據(jù)是通過(guò)yaml中的注解去實(shí)現(xiàn)的
app: metrics-app
annotations:
prometheus.io/scrape: "true"。讓它能夠采集
prometheus.io/port: "80"。 訪問(wèn)它的地址也就是url
prometheus.io/path: "/metrics"。 默認(rèn)都是metrics
這三個(gè)注解的字段都是prometheus開(kāi)頭的，所以要把這個(gè)指標(biāo)拿走監(jiān)控起來(lái)
Prometheus會(huì)掃描k8s中的pod有沒(méi)有暴露的指標(biāo)，有的話，它會(huì)自動(dòng)加入被監(jiān)控端，然后將暴露出來(lái)，所以這就是prometheus對(duì)k8s的自動(dòng)發(fā)現(xiàn)所能感知所監(jiān)控到
現(xiàn)在采集到了然后就是部署custom metrics adapter
部署 Custom Metrics Adapter
但是prometheus采集到的metrics并不能直接給k8s用，因?yàn)閮烧邤?shù)據(jù)格式不兼容，還需要另外一個(gè)組件(k8s-prometheus-adpater)，將prometheus的metrics 數(shù)據(jù)格式轉(zhuǎn)換成k8s API接口能識(shí)別的格式，轉(zhuǎn)換以后，因?yàn)槭亲远xAPI，所以還需要用Kubernetes aggregator在主APIServer中注冊(cè)，以便直接通過(guò)/apis/來(lái)訪問(wèn)。
這個(gè)主要作用就是將自己注冊(cè)到api-server中，第二就是轉(zhuǎn)換成api可以識(shí)別的數(shù)據(jù)，https://github.com/DirectXMan12/k8s-prometheus-adapter
該 PrometheusAdapter 有一個(gè)穩(wěn)定的Helm Charts，我們直接使用。
先準(zhǔn)備下helm環(huán)境：
[root@k8s-master1 helm]# wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
[root@k8s-master1 helm]# tar xf helm-v3.0.0-linux-amd64.tar.gz
[root@k8s-master1 helm]# mv linux-amd64/helm /usr/bin現(xiàn)在就可以使用helm 了，安裝好helm，還能配置一個(gè)helm的倉(cāng)庫(kù)
也就是它將adapter存放到這個(gè)倉(cāng)庫(kù)里面了
添加的話建議使用微軟云的adapter的
[root@k8s-master1 helm]# helm repo add stable http://mirror.azure.cn/kubernetes/charts
"stable" has been added to your repositories
[root@k8s-master1 helm]# helm repo ls
NAME URL
stable http://mirror.azure.cn/kubernetes/charts這樣的話，我們就能使用helm install，安裝adapter了
因?yàn)閍dapter這個(gè)chart比如它要連接prometheus的地址，就是默認(rèn)的chart并不能之前使用，還得把它改了，所以要指定它的地址和端口，直接通過(guò)set命令來(lái)替換chart默認(rèn)的變量
部署prometheus-adapter，指定prometheus地址：
[root@k8s-master1 helm]# helm install prometheus-adapter stable/prometheus-adapter --namespace kube-system --set prometheus.url=http://prometheus.kube-system,prometheus.port=9090
NAME: prometheus-adapter
LAST DEPLOYED: Fri Dec 13 15:22:42 2019
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
prometheus-adapter has been deployed.
In a few minutes you should be able to list metrics using the following command(s):
kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
[root@k8s-master1 helm]# helm list -n kube-system
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
prometheus-adapter kube-system 1 2019-12-13 15:22:42.043441232 +0800 CST deployed prometheus-adapter-1.4.0 v0.5.0查看pod已經(jīng)部署成功
[root@k8s-master1 helm]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-59fb8d54d6-7rmx2 1/1 Running 0 28h
grafana-0 1/1 Running 0 3h40m
kube-flannel-ds-amd64-4jjmm 1/1 Running 0 28h
kube-flannel-ds-amd64-9f9vq 1/1 Running 0 28h
kube-flannel-ds-amd64-gcf9s 1/1 Running 0 28h
metrics-server-64499fd8c6-xkc6c 1/1 Running 0 27h
prometheus-0 2/2 Running 0 3h45m
prometheus-adapter-77b7b4dd8b-9rv26 1/1 Running 0 2m36s檢查判斷pod是否工作正常，這里已經(jīng)是注冊(cè)到聚合層了
[root@k8s-master1 helm]# kubectl get apiservice
v1beta1.custom.metrics.k8s.io kube-system/prometheus-adapter True 13m這樣就能通過(guò)一個(gè)原始的url去測(cè)試這個(gè)接口能不能用[root@k8s-master1 helm]# kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" |jq
創(chuàng)建hpa策略
[root@k8s-master1 hpa]# cat hpa-v5.yaml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: metrics-app-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: metrics-app
minReplicas: 1
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: 800m查看創(chuàng)建成功的狀態(tài)，目前是沒(méi)有拿到這個(gè)值的。因?yàn)檫m配器還不知道你要什么指標(biāo)（http_requests_per_second），HPA也就獲取不到Pod提供指標(biāo)。
ConfigMap在default名稱空間中編輯prometheus-adapter ，并seriesQuery在該rules: 部分的頂部添加一個(gè)新的：
[root@k8s-master1 hpa]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
metrics-app-hpa Deployment/QPS /800m 3 6 0 16m
nginx Deployment/nginx 0%/60% 3 6 3 24h 添加新的字段，來(lái)收集我們想實(shí)現(xiàn)的QPS的值[root@k8s-master1 hpa]# kubectl edit cm prometheus-adapter -n kube-system
將這一塊放到rules下，，而且中間這個(gè)其實(shí)是promsql,這個(gè)可以執(zhí)行的，而且和我們的之前輸出的結(jié)果是一樣的，{里面表示字段不為空，更精確一些}，這個(gè)主要是查詢出一系列數(shù)據(jù)，下面一段是管聯(lián)，將ns和pod關(guān)聯(lián)，來(lái)拿數(shù)據(jù)，都是對(duì)應(yīng)的關(guān)系。
和前面的一樣，只不過(guò)前面的是http的訪問(wèn)的累計(jì)值，現(xiàn)在我們要轉(zhuǎn)換成一個(gè)速率，QPS的值是通過(guò)范圍之內(nèi)，1分鐘之內(nèi)采集了多少指標(biāo)進(jìn)行相加，再除以60秒，就是每秒的值， matches: "^(.*)_total"，也舉手匹配前面的值進(jìn)行替換，來(lái)提供 as: "${1}_per_second"的值，也就是QPS的值，用這個(gè)值為http提供接口，
rules:
- seriesQuery: 'http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}'
resources:
overrides:
kubernetes_namespace: {resource: "namespace"}
kubernetes_pod_name: {resource: "pod"}
name:
matches: "^(.*)_total"
as: "${1}_per_second"
metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'
這個(gè)值是求的它的一個(gè)平均值，也就是2分鐘之內(nèi)0.42http請(qǐng)求，每一次執(zhí)行就就近執(zhí)行的平均數(shù)
rate(http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}[2m])
因?yàn)槲覀兪嵌鄠€(gè)pod，所以我們需要相加對(duì)外提供一個(gè)指標(biāo)，然后我們?cè)俳o一個(gè)by，給個(gè)標(biāo)簽，這樣的話進(jìn)行標(biāo)簽去查詢
sum(rate(http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}[2m]))
使用by,定義標(biāo)簽的名稱方便去查詢
sum(rate(http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}[2m])) by (kubernetes_pod_name)
測(cè)試api
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests_per_second"目前已經(jīng)收到我們的值了
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
metrics-app-hpa Deployment/metrics-app 416m/800m 1 10 3 2m13s
nginx Deployment/nginx 0%/60% 3 6 3 25h壓測(cè)
Kubectl get svc
metrics-app ClusterIP 10.0.0.107 80/TCP 3h25m
ab -n 100000 -c 100 http://10.0.0.107/metrics 查看擴(kuò)容狀態(tài)
[root@k8s-master1 hpa]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
metrics-app-hpa Deployment/metrics-app 414m/200m 1 10 10 8m36s
nginx Deployment/nginx 0%/60% 3 6 3 26h
[root@k8s-master1 hpa]# kubectl get pod
NAME READY STATUS RESTARTS AGE
metrics-app-b96659c9c-5jxsg 1/1 Running 0 3m53s
metrics-app-b96659c9c-5lqpb 1/1 Running 0 5m24s
metrics-app-b96659c9c-6qx2p 1/1 Running 0 2m21s
metrics-app-b96659c9c-bqkbk 1/1 Running 0 3m53s
metrics-app-b96659c9c-f5vcf 1/1 Running 0 2m21s
metrics-app-b96659c9c-j24xn 1/1 Running 1 3h22m
metrics-app-b96659c9c-vpl4t 1/1 Running 0 3h22m
metrics-app-b96659c9c-wxp7z 1/1 Running 0 3m52s
metrics-app-b96659c9c-xztqz 1/1 Running 0 3m53s
metrics-app-b96659c9c-zhq5r 1/1 Running 0 5m24s
nfs-client-provisioner-6f54fc894d-dbvmk 1/1 Running 0 5h50m
nginx-969bfd4c9-g4zkc 1/1 Running 0 25h
nginx-969bfd4c9-mn2rd 1/1 Running 0 25h
nginx-969bfd4c9-rk752 1/1 Running 0 25h等待一會(huì)大概5分鐘就會(huì)進(jìn)行副本的縮容
小結(jié)：
- 通過(guò)/metrics收集每個(gè)Pod的http_request_total指標(biāo)；
- prometheus將收集到的信息匯總；
- APIServer定時(shí)從Prometheus查詢，獲取request_per_second的數(shù)據(jù)；
- HPA定期向APIServer查詢以判斷是否符合配置的autoscaler規(guī)則；
- 如果符合autoscaler規(guī)則，則修改Deployment的ReplicaSet副本數(shù)量進(jìn)行伸縮。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
本文標(biāo)題：Kubernetes高級(jí)進(jìn)階之pod的自動(dòng)擴(kuò)容/縮容-創(chuàng)新互聯(lián)
鏈接URL：http://www.ef60e0e.cn/article/cdscjj.html
