Help us understand the problem. What is going on with this article?

custom metrics による HPAに学ぶ Operator と Adapter

More than 1 year has passed since last update.

概要

custom metrics による HPAについて調べる過程で Operator や Adapter に関する知見を得ましたので共有します。
CloudNative Days Kansai 2019 MeetupでLTした際のスライドもご参照ください。

スライド1.png

以下について記載しています。

  • Pod Autoscaler
    • VPAとHPA
  • CPU使用率によるHPA
  • custom metricsによるHPA
    • Operatorとは
    • Adapterとは

Pod Autoscaler

VPAとHPAがあります。

VPA( Vertical Pod Autoscaler )

resources requestsを増減してくれます。

スライド56.png

HPA( Horizontal Pod Autoscaler )

pod数を増減してくれます。

スライド58.png

本記事はHPAに関するお話です。

CPU使用率によるHPA

公式ドキュメント( Horizontal Pod Autoscaler Walkthrough ) に手順がありますのでやってみました。

サンプルアプリケーション(php-apache)に負荷をかけると以下スライドのようにpod数が増えたので、確かにCPU使用率を基にしたHPAが動作していることが確認できました。

スライド12.png

カスタムメトリクスによるHPA

luxas/kubeadm-workshopにサンプルがあるのでやってみました。

マニフェストファイルはdemos/monitoringにあり、
サンプルアプリ(sample-metrics-app)が公開しているhttp_requestsというメトリクスに基づいてpod数が増減するサンプルとなっているようでした。

スライド16.png

サンプルアプリ(sample-metrics-app)にアクセスすると以下スライドのようにpod数が増えたので、確かにhttp_requestsというメトリクスに基づいてHPAが動作していることが確認できました。

スライド19.png

無事、カスタムメトリクスに基づいたHPAの動きを確認できました。
めでたし、めでたしといきたいところですが、
マニフェストファイル(demos/monitoring) を読んでみるといくつかの疑問が湧いてきました。

疑問点

Operatorとは🤔

prometheus-operatorを使ったDeploymentが定義されていました。
何なのでしょうか?
スライド21.png

謎のリソース🤔

ServiceMonitorPrometheusという謎のリソースがkindに指定されている箇所がありました。
これらはいつどこで定義されいつから使用可能になったのでしょう?

スライド22.png
スライド23.png

Adapter🤔

メトリクスサーバと思われるDeploymentにはprometheus-adapterなるimageが指定されていました。
adapterとは何なのでしょうか?

スライド24.png

このメトリクスサーバは、アプリが公開しているメトリクスをどのようにして収集しているのでしょうか?(左のHow to?)
また、HPA コントローラーはそのメトリクスをどのように取得しているのでしょうか?(右のHow to?)

スライド27.png

調査方法

マニフェストファイル(demos/monitoring) に記載された各定義を整理することにしました。
そのためにマニフェストの各要素をExcelのテキストボックスとして出力するツール(loftkun/yaml2excel)を書きました。

Excelファイルを出力するようにしたのは、参照関係のある要素同士をドラッグして近づけたり、矢印でつないだりして整理できるのが便利なためです。
今のところ、整理作業は手作業が必要ですが、マニフェストの参照関係に基づいて自動化できるとよいなと思っています。
( このような整理のできる良いツールが有りましたら教えていただけると大変助かります。 )

スライド28.png

調査結果

以下のような構成になっていました。

スライド43.png

Operator

上記スライドの左側を説明します。

  1. Prometheus OperatorをデプロイするとServiceMonitorPrometheusといったカスタムなリソース定義(CRD)を生成していました。
  2. そのため、Prometheus Operatorをデプロイした後は、kindServiceMonitorPrometheusを指定したオブジェクトをデプロイできるようになっていました。
  3. ServiceMonitorには監視対象メトリクスのエンドポイントを設定できます
  4. Prometheus OperatorServiceMonitorに設定されたエンドポイントを基にPrometheusのconfig(prometheus.yml)を生成してくれていました。

このことから、Operatorとは自身が取り扱うことのできるCRDと、その取り扱いを実装したコントローラーであり、人間の手作業による運用(Operation)をコードで実装したものだと理解しました。

Adapter

上記スライドの右下側を説明します。

  1. Custom metrics serverは、PrometheusHPA controllerの間に立っています。
  2. API ServiceCustom metrics serverkube-api serverの拡張領域であるaggregation layerに登録するためのものです。
  3. これによりHPA controllerkube-api server経由でCustom metrics serverを介してPrometheusのメトリクスを取得できるようになっているようでした。

PrometheusHPA controllerという本来通信が不可能な2者の間にあるのがCustom metrics serverであり、両者をつなげる互換性を提供している位置付けにあると捉えることができそうです。
そんなCustom metrics serverのimageがprometheus-adapterと名付けられていることから、これは互換性を提供するパターンであるAdapterパターンの事例であると理解しました。

まとめ

  • Prometheus Operatorによるメトリクスの収集を題材としてOperatorが何なのかを理解できたはず
  • Adapterパターンの具体的な事例としてprometheus-adapterを用いたCustom metrics serverを知ることができた
  • luxas/kubeadm-workshop は、custom metricsによるHPAを動かすサンプルとしてだけでなく、OperatorAdapterについて理解する上でも非常に良いサンプルでした

本記事が参考になりましたら幸いです。

loftkun
❤piano 🎵spitz 🎮shogi 1st grade 🎸IBM ex Yahoo 🎹Minikube contributer ☁CNDF2020 Committee 💻Lecturer at college lab 🎤http://speakerdeck.com/loftkun 🐗my opinions are my own
https://twitter.com/loftkun
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away