Prometheus と KEDA を使用した Kubernetes アプリケーションの自動スケーリング

シムアノスの風船男

スケーラビリティはクラウド アプリケーションの重要な要件です。 Kubernetes を使用すると、適切なデプロイメントのレプリカの数を増やすだけでアプリケーションのスケーリングが簡単になります。 ReplicaSet — ただし、それは手動のプロセスです。

Kubernetes を使用すると、アプリケーションを自動的にスケーリングできます (つまり、デプロイメント内のポッドや ReplicaSet) 水平ポッド オートスケーラー仕様を使用した宣言的な方法で。 自動スケーリングのデフォルトの基準は CPU 使用率メト​​リクス (リソース メトリクス) ですが、カスタム メトリクスと外部提供のメトリクスを統合できます。

チーム Mail.ru の Kubernetes aaS 外部メトリクスを使用して Kubernetes アプリケーションを自動的にスケーリングする方法に関する記事を翻訳しました。 すべてがどのように機能するかを示すために、著者は Prometheus を使用して収集された HTTP アクセス要求メトリックを使用します。

ポッドの水平自動スケーリングの代わりに、オープンソースの Kubernetes オペレーターである Kubernetes Event Driven Autoscaling (KEDA) が使用されます。 水平ポッド オートスケーラーとネイティブに統合され、イベント ドリブンのワークロードにシームレスな自動スケーリング (ゼロへの/ゼロからのスケールを含む) を提供します。 コードは次の場所で入手できます GitHubの.

システムの概要

この図は、すべてがどのように機能するかを簡単に説明したものです。

1. このアプリケーションは、HTTP ヒット カウント メトリックを Prometheus 形式で提供します。
2. Prometheus は、これらのメトリクスを収集するように構成されています。
3. KEDA の Prometheus スケーラーは、HTTP ヒット数に基づいてアプリケーションを自動的にスケーリングするように構成されています。

それではそれぞれの要素について詳しく説明していきます。

KEDAとプロメテウス

Prometheus は、オープンソースのシステム監視および警告ツールキットの一部です クラウドネイティブコンピューティング基盤。 さまざまなソースからメトリクスを収集し、時系列データとして保存します。 データを視覚化するために使用できるもの グラファナ または、Kubernetes API と連携する他の視覚化ツール。

KEDA はスケーラーの概念をサポートしており、KEDA と外部システムの間のブリッジとして機能します。 スケーラーの実装は各ターゲット システムに固有であり、そこからデータを抽出します。 KEDA はそれらを使用して自動スケーリングを制御します。

スケーラーは、Kafka、Redis、Prometheus などの複数のデータ ソースをサポートします。 つまり、KEDA を使用すると、Prometheus メトリクスを基準として Kubernetes デプロイメントを自動的にスケーリングできます。

テストアプリケーション

Golang テスト アプリケーションは HTTP 経由でアクセスを提供し、次の XNUMX つの重要な機能を実行します。

1. Prometheus Go クライアント ライブラリを使用してアプリケーションを計測し、ヒット カウントを含む http_requests メトリクスを提供します。 Prometheus メトリクスが利用可能なエンドポイントは、次の URI にあります。 /metrics.

   var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
          Name: "http_requests",
          Help: "number of http requests",
      })
   

2. リクエストに応じて GET アプリケーションはキーの値をインクリメントします (access_count) Redis で。 これは、HTTP ハンドラーの一部として作業を実行し、Prometheus メトリクスをチェックする簡単な方法です。 メトリック値は値と同じである必要があります access_count Redisで。

   func main() {
          http.Handle("/metrics", promhttp.Handler())
          http.HandleFunc("/test", func(w http.ResponseWriter, r 
   *http.Request) {
              defer httpRequestsCounter.Inc()
              count, err := client.Incr(redisCounterName).Result()
              if err != nil {
                  fmt.Println("Unable to increment redis counter", err)
                  os.Exit(1)
              }
              resp := "Accessed on " + time.Now().String() + "nAccess count " + strconv.Itoa(int(count))
              w.Write([]byte(resp))
          })
          http.ListenAndServe(":8080", nil)
      }
   

