使用自定義指標進行 K8s 自動彈性伸縮

Kubernetes 自動彈性伸縮可以根據業務流量，自動增加或減少服務。這一功能在實際的業務場景中十分重要。在本文中，我們將瞭解 Kubernetes 如何針對應用產生的自定義指標實現自動伸縮。

爲什麼需要自定義指標？

應用程序的 CPU 或 RAM 的消耗並不一定能夠正確表明是否需要進行擴展。例如，如果你有一個消息隊列 consumer，它每秒可以處理 500 條消息而不會導致崩潰。一旦該 consumer 的單個實例每秒處理接近 500 條消息，你可能希望將應用程序擴展到兩個實例，以便將負載分佈在兩個實例上。測量 CPU 或 RAM 對於擴展這樣的應用程序來說有點矯枉過正了，你需要尋找一個與應用程序性質更爲密切相關的指標。一個實例在特定時間點處理的消息數量能更貼切地反映該應用的實際負載。同樣，可能有一些應用的其他指標更有意義。這些可以使用 Kubernetes 中的自定義指標進行定義。

Metrics 流水線

Metrics Server 和 API

最初，這些指標會通過 Heapster 暴露給用戶，Heapster 可以從每個 kubelet 中查詢指標。Kubelet 則與 localhost 上的 cAdvisor 對話，並檢索出節點級和 pod 級的指標。Metric-server 的引入是爲了取代 heapster，並使用 Kubernetes API 來暴露指標從而以 Kubernetes API 的方式提供指標。Metric server 僅提供核心的指標，比如 pod 和節點的內存和 CPU，對於其他指標，你需要構建完整的指標流水線。構建流水線和 Kubernetes 自動伸縮的機制將會保持不變。

Aggregation Layer

能夠通過 Kubernetes API 層暴露指標的關鍵部分之一是 Aggregation Layer。該 aggregation layer 允許在集羣中安裝額外的 Kubernetes 格式的 API。這使得 API 像任何 Kubernetes 資源一樣可用，但 API 的實際服務可以由外部服務完成，可能是一個部署到集羣本身的 Pod（如果沒有在集羣級別完成，你需要啓用 aggregation layer）。那麼，這到底是如何發揮作用的呢？作爲用戶，用戶需要提供 API Provider（比如運行 API 服務的 pod），然後使用 APIService 對象註冊相同的 API。

讓我們以核心指標流水線爲例來說明 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 中提供了指標 API：

Metrics 流水線：核心部分和完整流水線

我們已經瞭解了基本組件，讓我們把它們放在一起組成核心 metrics 流水線。在覈心流水線中，如果你已經恰當地安裝了 metrics server，它也將創建 APIService 將自己註冊到 Kubernetes API server 上。正如我們在上一節中所瞭解到的那樣，這些指標將在 /apis/metrics.k8s.io 中暴露，並被 HPA 使用。

大部分複雜的應用程序需要更多的指標，而不僅僅是內存和 CPU，這也是大多數企業使用監控工具的原因，最常見的監控工具有 Prometheus、Datadog 以及 Sysdig 等。而不同的工具所使用的格式也有所區別。在我們可以使用 Kubernetes API 聚合來暴露 endpoint 之前，我們需要將指標轉換爲合適的格式。此時需要使用小型的 adapter（適配器）——它可能是監控工具的一部分，也可能作爲一個單獨的組件，它在監控工具和 Kubernetes API 之間架起了一座橋樑。例如，Prometheus 有專門的 Prometheus adapter 或者 Datadog 有 Datadog Cluster Agent — 它們位於監控工具和 API 之間，並從一種格式轉換到另一個種格式，如下圖所示。這些指標在稍微不同的 endpoint 都可以使用。

Demo：Kubernetes 自動伸縮

我們將演示如何使用自定義指標自動伸縮應用程序，並且藉助 Prometheus 和 Prometheus adapter。你可以繼續閱讀文章，或者直接訪問 Github repo 開始構建 demo：

