RKSを知る！連載第21回目 :マネージドKubernetesサービス比較調査 –監視編

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

1 はじめに
2 RKSの監視
3 EKSの監視
4 AKSの監視
5 調査結果の比較
6 あとがき

はじめに

「RKSを知る！」の連載第21回目の記事としまして、各マネージドkubernetesサービスの監視について調査・比較し、内容について解説したいと思います。

本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る！概要＆連載リンク集

RKSの監視

RKSでは、Ridgeにて24時間体制のクラスタ死活監視を内部的に行っているが、情報の可視化、ないしモニタリングできる機能は提供していないため、現状ではクラスタが停止し再起動を行ったとしても、ユーザ側で検知することは出来ません。

そのため、例えば夜間にWorkerNodeが異常検知された場合、自動的にNodeの停止→削除→再作成が行われるのですが、デフォルトではユーザ側に通知が何もいかないため、翌日クラスタを確認しても異常を確認することが出来ないことになります。

クラスタの監視、ないしクラスタ上のPod監視を行うにはPrometuth + GrafanaといったOSSベースで構築できる監視系ミドルウェアをPodとして導入したり、Datadogといったエージェント監視が可能な商用監視ツールを導入したり等、クラウド機能外にて監視環境を構築する必要があります。

EKSの監視

EKSの監視は同AWSサービスであるCloudWatchによるクラスタログやクラスタのメトリクスの監視・収集、およびCloudtrailによるクラスタへの改ざん検知を実施することが出来ます。

Cloudwatchは24時間体制でログ・メトリクスの監視、および収集を行っており、ユーザ側で監視設定を行い、監視設定にて検知された際にCloudwatchAlermにて通知を実施することが可能となります。

また、EKSクラスタ上のコンテナのログやメトリクスの監視をCloudWatch Container Insightsにより実施することが出来、Cloudwatch Alermと紐づけることで、コンテナ単位のアラート検知を行うことも可能です。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/ContainerInsights.html

CloudWatch Container Insightsの情報をさらに可視化するために、EKSクラスタ上にPrometuthをデプロイし、CloudWatch Container InsightsとPrometuthを連携することで、Cloudwatchにて取得したログ、およびメトリクス情報を自動的にPrometuthと連携することも可能です。
ただ、GUIのテンプレートは提供していないため、Grafana等でダッシュボードを作成する必要があります。

クラスタの死活監視としてはClusterAutoScalerという機能が存在し、設定した性能の閾値に触れた場合、自動的にNodeを増減することが可能です。

なお単体ではNodeの増減についての通知機能は持ち合わせておらず、RKSと同じく、ユーザ側で検知することは出来ません。

AWSサービスであるAWS SNSと組み合わせることで、ClusterAutoScalerの発動をSNSが検知し、ユーザにて設定した通知手段にて通知が行われるよう設定を行うことが出来ます。

AKSの監視

AKSの監視は同AKSサービスであるAzure Monitorを用いて、クラスタのコントロールプレーンログやメトリクス監視を実施することが出来ます。

AKS上で稼働するPodや各メトリクスをより細かく監視する場合は、EKSのContainer Insightsと同じクラスタ上のコンテナを監視、モニタリングする機能であるAzure Monitor for Containersを使用することで一元管理することが出来ます。

Azure Monitor for ContainersはKubernetes からのログだけでなく、DC/OS、Docker Swarm、Red Hat OpenShift などの他のオーケストレーションエンジンからのログの使用もサポートしているため、AKSの構成が異なるクラスタであっても、一元的にログ、メトリクス監視を実施することが可能となります。

以下はAzure公式ドキュメントにてAzure Monitor for Containersの概要を説明している図となります。

引用元 : https://docs.microsoft.com/ja-jp/dotnet/architecture/cloud-native/monitoring-azure-kubernetes

また、Azure Monitor for ContainersはAzureポータル上での確認以外にも、Prometheus上でも確認できるようサポ－トされており、公式にてAzure Monitor for Containers を Prometheus メトリックエンドポイントと直接統合されるため、別途Prometheusサーバを用意する必要なく、使用することが可能です。

ダッシュボードもテンプレートが用意されているため、即クラスタをPrometheus上にて確認できるようサポートされています。 Azure Monitor for Containersにも閾値を超えた場合のアラート設定が用意されており、ログ検索クエリ等を設定することで、指定した閾値、ないしログメッセージが発生した場合、指定した通知先に自動的通知を行うことが可能です。

調査結果の比較

監視について調査した結果、各マネージドKuberneteサービスを比較したところ、

EKSとはAKSはどちらも同クラウドサービス内でログ監視やメトリクス監視を実施することが出来、アラート設定や通知を一元化することが出来る。
AKSは公式にてPrometuthのGUI表示をサポートしており、導入設定を行うことですぐ使用することが出来るが、EKS、RKSはPrometuthと含めてGrafana等のダッシュボード表示を行うOSSの導入が必要となる。
RKSは現状、RidgeCloud内のクラウドサービスとして監視やモニタリングをサポートしておらず、構築したクラスタ上にPrometuthやZabbixを導入し、監視環境を構築する必要がある。

といったところが分かりました。

あとがき

今回は連載第21回目としまして、各マネージドkubernetesサービスの監視について調査し、比較・解説をしました！
監視についてもEKS、AKSではそこまで大きな差はなかったのですが、RKSはクラウドサービスとして監視・モニタリングをサポートしていないため、従来のオンプレミス環境のように監視環境を自己的に構築する必要があることが分かりました。

次回更新もRKSと他のマネージドKubernetesサービスとの比較から、RKSのユニークな点に迫りたいと思います！

ここまでお読みいただき、ありがとうございました！