共計 4401 個字符，預(yù)計需要花費(fèi) 12 分鐘才能閱讀完成。
怎樣使用自定義指標(biāo)進(jìn)行 K8S 自動彈性伸縮，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
Kubernetes 自動彈性伸縮可以根據(jù)業(yè)務(wù)流量，自動增加或減少服務(wù)。這一功能在實(shí)際的業(yè)務(wù)場景中十分重要。我們將了解 Kubernetes 如何針對應(yīng)用產(chǎn)生的自定義指標(biāo)實(shí)現(xiàn)自動伸縮。
為什么需要自定義指標(biāo)？
應(yīng)用程序的 CPU 或 RAM 的消耗并不一定能夠正確表明是否需要進(jìn)行擴(kuò)展。例如，如果你有一個消息隊列 consumer，它每秒可以處理 500 條消息而不會導(dǎo)致崩潰。一旦該 consumer 的單個實(shí)例每秒處理接近 500 條消息，你可能希望將應(yīng)用程序擴(kuò)展到兩個實(shí)例，以便將負(fù)載分布在兩個實(shí)例上。測量 CPU 或 RAM 對于擴(kuò)展這樣的應(yīng)用程序來說有點(diǎn)矯枉過正了，你需要尋找一個與應(yīng)用程序性質(zhì)更為密切相關(guān)的指標(biāo)。一個實(shí)例在特定時間點(diǎn)處理的消息數(shù)量能更貼切地反映該應(yīng)用的實(shí)際負(fù)載。同樣，可能有一些應(yīng)用的其他指標(biāo)更有意義。這些可以使用 Kubernetes 中的自定義指標(biāo)進(jìn)行定義。
Metrics 流水線
Metrics Server 和 API
最初，這些指標(biāo)會通過 Heapster 暴露給用戶，Heapster 可以從每個 kubelet 中查詢指標(biāo)。Kubelet 則與 localhost 上的 cAdvisor 對話，并檢索出節(jié)點(diǎn)級和 pod 級的指標(biāo)。Metric-server 的引入是為了取代 heapster，并使用 Kubernetes API 來暴露指標(biāo)從而以 Kubernetes API 的方式提供指標(biāo)。Metric server 僅提供核心的指標(biāo)，比如 pod 和節(jié)點(diǎn)的內(nèi)存和 CPU，對于其他指標(biāo)，你需要構(gòu)建完整的指標(biāo)流水線。構(gòu)建流水線和 Kubernetes 自動伸縮的機(jī)制將會保持不變。
Aggregation Layer
能夠通過 Kubernetes API 層暴露指標(biāo)的關(guān)鍵部分之一是 Aggregation Layer。該 aggregation layer 允許在集群中安裝額外的 Kubernetes 格式的 API。這使得 API 像任何 Kubernetes 資源一樣可用，但 API 的實(shí)際服務(wù)可以由外部服務(wù)完成，可能是一個部署到集群本身的 Pod（如果沒有在集群級別完成，你需要啟用 aggregation layer）。那么，這到底是如何發(fā)揮作用的呢？作為用戶，用戶需要提供 API Provider（比如運(yùn)行 API 服務(wù)的 pod），然后使用 APIService 對象注冊相同的 API。
讓我們以核心指標(biāo)流水線為例來說明 metrics server 如何使用 API Aggregation layer 注冊自己。APIService 對象如下：
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: v1beta1.metrics.k8s.io
spec:
service:
name: metrics-server
namespace: kube-system
group: metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100部署使用 APIService 注冊 API 的 metrics server 之后，我們可以看到 Kubernetes API 中提供了指標(biāo) API：
Metrics 流水線：核心部分和完整流水線
我們已經(jīng)了解了基本組件，讓我們把它們放在一起組成核心 metrics 流水線。在核心流水線中，如果你已經(jīng)恰當(dāng)?shù)匕惭b了 metrics server，它也將創(chuàng)建 APIService 將自己注冊到 Kubernetes API server 上。正如我們在上一節(jié)中所了解到的那樣，這些指標(biāo)將在 /apis/metrics.k8s.io 中暴露，并被 HPA 使用。
大部分復(fù)雜的應(yīng)用程序需要更多的指標(biāo)，而不僅僅是內(nèi)存和 CPU，這也是大多數(shù)企業(yè)使用監(jiān)控工具的原因，最常見的監(jiān)控工具有 Prometheus、Datadog 以及 Sysdig 等。而不同的工具所使用的格式也有所區(qū)別。在我們可以使用 Kubernetes API 聚合來暴露 endpoint 之前，我們需要將指標(biāo)轉(zhuǎn)換為合適的格式。此時需要使用小型的 adapter（適配器）——它可能是監(jiān)控工具的一部分，也可能作為一個單獨(dú)的組件，它在監(jiān)控工具和 Kubernetes API 之間架起了一座橋梁。例如，Prometheus 有專門的 Prometheus adapter 或者 Datadog 有 Datadog Cluster Agent — 它們位于監(jiān)控工具和 API 之間，并從一種格式轉(zhuǎn)換到另一個種格式，如下圖所示。這些指標(biāo)在稍微不同的 endpoint 都可以使用。
Demo：Kubernetes 自動伸縮
我們將演示如何使用自定義指標(biāo)自動伸縮應(yīng)用程序，并且借助 Prometheus 和 Prometheus adapter。
設(shè)置 Prometheus
為了讓適配器可以使用指標(biāo)，我們將使用 Prometheus Operator 來安裝 Prometheus。它創(chuàng)建 CRD 來在集群中部署 Prometheus 的組件。CRD 是擴(kuò)展 Kubernetes 資源的一種方式。使用 Operator 可以“以 Kubernetes 的方式”（通過在 YAML 文件中定義對象）輕松配置和維護(hù) Prometheus 實(shí)例。由 Prometheus Operator 創(chuàng)建的 CRD 有：
AlertManager
ServiceMonitor
Prometheus
你可以根據(jù)下方鏈接的指導(dǎo)設(shè)置 Prometheus：
https://github.com/infracloudio/kubernetes-autoscaling#installing-prometheus-operator-and-prometheus
部署 Demo 應(yīng)用程序
為了生成指標(biāo)，我們將部署一個簡單的應(yīng)用程序 mockmetrics，它將在 /metrics 處生成 total_hit_count 值。這是一個用 Go 寫的網(wǎng)絡(luò)服務(wù)器。當(dāng) URL 被訪問時，指標(biāo) total_hit_count 的值會不斷增加。它使用 Prometheus 所要求的展示格式來顯示指標(biāo)。
根據(jù)以下鏈接來為這一應(yīng)用程序創(chuàng)建 deployment 和服務(wù)，它同時也為應(yīng)用程序創(chuàng)建 ServiceMonitor 和 HPA：
https://github.com/infracloudio/kubernetes-autoscaling#deploying-the-mockmetrics-application
ServiceMonitor
ServiceMonitor 為 Prometheus 創(chuàng)建了一個配置。它提到了服務(wù)的標(biāo)簽、路徑、端口以及應(yīng)該在什么時候抓取指標(biāo)的時間間隔。在服務(wù) label 的幫助下，選擇了 pods。Prometheus 會從所有匹配的 Pod 中抓取指標(biāo)。根據(jù)你的 Prometheus 配置，ServiceMonitor 應(yīng)該放在相應(yīng)的命名空間中。在本例中，它和 mockmetrics 在同一個命名空間。
部署和配置 Prometheus Adapter
現(xiàn)在要為 HPA 提供 custom.metrics.k8s.io API endpoint，我們將部署 Prometheus Adapter。Adapter 希望它的配置文件在 Pod 中可用。我們將創(chuàng)建一個 configMap 并將其掛載在 pod 內(nèi)部。我們還將創(chuàng)建 Service 和 APIService 來創(chuàng)建 API。APIService 將 **/api/custom.metrics.k8s.io/v1beta1 endpoint** 添加到標(biāo)準(zhǔn)的 Kubernetes APIs。你可以根據(jù)以下教程來實(shí)現(xiàn)這一目標(biāo)：
https://github.com/infracloudio/kubernetes-autoscaling#deploying-the-custom-metrics-api-server-prometheus-adapter
接下來，我們看一下配置：
seriesQuery 用于查詢 Prometheus 的資源，標(biāo)簽為“default“和”mockmetrics-service“。
resources 部分提到標(biāo)簽如何被映射到 Kubernetes 資源。針對我們的情況，它將“namespace“標(biāo)簽與 Kubernetes 的”namespace“進(jìn)行映射，服務(wù)也是如此。
metricsQuery 又是一個 Prometheus 查詢，它可以將指標(biāo)導(dǎo)入 adapter。我們使用的查詢是獲取 2 分鐘內(nèi)所有匹配 regexmockmetrics-deploy-(.*) 的 pods 的平均 total_hit_count 總和。
Kubernetes 自動伸縮實(shí)踐
一旦你根據(jù)下文中的步驟進(jìn)行，指標(biāo)值會不斷增加。我們現(xiàn)在就來看 HPA：
https://github.com/infracloudio/kubernetes-autoscaling#scaling-the-application
$ kubectl get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
mockmetrics-app-hpa Deployment/mockmetrics-deploy 0/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 56/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 110/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 90/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 126/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 306/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 171/100 1 10 4 11h你可以看到當(dāng)該值達(dá)到目標(biāo)值時，副本數(shù)如何增加。
工作流程
自動伸縮的整體流程如下圖所示：
圖片來源: luxas/kubeadm-workshop
關(guān)于怎樣使用自定義指標(biāo)進(jìn)行 K8S 自動彈性伸縮問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注丸趣 TV 行業(yè)資訊頻道了解更多相關(guān)知識。