アプリケーションは次の方法で Kubernetes にデプロイされます。 Deployment。 サービスも生まれます ClusterIPを使用すると、Prometheus サーバーがアプリケーション メトリクスを取得できるようになります。

ここで アプリケーションのデプロイメントマニフェスト.

プロメテウスサーバー

Prometheus デプロイメント マニフェストは次のもので構成されます。

• ConfigMap — Prometheus 構成を転送します。
• Deployment — Kubernetes クラスターに Prometheus をデプロイする場合。
• ClusterIP — UI Prometheus にアクセスするためのサービス。
• ClusterRole, ClusterRoleBinding и ServiceAccount — Kubernetes でのサービスの自動検出 (自動検出)。

ここで Prometheus を実行するためのマニフェスト.

KEDA プロメテウス スケールド オブジェクト

スケーラーは、KEDA とメトリックを取得する必要がある外部システムの間のブリッジとして機能します。 ScaledObject デプロイメントをイベント ソース (この場合は Prometheus) と同期するためにデプロイする必要があるカスタム リソースです。

ScaledObject デプロイメントのスケーリング情報、イベント ソースのメタデータ (接続シークレット、キュー名など)、ポーリング間隔、回復期間、その他のデータが含まれます。 これにより、展開をスケールするための対応する自動スケーリング リソース (HPA 定義) が生成されます。

オブジェクトのとき ScaledObject が削除されると、対応する HPA 定義がクリアされます。

定義は次のとおりです ScaledObject この例では、スケーラーを使用します Prometheus:

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
 name: prometheus-scaledobject
 namespace: default
 labels:
   deploymentName: go-prom-app
spec:
 scaleTargetRef:
   deploymentName: go-prom-app
 pollingInterval: 15
 cooldownPeriod:  30
 minReplicaCount: 1
 maxReplicaCount: 10
 triggers:
 - type: prometheus
   metadata:
     serverAddress: 
http://prometheus-service.default.svc.cluster.local:9090
     metricName: access_frequency
     threshold: '3'
     query: sum(rate(http_requests[2m]))

以下の点にご注意ください。

1. 彼はこう指摘する Deployment 名前で go-prom-app.
2. トリガータイプ - Prometheus。 Prometheus サーバーのアドレスは、メトリック名、しきい値、および PromQLクエリ、使用されます。 PromQL クエリ - sum(rate(http_requests[2m])).
3. による pollingInterval,KEDA は XNUMX 秒ごとに Prometheus にターゲットを要求します。 () の下に少なくとも XNUMX つ以上minReplicaCount)、ポッドの最大数は超えません maxReplicaCount (この例では - XNUMX)。

設置可能 minReplicaCount ゼロに等しい。 この場合、KEDA はゼロツー XNUMX デプロイメントをアクティブ化してから、さらなる自動スケーリングのために HPA を公開します。 逆の順序、つまり XNUMX から XNUMX までのスケーリングも可能です。 この例では、これは HTTP サービスでありオンデマンド システムではないため、ゼロを選択しませんでした。

自動スケーリングの魔法

しきい値は、展開を拡張するためのトリガーとして使用されます。 この例では、PromQL クエリは sum(rate (http_requests [2m])) 過去 XNUMX 分間に測定された、集計された HTTP リクエスト レート (XNUMX 秒あたりのリクエスト数) を返します。

しきい値が XNUMX であるため、値が減少している間に XNUMX つ下回ることになります。 sum(rate (http_requests [2m])) XNUMXつ未満。 値が増加すると、そのたびにサブが追加されます sum(rate (http_requests [2m])) 12つ増えます。 たとえば、値が 14 ～ XNUMX の場合、ポッドの数は XNUMX です。

