概要
custom metrics による HPAについて調べる過程で Operator や Adapter に関する知見を得ましたので共有します。
CloudNative Days Kansai 2019 MeetupでLTした際のスライドもご参照ください。
以下について記載しています。
- Pod Autoscaler
- VPAとHPA
- CPU使用率によるHPA
- custom metricsによるHPA
- Operatorとは
- Adapterとは
Pod Autoscaler
VPAとHPAがあります。
VPA( Vertical Pod Autoscaler )
resources requestsを増減してくれます。
HPA( Horizontal Pod Autoscaler )
pod数を増減してくれます。
本記事はHPAに関するお話です。
CPU使用率によるHPA
公式ドキュメント( Horizontal Pod Autoscaler Walkthrough ) に手順がありますのでやってみました。
サンプルアプリケーション(php-apache)に負荷をかけると以下スライドのようにpod数が増えたので、確かにCPU使用率を基にしたHPAが動作していることが確認できました。
カスタムメトリクスによるHPA
luxas/kubeadm-workshopにサンプルがあるのでやってみました。
マニフェストファイルはdemos/monitoringにあり、
サンプルアプリ(sample-metrics-app)が公開しているhttp_requestsというメトリクスに基づいてpod数が増減するサンプルとなっているようでした。
サンプルアプリ(sample-metrics-app)にアクセスすると以下スライドのようにpod数が増えたので、確かにhttp_requestsというメトリクスに基づいてHPAが動作していることが確認できました。
無事、カスタムメトリクスに基づいたHPAの動きを確認できました。
めでたし、めでたしといきたいところですが、
マニフェストファイル(demos/monitoring) を読んでみるといくつかの疑問が湧いてきました。
疑問点
Operatorとは🤔
prometheus-operatorを使ったDeploymentが定義されていました。
何なのでしょうか？
謎のリソース🤔
ServiceMonitorやPrometheusという謎のリソースがkindに指定されている箇所がありました。
これらはいつどこで定義されいつから使用可能になったのでしょう？
Adapter🤔
メトリクスサーバと思われるDeploymentにはprometheus-adapterなるimageが指定されていました。
adapterとは何なのでしょうか？
このメトリクスサーバは、アプリが公開しているメトリクスをどのようにして収集しているのでしょうか？(左のHow to?)
また、HPA コントローラーはそのメトリクスをどのように取得しているのでしょうか？(右のHow to?)
調査方法
マニフェストファイル(demos/monitoring) に記載された各定義を整理することにしました。
そのためにマニフェストの各要素をExcelのテキストボックスとして出力するツール(loftkun/yaml2excel)を書きました。
Excelファイルを出力するようにしたのは、参照関係のある要素同士をドラッグして近づけたり、矢印でつないだりして整理できるのが便利なためです。
今のところ、整理作業は手作業が必要ですが、マニフェストの参照関係に基づいて自動化できるとよいなと思っています。
( このような整理のできる良いツールが有りましたら教えていただけると大変助かります。 )
調査結果
以下のような構成になっていました。
Operator
上記スライドの左側を説明します。
-
Prometheus OperatorをデプロイするとServiceMonitorやPrometheusといったカスタムなリソース定義(CRD)を生成していました。 - そのため、
Prometheus Operatorをデプロイした後は、kindにServiceMonitorやPrometheusを指定したオブジェクトをデプロイできるようになっていました。 -
ServiceMonitorには監視対象メトリクスのエンドポイントを設定できます -
Prometheus OperatorはServiceMonitorに設定されたエンドポイントを基にPrometheusのconfig(prometheus.yml)を生成してくれていました。
このことから、Operatorとは自身が取り扱うことのできるCRDと、その取り扱いを実装したコントローラーであり、人間の手作業による運用(Operation)をコードで実装したものだと理解しました。
Adapter
上記スライドの右下側を説明します。
-
Custom metrics serverは、PrometheusとHPA controllerの間に立っています。 -
API ServiceはCustom metrics serverをkube-api serverの拡張領域であるaggregation layerに登録するためのものです。 - これにより
HPA controllerはkube-api server経由でCustom metrics serverを介してPrometheusのメトリクスを取得できるようになっているようでした。
PrometheusとHPA 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を動かすサンプルとしてだけでなく、
OperatorやAdapterについて理解する上でも非常に良いサンプルでした
本記事が参考になりましたら幸いです。