この記事について
Kubernetesの監視といえばPrometheus(+Grafana)が有名ですが、弊社の監視ソリューションであるCloud Insights(以下、CIと表記)にもk8sの監視機能が組み込まれています。
この記事ではCIのk8s監視にフォーカスして実際の使用感などをチェックしてみたいと思います。
まとめ
以降の内容を通して確認した結果をはじめにまとめておきます
Cloud Insightsのk8s監視でできること
- 組み込みのダッシュボード(Kubernetes Explorer)でクラスタの状況が俯瞰できる
- 各種k8sリソースのメトリクス/ログを監視できる
- 代表的なミドルウェアのメトリクスが監視できる(Nginx, Apache, MongoDB, PostgresSQL等)
- 機械学習エンジンを活用したCloud Insights独自のメトリクスが監視できる
- アラート出力の条件を指定してメールまたはwebhookによる通知ができる
Cloud Insightsについて
ひとことで言えばNetAppが提供するSaaS型の統合監視ソリューションです。
NetAppといえばストレージが主力製品になりますが、Cloud Insightsはストレージに限らずインフラ〜アプリといったフルスタックの監視ができるというところが特徴です。
Cloud InsightsのKubernetes監視機能を使ってみる
ここではCIのサインアップは済んでいる前提で進めていきます。
NetApp Kubernetes Monitoring Operator(NKMO)のデプロイ
CIでは様々なプロダクトの監視を行うために監視対象のハードウェアやクラウドリソースに特化したData Collectorというオブジェクトをお使いの環境にデプロイする必要があります。
ONTAPの監視をするのであればONTAP用のData Collectorを、AWS EC2の監視をするであればEC2用のData Collectorを、という感じです。
k8s監視の場合はk8sのオペレータパターンに則った形式でData Collectorが提供されています。
その名もNetApp Kubernetes Monitoring Operator(通称、NKMO)
ということでまず初めに監視対象のk8sクラスタ上にNKMOをデプロイします。
CIにログインしてAdmin -> Data Collectors -> + Data Collectorと進むとData Collectorのカタログが表示されますので、この中にあるKubernetesのロゴを探してクリック。
NKMOのインストール手順が表示されます。英語の説明文に従って以下を行います。
- クラスタ名、NKMOをデプロイするnamespaceを入力
- インストーラスニペットをコピー
- kubectl, curlが使える端末上でインストーラスニペットをペーストして実行
- 完了
# 2でコピーしたスニペットをペーストして実行
$ clustername="cluster1" && namespace=netapp-monitoring && token=xxxxxxx && key=xxxxxxxx && domain=ps1325.c01.cloudinsights.netapp.com && curl -X GET -H "Authorization: Bearer $token" -H "X-CloudInsights-Namespace: $namespace" -H "X-CloudInsights-ClusterName: $clustername" -H "X-CloudInsights-ApiKey-Id: $key" https://$domain/rest/v1/lake/telegraf/platforms/operator?name=operator.yaml | kubectl apply -f - && echo "Getting operator based installer config..." && curl -X GET -H "Authorization: Bearer $token" -H "X-CloudInsights-Namespace: $namespace" -H "X-CloudInsights-ClusterName: $clustername" -H "X-CloudInsights-ApiKey-Id: $key" https://$domain/rest/v1/lake/telegraf/platforms/operator?name=operator-cr.yaml | kubectl apply -f -
この長〜〜〜いコマンドラインではNKMOを監視対象のk8s上にデプロイしつつ、CIのAPIにアクセスし対象のk8sクラスタを登録するということを行なっています。
デプロイが完了すると以下の様にoperator本体とその他2種類のpodが展開されます。
# デプロイされたリソースを確認
$ kubectl get pod -n netapp-monitoring
NAME READY STATUS RESTARTS AGE
kube-state-metrics-5cd9cf96c6-whtl4 1/1 Running 0 5d20h
monitoring-operator-68cf4c54db-6n7d9 2/2 Running 0 5d20h
telegraf-ds-n5pwz 1/1 Running 0 5d20h
telegraf-ds-p2h2v 1/1 Running 0 5d20h
telegraf-rs-dmxcq 1/1 Running 0 5d20h
kube-state-metricsはkubernetesの各種リソースに関するメトリクスを生成するアプリケーションで、Prometheusをはじめとする様々な監視ソリューションで使われています。
daemonSetによって各ノードに展開されるtelegrafはクラウド上のCIインスタンスにメトリクスを橋渡しする為のアプリケーションです。
これらのリソースが無事展開されれば各種メトリクス/ログがクラウド上のCIインスタンスに転送され、k8s監視が有効になります。
Kubernetes上のミドルウェア/アプリケーションの監視について
上記手順でKubernetesリソースの監視は有効になりますがNginx,MongoDBなどKubernetes基盤上に導入するアプリケーションの監視を行う場合には別途、各アプリケーションに応じたData Collectorの導入が必要になります。
Kubernetes Explorerの使用
Grafanaなど様々な可視化ソリューションと同様に、CIでもユーザ独自のダッシュボードを作り込むことで必要な情報にすぐにアクセスすることができます。
一方でCIではKubernetes ExplorerというKubernetes監視専用のダッシュボードが組み込みで用意されています。
画面左のメニューからDashborads -> Kubernetes Explorerと進むと以下の様な画面が表示されます。
Kubernetes Explorerで見れるもの（一例）
- クラスタの一覧
- 総Pod数
- Podのスケジュール状況
- 各ノードにスケジュールされているPod数, エラーが発生しているPod, スケジュールできずPendingとなっているPodなど
- CPU使用率/MEM使用率/Disk使用率
- クラスタ全体やnamespace単位など様々な粒度で閲覧可
クエリの作成
Kubernetes Explorerで見れない細かなメトリクスやログはクエリを使用することで閲覧できます。
画面左のメニューからQueries -> + New Metric Queryをクリックします(ログを見たい場合はQueries -> + New Log Query)
下記の図では一例として、"cluster1"という名称のクラスタ内のノードに関するメトリクス(kubernetes.node)を閲覧しています。
また画面右上のSaveボタンからクエリを保存することで次回閲覧時に素早く情報にアクセスすることできます。
CIで利用可能なk8s関連のメトリクスについて
CIではk8s上の各種リソース(pod, deployment, service, etc)のメトリクスを生成するためにkube-state-metricsが組み込まれています。メトリクスの一覧は以下のkube-state-metricsのドキュメントを参照ください。
またkube-state-metrics標準のメトリクス以外にCI独自に提供されているメトリクスもあります。
ここでは代表的な例としてkubernetes.pvオブジェクトのメトリクスの一つとして提供されているtimeToFullを紹介します。
timeToFull.totalは機械学習エンジンにより予測されたPVの容量が枯渇するまでの残り日数を示します。
図の一番上にある"nfsapp"という名称のPVを見るとおおよそ95日後にPVの容量がゼロになる、と予測されています。
またtimeToFull.confidenceIntervalはtimeToFull.totalの予測精度を示します。
"nfsapp"の例ではtimeToFull.totalに表示されている予測(95日後にPVが枯渇)には12日間程度の誤差があるだろう、という事になります。
例えば毎日100GBきっかりの書き込みが発生する様な規則的なアクセスパターンのPVであれば、予測は簡単ですのでtimeToFull.confidenceIntervalは0に近い値になります。
一方で、書き込みや削除が不規則的に行われる様なPVあれば予測は難しく、timeToFull.confidenceIntervalの値はより大きくなります。
アラート通知の設定
もちろん条件を設定して指定した通知先へアラートを飛ばすという事もできます。
画面左のメニューからAlerts -> Manage Monitors -> + Monitorと進みます。
するとアラート通知の条件にメトリクス/ログのいずれを使用するか訊かれます。今回はメトリクスを使ってしきい値を超えた場合にアラート通知される様に設定します。
まず①でアラート通知に使用するメトリクスを指定します。使用可能なメトリクスはクエリの作成の項で選択できるものと同様です。
下記の図では"cluster1"という名称のクラスタを対象に、ノードあたりのCPU使用率をアラート対象としています。
②では①で指定したメトリクスに対してしきい値と超過時間を設定します。
下記の例ではCPU使用率が15分以上60%を超えた場合にWarningレベル, 80%超えた場合にはCriticalレベルのアラートを出力します。
③ではアラート出力時の通知先を指定します。
メールによる通知、Webhook(Teams, Slack, Discordなど)のいずれか、または両方を指定できます。
④, ⑤はオプションなので今回は割愛します。
あとは画面右上のSaveをクリックすればアラート設定が有効になります。
おわりに
ということでCloud InsightsによるKubernetes監視機能について検証しました。
Cloud Insightsに関してより詳しく知りたい方は以下の記事もご覧になってみてください。
-
ITインフラのコストを最適化したいのでITインフラを可視化してみた
https://qiita.com/seijitanabe/items/9969d7b9504122e0e4a7 -
NetApp Cloud Insights – Cloud Secureを使ってみた(導入編)
https://dev.classmethod.jp/articles/introduce-netapp-cloud-insights-cloud-secure/