Contents
- 1 Helm チャートでのインストール手順（最新版の確認を含む）
- 2 CRD の役割と確認方法
- 3 kube-state-metrics のデプロイと推奨リソース設定
- 4 node-exporter のデプロイと推奨リソース設定
- 5 ServiceMonitor 定義例（labels, namespace, scrape interval）
- 6 複数サービスへの適用パターンとベストプラクティス
- 7 永続化ベストプラクティス（StatefulSet + PVC）
- 8 Alertmanager 設定と基本アラートルール（CPU、Pod 異常）
- 9 公式ダッシュボードインポート手順
- 10 カスタムパネル作成と実践例（Pod 起動時間の可視化）
- 11 まとめ
Helm チャートでのインストール手順（最新版の確認を含む）
公式リポジトリから最新の kube-prometheus-stack を取得し、カスタマイズした values.yaml と共にデプロイします。
1. リポジトリ追加とバージョン確認
|
1 2 3 4 5 6 |
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 利用可能なバージョン一覧を取得（例: v0.78 が最新でない場合に備える） helm search repo prometheus-community/kube-prometheus-stack --versions | head -n 10 |
上記コマンドの出力から、推奨される最新版（例: v57.2.0）をメモしておきます。
2. カスタム values.yaml の作成
|
1 2 3 4 5 6 7 8 9 10 |
# values.yaml（抜粋） namespaceOverride: monitoring # デプロイ先 Namespace prometheus: prometheusSpec: replicas: 2 # 高可用性のために複数レプリカ retention: 30d # データ保持期間 alertmanager: alertmanagerSpec: replicas: 1 |
values.yaml は環境ごとのリソース要件やストレージクラスに合わせて編集してください。
3. Helm インストール実行
|
1 2 3 4 5 6 |
helm install prometheus-operator \ prometheus-community/kube-prometheus-stack \ -n monitoring --create-namespace \ -f values.yaml \ --version <取得した最新版> |
--version オプションで確認済みのバージョンを指定すると、意図しない古いリリースがインストールされるリスクを回避できます。
CRD の役割と確認方法
Operator が管理するリソース（例: Prometheus, ServiceMonitor）はすべて CRD として Kubernetes に登録されています。CRD が未登録だと、カスタムリソース作成時にエラーが発生します。
CRD 名称の注意点
過去のドキュメントでは prometheuses.monitoring.coreos.com などが例示されましたが、実際のリリースでは 名前空間や API グループが変わることがあります。最新版の CRD 名は次のコマンドで確実に取得してください。
|
1 2 |
kubectl get crd -l app.kubernetes.io/instance=prometheus-operator -o custom-columns=NAME:.metadata.name |
1. 登録済み CRD の一覧取得
|
1 2 |
kubectl get crd | grep -E 'prometheus|servicemonitor|alertmanager' |
代表的な CRD が表示されれば、Operator は正常に機能する状態です。
2. 個別 CRD の詳細確認（例: ServiceMonitor）
|
1 2 |
kubectl describe crd servicemonitors.monitoring.coreos.com |
describe 出力で versions, scope, names 等を確認し、期待通りの API が有効か検証します。
Kubernetes 上のメトリクス収集コンポーネントのデプロイ
kube-state-metrics と node-exporter は Prometheus がスクレイピング対象とする代表的なエクスポーターです。本セクションでは、各コンポーネントを別々の Namespace に分離しつつ、リソース上限・要求を明示した Helm デプロイ方法を紹介します。
kube-state-metrics のデプロイと推奨リソース設定
kube-state-metrics はクラスターの状態情報（Pod、Deployment など）をメトリクスとして公開します。以下は公式 Helm チャートでのインストール例です。
|
1 2 3 4 5 6 7 8 9 10 11 |
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install kube-state-metrics \ prometheus-community/kube-state-metrics \ -n kube-system --create-namespace \ --set resources.limits.cpu=200m \ --set resources.limits.memory=256Mi \ --set resources.requests.cpu=100m \ --set resources.requests.memory=128Mi |
| リソース | 推奨値 |
|---|---|
| CPU limit | 200 m |
| CPU request | 100 m |
| Memory limit | 256 Mi |
| Memory request | 128 Mi |
この設定は 中規模クラスター（ノード数 10〜30） を想定したバランスです。リソースが逼迫する場合は limits を段階的に上げてください。
node-exporter のデプロイと推奨リソース設定
node-exporter は各ノードのハードウェア指標（CPU、メモリ、ディスク I/O）を取得します。以下のコマンドで monitoring Namespace に展開します。
|
1 2 3 4 5 6 7 8 |
helm install node-exporter \ prometheus-community/prometheus-node-exporter \ -n monitoring --create-namespace \ --set resources.limits.cpu=150m \ --set resources.limits.memory=200Mi \ --set resources.requests.cpu=50m \ --set resources.requests.memory=100Mi |
| リソース | 推奨値 |
|---|---|
| CPU limit | 150 m |
| CPU request | 50 m |
| Memory limit | 200 Mi |
| Memory request | 100 Mi |
インストール完了後、node-exporter が自動的に ServiceMonitor に登録され、Prometheus が即座にノード指標を取得できるようになります。
ServiceMonitor を活用したアプリケーションメトリクス取得
ServiceMonitor は Prometheus Operator が提供するカスタムリソースで、対象 Service のラベルだけでスクレイピング設定が完結します。本節では基本的な定義例と、複数サービスへ適用するベストプラクティスを解説します。
ServiceMonitor 定義例（labels, namespace, scrape interval）
以下は my-app Namespace にあるラベル app: my-service の Service を 30 秒間隔で取得する設定です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: my-service-monitor labels: release: prometheus-operator # Helm リリース名と合わせると管理しやすい spec: selector: matchLabels: app: my-service # 監視対象 Service のラベル namespaceSelector: matchNames: - my-app # 監視対象 Namespace endpoints: - port: metrics # Service が公開しているポート名 interval: 30s # スクレイプ間隔 path: /metrics |
kubectl apply -f service-monitor.yaml を実行すれば、Prometheus が自動的にメトリクス収集を開始します。
複数サービスへの適用パターンとベストプラクティス
| パターン | 特徴・留意点 |
|---|---|
| 共通ラベルで一括管理 | 全サービスに monitoring: true を付与し、1 つの ServiceMonitor が全体を対象。設定がシンプルになる代わりに、個別チューニングは難しい。 |
| Namespace 別に個別 Monitor | セキュリティや権限境界が厳しい場合に有効。各 Namespace 毎に独立した ServiceMonitor を作成し、RBAC でアクセス制御を分離できる。 |
| scrapeInterval の調整 | 高トラフィック API は 15s、バッチ系は 1m 程度に設定して、Prometheus の負荷とデータ解像度のバランスを取る。 |
Prometheus の永続化と Alertmanager 連携
長期間のメトリクス保存や障害時の通知は、本番環境で欠かせない要素です。本章では StatefulSet と PVC による永続化、そして Alertmanager の基本設定とアラートルール を実践的に示します。
永続化ベストプラクティス（StatefulSet + PVC）
以下は Prometheus 本体を StatefulSet 化し、50 Gi の永続ボリュームを gp2 ストレージクラスで確保する例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
apiVersion: apps/v1 kind: StatefulSet metadata: name: prometheus namespace: monitoring spec: serviceName: prometheus-headless replicas: 2 # 奇数にすると Quorum が取りやすい selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: containers: - name: prometheus image: prom/prometheus:v2.48.0 args: - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/prometheus - --storage.tsdb.retention.time=30d ports: - containerPort: 9090 volumeMounts: - name: data mountPath: /prometheus volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] storageClassName: gp2 # クラウド環境に合わせて変更 resources: requests: storage: 50Gi |
- レプリカ数は奇数（可用性とデータ整合性確保）
- Retention は 30 日 が多くのユースケースでバランスが良い
- ストレージクラスは IOPS とコストを比較し選択
Alertmanager 設定と基本アラートルール（CPU、Pod 異常）
Alertmanager は Helm でインストールし、alertmanager.yml に通知先（Slack, Email 等）を記述します。
|
1 2 3 4 5 |
helm install alertmanager \ prometheus-community/alertmanager \ -n monitoring --create-namespace \ --set config.global.resolve_timeout=5m |
アラートルール例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: node-rules namespace: monitoring spec: groups: - name: node.rules rules: - alert: HighCPUUsage expr: sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.8 for: 2m labels: severity: warning annotations: summary: "CPU 使用率が高い" description: "{{ $labels.instance }} の CPU が 80% を超えています。" - alert: PodCrashLoopBackOff expr: kube_pod_container_status_waiting_reason{reason=\"CrashLoopBackOff\"} > 0 for: 1m labels: severity: critical annotations: summary: "Pod が CrashLoopBackOff" description: "{{ $labels.namespace }}/{{ $labels.pod }} が再起動ループに入っています。" |
kubectl apply -f prometheus-rule.yaml とすれば、Alertmanager が設定された通知先へ即座にアラートを送信します。
Grafana ダッシュボードのセットアップとカスタマイズ
Grafana は可視化の中心ツールです。Helm でデプロイし、公式ダッシュボードをインポートすれば、クラスター全体の監視が瞬時に開始できます。
公式ダッシュボードインポート手順
- Grafana の Helm デプロイ
bash
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install grafana grafana/grafana \
-n monitoring --create-namespace \
--set datasources.datasource.prometheus=true \
--set datasources.datasource.url=http://prometheus-operated.monitoring.svc:9090 \
--set adminPassword=ChangeMe123
2. **Web UI にログイン**（デフォルトは/ 上記パスワード）し、左メニューの **Dashboards → Import** を選択。1860 – “Kubernetes cluster monitoring”）を入力して Load。
3. **公式ダッシュボード ID**（例:
4. データソースに先ほど設定した Prometheus が自動的に割り当てられ、即座に可視化が開始します。
カスタムパネル作成と実践例（Pod 起動時間の可視化）
独自指標をダッシュボードに組み込む手順は次の通りです。
- PromQL クエリ作成
promql
histogram_quantile(0.95, sum(rate(kube_pod_start_time_seconds_bucket[5m])) by (le)) - パネル追加 → “Add Query” に上記クエリを貼り付け、Visualization を “Stat” に変更。単位は “seconds”。
- Threshold 設定（例: 95 パーセンタイルが 30 秒超えると赤表示）で異常検知を視覚化する。
このように YAML/PromQL と Grafana UI を組み合わせるだけで、ビジネス要件に合わせた柔軟なダッシュボードが構築できます。
まとめ
本記事では Prometheus Operator のインストールから CRD 確認、メトリクス収集コンポーネントのデプロイ、ServiceMonitor 活用、永続化と Alertmanager 連携、Grafana 可視化 までをステップ別に解説しました。
- Helm チャートは必ず公式リポジトリで最新バージョンを確認すること。
- CRD 名称はリリースごとに変わり得るため、kubectl get crd で実際の名前を検証してください。
これらのベストプラクティスに従えば、Kubernetes クラスタ全体のメトリクス基盤を安定かつ拡張性高く構築できるでしょう。