https://github.com/infracloudio/kubernetes-autoscaling

設置 Prometheus

爲了讓適配器可以使用指標，我們將使用 Prometheus Operator 來安裝 Prometheus。它創建 CRD 來在集羣中部署 Prometheus 的組件。CRD 是擴展 Kubernetes 資源的一種方式。使用 Operator 可以 “以 Kubernetes 的方式”（通過在 YAML 文件中定義對象）輕鬆配置和維護 Prometheus 實例。由 Prometheus Operator 創建的 CRD 有：

AlertManager
ServiceMonitor
Prometheus

你可以根據下方鏈接的指導設置 Prometheus：

https://github.com/infracloudio/kubernetes-autoscaling#installing-prometheus-operator-and-prometheus

部署 Demo 應用程序

爲了生成指標，我們將部署一個簡單的應用程序 mockmetrics，它將在 / metrics 處生成 total_hit_count 值。這是一個用 Go 寫的網絡服務器。當 URL 被訪問時，指標 total_hit_count 的值會不斷增加。它使用 Prometheus 所要求的展示格式來顯示指標。

根據以下鏈接來爲這一應用程序創建 deployment 和服務，它同時也爲應用程序創建 ServiceMonitor 和 HPA：

https://github.com/infracloudio/kubernetes-autoscaling#deploying-the-mockmetrics-application

ServiceMonitor

ServiceMonitor 爲 Prometheus 創建了一個配置。它提到了服務的標籤、路徑、端口以及應該在什麼時候抓取指標的時間間隔。在服務 label 的幫助下，選擇了 pods。Prometheus 會從所有匹配的 Pod 中抓取指標。根據你的 Prometheus 配置，ServiceMonitor 應該放在相應的命名空間中。在本例中，它和 mockmetrics 在同一個命名空間。

部署和配置 Prometheus Adapter

現在要爲 HPA 提供 custom.metrics.k8s.io API endpoint，我們將部署 Prometheus Adapter。Adapter 希望它的配置文件在 Pod 中可用。我們將創建一個 configMap 並將其掛載在 pod 內部。我們還將創建 Service 和 APIService 來創建 API。APIService 將 /api/custom.metrics.k8s.io/v1beta1 endpoint 添加到標準的 Kubernetes APIs。你可以根據以下教程來實現這一目標：

https://github.com/infracloudio/kubernetes-autoscaling#deploying-the-custom-metrics-api-server-prometheus-adapter

接下來，我們看一下配置：

seriesQuery 用於查詢 Prometheus 的資源，標籤爲 “default“和”mockmetrics-service“。
resources 部分提到標籤如何被映射到 Kubernetes 資源。針對我們的情況，它將 “namespace“標籤與 Kubernetes 的”namespace“進行映射，服務也是如此。
metricsQuery 又是一個 Prometheus 查詢，它可以將指標導入 adapter。我們使用的查詢是獲取 2 分鐘內所有匹配 regexmockmetrics-deploy-(.*) 的 pods 的平均 total_hit_count 總和。

Kubernetes 自動伸縮實踐

一旦你根據下文中的步驟進行，指標值會不斷增加。我們現在就來看 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

你可以看到當該值達到目標值時，副本數如何增加。

工作流程

自動伸縮的整體流程如下圖所示：

圖片來源: luxas/kubeadm-workshop

結論

你可以從下方鏈接中瞭解更多相關項目和參考資料。在過去的幾個版本中，Kubernetes 中的監控流水線已經大有發展，而 Kubernetes 的自動伸縮主要基於該流水線工作。如果你不熟悉這個環境，很容易感到困惑和迷茫。

https://github.com/infracloudio/kubernetes-autoscaling#other-references-and-credits

來源：Rancher

原文鏈接：

https://dzone.com/articles/kubernetes-autoscaling-with-custom-metrics-updated

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/vmA86M6d37RRFsWfi3CB6w

猜你喜歡