では、実際に設定してみましょう！

プリセット

必要なのは、Kubernetes クラスターと構成されたユーティリティだけです kubectl。 この例ではクラスターを使用します minikube, ただし、他のものを選択することもできます。 クラスターをインストールするには、 руководство.

最新バージョンを Mac にインストールします。

curl -Lo minikube 
https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 
&& chmod +x minikube
sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/

セット キューブクルKubernetes クラスターにアクセスします。

最新バージョンを Mac にインストールします。

curl -LO 
"https://storage.googleapis.com/kubernetes-release/release/$(curl -s
https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version

KEDAのインストール

KEDA はいくつかの方法で導入できます。それらの方法は次のとおりです。 ドキュメンテーション。 私はモノリシック YAML を使用しています。

kubectl apply -f
https://raw.githubusercontent.com/kedacore/keda/master/deploy/KedaScaleController.yaml

KEDA とそのコンポーネントは名前空間にインストールされます keda。 確認するコマンド:

kubectl get pods -n keda

KEDA Operator が起動するのを待って、 Running State。 そしてその後も続けます。

Helm を使用した Redis のインストール

Helm がインストールされていない場合は、これを使用してください リーダーシップ。 Mac にインストールするコマンド:

brew install kubernetes-helm
helm init --history-max 200

helm init ローカルコマンドラインインターフェースを初期化し、インストールも行います。 Tiller Kubernetes クラスターに接続します。

kubectl get pods -n kube-system | grep tiller

Tiller ポッドが実行状態になるまで待ちます。

翻訳者のメモ: 作成者は Helm@2 を使用していますが、これには Tiller サーバー コンポーネントがインストールされている必要があります。 Helm@3 は関連性があり、サーバー部分は必要ありません。

Helm をインストールした後、Redis を起動するには XNUMX つのコマンドで十分です。

helm install --name redis-server --set cluster.enabled=false --set 
usePassword=false stable/redis

Redis が正常に起動したことを確認します。

kubectl get pods/redis-server-master-0

Redis が状態になるまで待ちます Running.

アプリケーションの導入

デプロイメントコマンド:

kubectl apply -f go-app.yaml

//output
deployment.apps/go-prom-app created
service/go-prom-app-service created

すべてが開始されたことを確認します。

kubectl get pods -l=app=go-prom-app

Redis が状態になるまで待ちます Running.

Prometheus サーバーの導入

Prometheus マニフェストでは、 Prometheus の Kubernetes サービス ディスカバリ。 これにより、サービス ラベルに基づいてアプリケーション ポッドを動的に検出できます。

kubernetes_sd_configs:
   - role: service
   relabel_configs:
   - source_labels: [__meta_kubernetes_service_label_run]
     regex: go-prom-app-service
     action: keep

導入するには:

kubectl apply -f prometheus.yaml

//output
clusterrole.rbac.authorization.k8s.io/prometheus created
serviceaccount/default configured
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
configmap/prom-conf created
deployment.extensions/prometheus-deployment created
service/prometheus-service created

すべてが開始されたことを確認します。

kubectl get pods -l=app=prometheus-server

プロメテウスが状態になるのを待ちます Running.

使用 kubectl port-forward Prometheus ユーザー インターフェイス (または API サーバー) にアクセスするには、 http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

KEDA 自動スケーリング構成のデプロイ

作成するコマンド ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

KEDA オペレーターのログを確認します。

KEDA_POD_NAME=$(kubectl get pods -n keda 
-o=jsonpath='{.items[0].metadata.name}')
kubectl logs $KEDA_POD_NAME -n keda

結果は次のようになります。

time="2019-10-15T09:38:28Z" level=info msg="Watching ScaledObject:
default/prometheus-scaledobject"
time="2019-10-15T09:38:28Z" level=info msg="Created HPA with 
namespace default and name keda-hpa-go-prom-app"

