Contents
Kubernetes環境におけるPrometheus導入の意義と基本概念
Kubernetesを運用する際、動的なスケーリングやポッドライフサイクルに合わせた監視体制は不可欠です。Prometheusは、Kubernetesネイティブなアーキテクチャでメトリクスを収集・分析できるツールとして、近年急速に普及しています。本記事では、その導入手順とベストプラクティスをステップバイステップで解説します。
監視アーキテクチャ設計の要点
Kubernetes環境における監視は、ポッドの短寿命化やリソース配分の変動に対応できる柔軟な設計が求められます。ServiceMonitorやPodMonitorといったKubernetes固有のリソースを活用することで、アプリケーションとインフラの両面からの監視が可能になります。
- 動的スケーリング対応: ポッドの増減に即してメトリクス収集範囲を自動調整
- ライフサイクル管理: ポッド起動時/終了時のイベントを正確に捕捉
ネイティブな監視の利点
Prometheusは、Kubernetes APIやカスタムリソース定義（CRD）を活用したネイティブな監視が可能です。これにより、クラスター内のポッドやノードの状態変化に即してメトリクスを収集できます。
| 比較項目 | 伝統的監視ツール | Prometheus/Kubernetesネイティブ |
|---|---|---|
| メトリクス収集対象 | 固定されたホスト/アプリケーション | Kubernetesリソース（ポッド、ノード）と連携 |
| スケーリング対応性 | 手動設定が必要 | 自動的に収集範囲が更新される |
Prometheus Operatorによるインストール手順
Kubernetes環境にPrometheusを導入する際、Prometheus Operatorは効率的な方法です。Operatorを使用することで、カスタムリソース定義（CRD）を通じてPrometheusのデプロイを簡略化できます。
Helmチャートでのデプロイ手順
Helmチャートを使うことで、Prometheus Operatorと関連リソースを一括でインストール可能です。以下が基本的な手順です：
-
HelmリポジトリにOperator追加
bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update -
Prometheus Operatorをインストール
bash
helm install prometheus-operator prometheus-community/kube-prometheus-stack注意:
kube-prometheus-stackはコミュニティメンテナンスのチャートです。公式リソースについてはhttps://github.com/prometheus-operator/kube-prometheusを参照してください。 -
RBAC設定の確認
Prometheus Operatorは、Kubernetesリソースへのアクセス権が必要です。デフォルトではprometheus名前空間が作成され、適切なRoleとClusterRoleが割り当てられます。
ServiceMonitorとCronJobの監視設計
ServiceMonitorとPodMonitorを活用することで、アプリケーションや定期タスクのメトリクス収集を効果的に行えます。特にKubernetesのポッドライフサイクルに合わせた監視設計が重要です。
メトリクス収集対象の選定基準
ServiceMonitorは、アプリケーションのサービス（Pod）に直接バインドされるため、以下の点を意識しましょう：
- ラベルセレクター：
app.kubernetes.io/nameなどの標準的なラベルを使うと管理がしやすい - メトリクスエンドポイント：HTTP経由で
/metricsエンドポイントにアクセスする設定が必要
例として、WebアプリケーションのServiceMonitor定義は以下のようにします：
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: web-app-monitor spec: selector: matchLabels: app.kubernetes.io/name: webapp endpoints: - port: metrics |
定期タスクの監視設計
CronJobを監視する場合は、kubectl describe cronjobで状態を確認し、失敗回数や実行履歴をメトリクスとして取得します。ServiceMonitorはPodベースの監視には不向きです。以下の場合にはPodMonitorが適切です：
- Podのライフサイクルに即した監視が必要な場合
- ポッドのラベルで選択する必要がある場合（例:
job-name=cronjob） - CronJobと直接連携したい場合
コミュニティ推奨リソース: https://github.com/prometheus-operator/kube-prometheus でPodMonitorの使用条件が詳細に説明されています。
Node ExporterとcAdvisorの導入方法
ノードレベルのメトリクス（CPU使用率やディスクIOなど）を収集するには、Node ExporterとcAdvisorをデプロイします。これらは、Kubernetes環境でリソース利用状況を把握するための必須コンポーネントです。
ノードレベルメトリクス収集構成
Node ExporterはDaemonSet形式でクラスター内の全ノードに展開されます。これにより、各ノードのメトリクスがPrometheusに自動的に送信されます。
-
デプロイ手順例（Helm）:
bash
helm install node-exporter prometheus-community/prometheus-node-exporter -
収集対象メトリクス:
- CPU使用率
- メモリ使用量
- ディスクIO状態
コンテナリソース監視の最適化
cAdvisorは、Kubernetesノード上のコンテナごとのリソース利用（CPU・メモリ）を自動的に収集します。Prometheusと連携することで、アプリケーションごとのリソース消費傾向を分析可能です。
- cAdvisorの自動登録:
Kubernetesは/metrics/cadvisor経由でメトリクスを公開しており、ServiceMonitorでこのエンドポイントを指定すれば自動的に収集されます。
Alertmanagerとの連携設定
アラートルールと通知チャネルを構成することで、異常発生時に迅速な対応が可能になります。特にKubernetesノードの状態変化やアプリケーション特有のエラー検知には注意が必要です。
アラートルールの設計ガイドライン
アラートルールはPromQLで定義します。以下の点を意識して設計しましょう：
- Thresholdの設定: CPU使用率が90%以上になった場合にアラートするなど、実際の運用に応じて調整
- Slack/Email通知: チームごとに通知先を分けることで、情報共有がスムーズになる
例として、ノードのCPU使用率が高くなったときのルールは以下のようになります：
|
1 2 3 4 5 6 7 8 9 10 |
groups: - name: node-alerts rules: - alert: HighNodeCPUUsage expr: (100 * avg by (instance) (rate(container_cpu_usage_seconds_total[5m]))) > 90 labels: severity: warning annotations: summary: "{{ $labels.instance }}のCPU使用率が高くなっています" |
メトリクス精度確認:
container_cpu_usage_seconds_totalはKubernetesのcAdvisorから収集されるメトリクスです。最新バージョンではcontainer_cpu_user_seconds_totalまたはcontainer_cpu_system_seconds_totalを指定することもあります。
通知チャネルの多様な構成例
Alertmanagerでは、SlackやEmailなど複数の通知手段を組み合わせることができます。以下はSlack通知設定の一例です：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
global: slack_api_url: https://hooks.slack.com/services/xxxxx route: receiver: 'slack-notifications' receivers: - name: 'slack-notifications' slack_configs: - channel: '#monitoring' send_resolved: true |
Kubernetes Dashboardとの統合方法
Kubernetes DashboardにPrometheusデータを表示させることで、UIでの可視化が可能です。ただし、セキュリティ設定の見直しが必要です。
メトリクス表示のカスタマイズ
Dashboard内にはPrometheusデータソースを登録する機能があります。以下が基本的な手順です：
-
Dashboardにアクセス
bash
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.8.0/aio/deploy/recommended.yaml注意: 上記のURLは最新版（v2.8.0）に変更されています。公式リポジトリhttps://github.com/kubernetes/dashboardで確認してください。
-
Prometheusデータソースを追加
Dashboardの「Settings」→「Data Sources」から、http://prometheus:9090を登録します。 -
ダッシュボードを作成
メトリクス（例：ノードCPU使用率）をグラフ形式で表示できます。
UI操作とAPI利用の連携
DashboardとPrometheusは、Kubernetes API経由で通信するため、認証設定に注意が必要です。以下がセキュリティ考慮点：
- RBAC制限: 一部のユーザーにはPrometheusへのアクセス権を制限
- HTTPS通信:
IngressまたはServiceを介してTLS接続を確立
まとめ
本記事では、Kubernetes環境でPrometheusを導入・設定する手順とベストプラクティスを解説しました。重要なポイントは以下の通りです：
- Operatorによるインストール: HelmチャートやRBAC設定に注意
- ServiceMonitor/CronJobの活用: ポッドライフサイクルに対応した監視設計（PodMonitorの適切な利用）
- Node ExporterとcAdvisor: ノードおよびコンテナリソース監視を確実に
- Alertmanagerとの連携: 実際に運用する際にはThresholdや通知先を調整
- Dashboardとの統合: 可視化のしやすさとセキュリティ設定のバランス
本記事で紹介した設定を基に、自社環境での監視体制構築を試してみてください。実装中に課題があればコメント欄でご質問ください。