
目次
はじめに
私が現在従事しているプロジェクトではアプリケーション実行基盤としてKubernetesを導入しています。
システム運用を行う上で、システム監視は重要な役割を担っています。
この記事では、私がKubernetesにおける監視設計を進めるにあたり、
- 何をすべきか?
- 従来の非Kubernetesシステムとの違いは?
について、調査・検討した内容を紹介します。
Kubernetesとは
Kubernetes ⧉は、コンテナ化されたアプリケーションを自動的にデプロイ・スケール・管理するためのオープンソースプラットフォームです。
マイクロサービスやクラウドネイティブなシステムに高い親和性を持ち、アプリケーションの可用性・拡張性・運用効率を向上させることができます。また、AWSやGoogle Cloud、Microsoft Azureなどの主要クラウドでもサービスが提供されています。
Kubernetesにおける監視とは
システムの監視とはシステムが正常に動作しているかどうかをリアルタイムで確認し、問題や異常を早期に検出するプロセスです。
Kubernetesをアプリケーション実行基盤として採用したシステムにおける監視は、Kubernetesクラスタ全体とアプリケーションの正常性をリアルタイムで確認し、問題や異常を早期に検出するプロセスです。
Kubernetesの運用は、以下の点を考慮する必要があります。
- Kubernetes環境のパフォーマンスやリソース使用状況といったシステム全体の状態を可視化すること
- Kubernetesクラスタ上で動作するコンテナやアプリケーションを含むクラスタ・ノード・PodといったKubernetesリソースの状態も監視すること
- PodやコンテナはKubernetesによって自動で配置・再起動されるため、監視対象が常に変化する
- 監視対象の自動追跡および発生事象(配置、再起動等)を通知する
従来システムにおける監視との違い
従来システム(サーバホスト上で稼働するシステム)とKubernetesシステム(Kubernetesを利用したシステム)との違いを比較します。
監視対象の違い
項目 | 従来システム | Kubernetesシステム |
---|---|---|
監視単位 | サーバー、プロセス、 アプリケーション単位 | クラスタ、ノード、Pod、コンテナ単位 |
アプリケーション配置 | 固定されたホスト上に配置 | クラスタ内で動的に配置 |
監視観点の違い
項目 | 従来システム | Kubernetesシステム |
---|---|---|
インフラ | サーバーのリソース(CPU、メモリ、ディスクなど) | ノードのリソース(CPU、メモリ、ディスクなど)、 クラスタ全体の健全性 |
アプリ | ログ、プロセスの死活、ポート監視など | ログ、Podの状態、レプリカ数、リソース制限、 コンテナの状態など |
構成 | 手動の変更が多く、監視対象は固定 | 自動スケーリングやローリングアップデートにより 監視対象が動的に変化 |
ログ管理 | 各サーバーに分散 | サイドカーやログ集約基盤で集中管理 |
メトリクス収集 | Zabbix、Nagiosなど | Prometheus、OpenTelemetryなどの Kubernetesネイティブなツール |
Kubernetesシステムにおける監視対象が動的にスケジューリングされるという特性は従来システムの静的な監視と大きく異なります。
これに対応するためには動的なリソースを追跡・識別・可視化する仕組みが必要になります。
以下にその方法を紹介します。
1. ラベルによる識別と分類
各PodやDeploymentといったKubernetesリソースに一貫したラベルを付与することで、個々のリソースではなく監視対象を論理的なグループとして扱うことが可能になります。
後ほど紹介する監視ツールでは、ラベルを活用してメトリクスを集約したりフィルタリングしたりする機能を持つものもあります。
2. サービスディスカバリ
Prometheusなどの監視ツールはKubernetes APIと連携して、新規に追加されたPodやノードを自動的に検出します。
これによりPodが再スケジューリングされても監視対象が自動的に更新されます。
3. メトリクスのラベル付け
Prometheusでは、各メトリクスにPod名、Namespace名などが自動的に付与されます。
また、リラベリング設定により任意のラベルを付与することも可能です。
例:
container_cpu_usage_seconds_total{namespace="prod", pod="web-xxx", app="web"}
4. ダッシュボードのテンプレート化
Grafanaでは、ラベルを使って動的に変化するPodやアプリケーションを自動的に表示するダッシュボードを作成できます。
例:$app という変数を使って、任意のアプリケーションのメトリクスを切り替えて表示することができます。
5. ログの集約とトレース(Fluentd、Grafana Loki、OpenTelemetryなど)
Podが再起動・再スケジューリングされても、ログを統合的に収集・検索できるようにすることで、トラブルシューティングが可能になります。 各ログにPod名やラベルを付与することで、トラブル発生元(どの環境のどのアプリか)を迅速に特定できます。
Kubernetesにおける監視対象
Kubernetesを監視する上で主な監視項目をあげます。
リソース監視
目的: 各Kubernetesリソースの使用状況やパフォーマンスを可視化し、ボトルネックや過負荷を検知する
対象 | 監視項目の例 |
---|---|
ノード | CPU使用率、メモリ使用率、ディスクI/O、ネットワーク帯域 |
Pod(コンテナ) | リソース使用量(CPU/メモリ)、リソース制限(マニフェストで定義したRequests/Limits値との乖離)、OOMKill発生 |
PersistentVolume | 容量使用率、I/Oレイテンシ |
ネットワーク | パケットロス、レイテンシ、トラフィック量 |
死活監視
目的: リソースが「生きているか」「正常に動作しているか」を確認し、異常を即時検知する
対象 | 監視項目の例 |
---|---|
Pod | 状態(Running, CrashLoopBackOff, Pendingなど)、再起動回数 |
コンテナ | Liveness Probe / Readiness Probe / Startup Probeの結果 |
Deployment / StatefulSet / ReplicaSet | 期待されるレプリカ数と展開されているPodの数との差異 |
ノード | Ready / NotReady 状態、kubeletの応答有無 |
コントロールプレーン監視
目的: Kubernetesの中枢機能 (APIサーバー、スケジューラーなど)が正常に動作しているかを確認する
対象 | 監視項目の例 |
---|---|
kube-apiserver | レスポンスタイム、エラー率、リクエスト数 |
kube-scheduler | スケジューリング遅延、失敗数 |
kube-controller-manager | リリースの同期状況、エラー数 |
etcd(データストア) | データサイズ、レイテンシ |
Kubernetes監視ツール
以下にKubernetes監視で用いられる代表的なツールを紹介します。 これらを単体あるいは複数を組み合わせて監視を実現します。
メトリクス収集・可視化
- Kubernetes Dashboard ⧉:
Kubernetesに具備されるWebベースのUIで、クラスタ内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供される。 - Prometheus ⧉:
オープンソースの監視システムおよび時系列データベース。
システムやアプリケーションのメトリクスを収集・分析し、異常や負荷の増減を把握する。 - Grafana ⧉:
収集したデータを可視化するためのダッシュボードを提供する。
Prometheusと組み合わせて使用されることが多い。 - Sysdig ⧉:
セキュリティとパフォーマンスの監視を統合したツールで、Kubernetesクラスタの詳細な監視を提供する。 - Datadog ⧉:
クラウドネイティブな監視ツール。Kubernetesやコンテナ化された環境での監視に強みがある。 - Splunk ⧉:
Kubernetes環境のログ、メトリクスを収集し、検索や可視化を行う。
AIドリブンの分析機能も提供し、迅速なトラブルシューティングをサポートする。
ログ集約
- Fluentd ⧉:
ログの収集・変換・転送を行う。多数のプラグイン(入力・出力)を持ち、ElasticsearchやS3、Grafana Lokiなどに転送可能。 - Grafana Loki ⧉:
Grafana製のログ集約・検索システム。Prometheusのようにラベルベースのログ管理が可能。
FluentdやPromtailと連携してログを収集する。
Grafanaと統合されているため、メトリクスとログを同じ画面で確認可能。
アラート通知
- AlertManager ⧉:
Prometheusのアラートを受け取り、通知や抑制、グルーピングを行う。Slack・メールなどへの通知が可能。
トレース
- OpenTelemetry ⧉:
メトリクス、ログ、トレースを統一的に収集・送信するためのオープンな標準フレームワーク。各種言語のSDKを提供し、アプリケーションに組み込んでトレース情報を収集可能。 - Jaeger ⧉:
分散トレーシングの可視化ツール。OpenTelemetryやOpenTracingと連携してリクエストの流れを可視化。
最後に
プロジェクトにKubernetesを導入しているが、そもそもKubernetesは何を監視したらよいのか?という方のご参考になればと思います。