アプリケーションの下で確認してください。 XNUMX つのインスタンスが実行されている必要があるため、 minReplicaCount 1 に等しい:

kubectl get pods -l=app=go-prom-app

HPA リソースが正常に作成されたことを確認します。

kubectl get hpa

次のようなものが表示されるはずです。

NAME                   REFERENCE                TARGETS     MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-go-prom-app   Deployment/go-prom-app   0/3 (avg)   1         10        1          45s

ヘルスチェック: アプリケーションへのアクセス

アプリケーションの REST エンドポイントにアクセスするには、次を実行します。

kubectl port-forward service/go-prom-app-service 8080

アドレスを使用して Go アプリにアクセスできるようになりました http://localhost:8080。 これを行うには、次のコマンドを実行します。

curl http://localhost:8080/test

結果は次のようになります。

Accessed on 2019-10-21 11:29:10.560385986 +0000 UTC 
m=+406004.817901246
Access count 1

この時点で、Redis も確認します。 キーが access_count 1 に増加:

kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
"1"

メトリック値が次であることを確認してください。 http_requests 同じ：

curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests number of http requests
# TYPE http_requests counter
http_requests 1

負荷の作成

我々は使用するだろう ねえ — 負荷を生成するためのユーティリティ:

curl -o hey https://storage.googleapis.com/hey-release/hey_darwin_amd64 
&& chmod a+x hey

ユーティリティをダウンロードすることもできます Linux または Windows.

それを実行します：

./hey http://localhost:8080/test

デフォルトでは、ユーティリティは 200 個のリクエストを送信します。 これは、Redis だけでなく Prometheus メトリクスを使用して検証できます。

curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests number of http requests
# TYPE http_requests counter
http_requests 201
kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
201

実際のメトリクスの値 (PromQL クエリによって返される) を検証します。

curl -g 
'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'
//output
{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1571734214.228,"1.686057971014493"]}]}}

この場合、実際の結果は次のようになります。 1,686057971014493 フィールドに表示されます value。 設定したしきい値は 3 であるため、これではスケーリングには十分ではありません。

もっと負荷を！

新しいターミナルで、アプリケーション ポッドの数を監視します。

kubectl get pods -l=app=go-prom-app -w

次のコマンドを使用して負荷を増やしてみましょう。

./hey -n 2000 http://localhost:8080/test

しばらくすると、HPA がデプロイメントをスケーリングし、新しいポッドを起動していることがわかります。 HPA をチェックして次のことを確認してください。

kubectl get hpa
NAME                   REFERENCE                TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-go-prom-app   Deployment/go-prom-app   1830m/3 (avg)   1         10        6          4m22s

負荷に一貫性がない場合、デプロイメントは XNUMX つのポッドのみが実行されるまで縮小されます。 実際のメトリック (PromQL クエリによって返される) を確認したい場合は、次のコマンドを使用します。

curl -g 
'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'

クリーニング

//Delete KEDA
kubectl delete namespace keda
//Delete the app, Prometheus server and KEDA scaled object
kubectl delete -f .
//Delete Redis
helm del --purge redis-server

まとめ

KEDA を使用すると、外部メトリックからのデータに基づいて、Kubernetes デプロイメントを (ゼロへ/ゼロから) 自動的にスケーリングできます。 たとえば、Prometheus メトリクス、Redis のキューの長さ、Kafka トピックのコンシューマ レイテンシに基づきます。

KEDA は外部ソースと統合し、そのメトリクスを Metrics Server 経由で horizo​​ntal Pod Autoscaler に提供します。

グッドラック！

他に読むべきこと：

1. 実稼働環境でコンテナーと Kubernetes を実行するためのベスト プラクティスとベスト プラクティス.
2. Kubernetes 用の 90 以上の便利なツール: デプロイメント、管理、モニタリング、セキュリティなど.
3. Telegram の Kubernetes に関する私たちのチャンネル.

出所： habr.com