Kubernetes クラスターの監視

運用プラットフォームは、Kubernetes のノードリソース、コンテナーリソース（cAdvisor）、**クラスターオブジェクトの状態（kube-state-metrics）**を収集し、「リソース監視 → Kubernetes」パネルにノード、Pod、Deployment、コンテナーなどのビューを表示します。

運用プラットフォームのデプロイ先を確認する

Kubernetes のメトリクス収集方式は、運用プラットフォームのデプロイ先によって異なります。

構成	設定方法
運用プラットフォームを HAP/HDP の Kubernetes クラスター内にデプロイ（既存クラスターを使用し、`ops.yaml` と `k8s-cluster/` のどちらを使用する場合も同様）	追加設定は不要です。デプロイ後、そのクラスターのデータが自動収集されます。動作確認に進んでください。
運用プラットフォームを監視対象の HAP/HDP Kubernetes クラスター外にデプロイ（例：運用プラットフォームはスタンドアロン構成で、別の Kubernetes クラスターを監視する場合）	監視対象クラスター内に収集コンポーネントをデプロイします。
複数の Kubernetes クラスターを監視	運用プラットフォームが稼働する HAP/HDP Kubernetes クラスターは自動収集されます。それ以外の各監視対象クラスターに収集コンポーネント一式をデプロイします。複数クラスターの監視を参照してください。

収集処理は常にクラスター内で実行されます

どの方式でも、kubelet/cAdvisor/kube-state-metrics をスクレイプするプロセスは監視対象クラスター内で稼働し、マウントされた ServiceAccount を使用して apiserver にアクセスします。そのため、NodePort の公開は不要で、Bearer Token もクラスター外に出ることはありません。

HAP/HDP Kubernetes クラスター内にデプロイする場合：自動収集

Kubernetes 用のデプロイマニフェストには次の設定が含まれているため、追加操作は不要です。

コンポーネント	設定箇所
`ENV_K8S_MONITOR_MODE: "incluster"`	ConfigMap（`ops.yaml` の先頭部分／`11-configmap.yaml`）
Prometheus の ServiceAccount + ClusterRole	同じ `ops.yaml` の末尾／`20-rbac.yaml`
kube-state-metrics	同じ `ops.yaml` の末尾／`40-stateless.yaml` の `ops-ksm`

運用プラットフォーム内蔵の Prometheus が、自身の稼働する HAP/HDP Kubernetes クラスターから直接収集し、ローカルの TSDB に保存します。remote_write の設定は不要です。設定すると自身にデータを送信することになり、不要な書き込み経路が増えます。

1.5.7 より前のバージョンからアップグレードする場合

1.5.7 より前の単一ファイル形式の ops.yaml には RBAC と kube-state-metrics が含まれていないため、Kubernetes パネルにデータが表示されません。 ops.yaml を再ダウンロードし、既存のデプロイに上書き適用すると、不足する設定を追加できます。既存データには影響しません。追加されるのは ServiceAccount、ClusterRole、kube-state-metrics、および ConfigMap の 3 つのキーです。

Kubernetes パネルを無効にするには、ConfigMap の ENV_K8S_MONITOR_MODE を off に変更し、kube-state-metrics 関連のオブジェクトを削除します。

収集コンポーネント方式：対象クラスター外からの監視・複数クラスターの監視

監視対象クラスター内に、Kubernetes メトリクス専用の Prometheus、RBAC、kube-state-metrics からなる軽量な収集コンポーネント一式をデプロイします。メトリクスは remote_write で運用プラットフォームに送信されるため、運用プラットフォームから対象クラスターにアクセスできる必要はありません。

この方式では、監視対象クラスターから運用プラットフォームへのアウトバウンド接続のみが必要です。インバウンド接続が制限された環境に適しています。

⬇ k8s-addons.tar.gz をダウンロード

展開後、まず 30-prometheus-incluster.yaml の次の 3 つの変数を変更してから適用してください。

- name: ENV_PROMETHEUS_REMOTE_WRITE_URL
  value: "http://運用プラットフォームのアドレス:30881/mdis/prometheus/server/api/v1/write"
- name: ENV_PROMETHEUS_REMOTE_WRITE_TOKEN
  value: "運用プラットフォームの ENV_OPS_TOKEN"
- name: ENV_K8S_CLUSTER_NAME
  value: "prod-k8s"          # パネルでクラスターを区別する識別名。重複しない名前を指定します。

書き込み先アドレスは、次の 3 つの要素を結合して指定します。

http://<運用プラットフォームのゲートウェイアドレス>:<ポート> + <サブパス> + /prometheus/server/api/v1/write

ポート：Kubernetes では ops-gateway の NodePort（デフォルト 30881）、スタンドアロンでは 48881
サブパス：運用プラットフォームの ENV_OPS_SUB_PATH（デフォルト /mdis）
末尾のパス：運用プラットフォームの Prometheus は --web.external-url=/prometheus/server/ で稼働

よくある設定ミス

① 運用プラットフォームの :9090 を指定しないでください。 ops-prometheus は ClusterIP であり、運用プラットフォームが稼働するクラスター内でのみ名前解決できます。他のクラスターからはアクセスできないため、ゲートウェイの公開ポートを使用してください。

② /prometheus/server/ を省略しないでください。 この部分がない場合は 404 が返されます。

③ トークンは必須です。 ゲートウェイの書き込みエンドポイントは Bearer 認証を使用するため、トークンがない場合は 401 が返されます。運用プラットフォームの ENV_OPS_TOKEN（運用プラットフォームへのログインに使用するものと同じ）を指定してください。

これらの設定ミスがある場合、収集側のコンテナーログでは再試行が繰り返されますが、画面上では通常「データなし」と表示されます。設定後は、まず収集コンポーネントの Pod 内で次の確認を行ってください。

# トークンなし：401 が返れば、エンドポイントが存在し、認証が有効です。
curl -s -o /dev/null -w '%{http_code}\n' -X POST \
  http://運用プラットフォームのアドレス:30881/mdis/prometheus/server/api/v1/write

# トークンあり：400 が返れば、エンドポイントは存在しますが、空のリクエストボディが拒否されています。
curl -s -o /dev/null -w '%{http_code}\n' -X POST \
  -H 'Authorization: Bearer 運用プラットフォームのENV_OPS_TOKEN' \
  http://運用プラットフォームのアドレス:30881/mdis/prometheus/server/api/v1/write

404 が返る場合はアドレスの組み立てが誤っています。両方のリクエストで 401 が返る場合は、トークンが正しくありません。

変更後、マニフェストを適用します。

kubectl apply \
  -f k8s-addons/00-namespace.yaml \
  -f k8s-addons/10-kube-state-metrics.yaml \
  -f k8s-addons/30-prometheus-incluster.yaml

データの流れ：

┌─ 監視対象クラスター ──────────────────────────────┐
│  kubelet / cAdvisor ──┐                           │
│  kube-state-metrics ──┼─→ 収集用 Prometheus       │
│  apiserver ───────────┘   （同じクラスターの SA）  │
└────────────────────────────────┬──────────────────┘
                                 │ remote_write（アウトバウンドのみ、Bearer token 付き）
                                 ↓
     運用プラットフォームのゲートウェイ :30881/mdis/prometheus/server/api/v1/write
                                 ↓
                    運用プラットフォームの Prometheus（ローカル TSDB に保存）
                                 ↓
                    Grafana「リソース監視 → Kubernetes」パネル

Kubernetes メトリクスのみを送信します

収集コンポーネントは kube_*/container_*/kubelet_*/machine_*/node_* のみを運用プラットフォームに送信します。自身の Prometheus の稼働メトリクスは送信しないため、その分のストレージを消費しません。

収集コンポーネントのマニフェスト

ファイル	用途	必須
`00-namespace.yaml`	名前空間 `mdis-monitoring`	✅
`10-kube-state-metrics.yaml`	kube-state-metrics + RBAC + Service	✅
`20-node-exporter.yaml`	node_exporter DaemonSet + Service	任意（ノード・コンテナーメトリクスは kubelet+cAdvisor で収集済み）
`30-prometheus-incluster.yaml`	クラスター内の ops-prometheus + RBAC + Service	✅
`40-alloy-logs.yaml`	コンテナーログ収集用 DaemonSet	コンテナーログを収集する場合にデプロイ。サービスログの取り込みを参照

40-alloy-logs.yaml はログの収集を行うもので、メトリクスは収集しません。上記の apply コマンドにも含まれていません。使用する前に ENV_LOKI_PUSH_URL を変更してください。このファイルをデプロイしなくても Kubernetes パネルにメトリクスは表示されますが、「コンテナーコンソール」にはデータが表示されません。

運用プラットフォームが稼働する HAP/HDP Kubernetes クラスターに収集コンポーネントをデプロイしないでください

運用プラットフォームは自身が稼働する HAP/HDP Kubernetes クラスターを自動収集しています。収集コンポーネントを追加すると収集が重複し、同じ TSDB に異なるクラスター名で 2 組のデータが書き込まれます。その結果、パネルのドロップダウンに判別しにくい項目が表示され、ストレージの使用量も増加します。

複数クラスターの監視

各クラスターのメトリクスには origin_prometheus=<クラスター名> ラベルが付与され、運用プラットフォームに送信されます。「リソース監視 → Kubernetes」パネルの上部には**「クラスター」ドロップダウン**が表示され、クラスターを切り替えられます。デフォルトの All では、すべてのデータをまとめて表示します。

ここでは、クラスター A に運用プラットフォームをデプロイし、クラスター B も監視対象にする場合を例に説明します。

手順 1：運用プラットフォームが稼働するクラスター A に名前を付ける

クラスター A はすでに自動収集されているため、識別しやすいクラスター名を設定するだけです。運用プラットフォームの ConfigMap を変更します。

kubectl -n hap-ops edit configmap ops-config

ENV_K8S_CLUSTER_NAME を、デフォルトの default から分かりやすい名前に変更します。

ENV_K8S_CLUSTER_NAME: "main-k8s"

設定を反映するため Prometheus を再起動します。この値は起動時に Prometheus の external_labels に書き込まれます。

kubectl -n hap-ops rollout restart deployment/ops-prometheus

名前を変更すると過去のデータと分かれます

origin_prometheus はメトリクスに付与されるラベルです。変更後のデータには新しい名前が使用されますが、過去のデータには default が残るため、パネルのドロップダウンには両方が表示されます。運用開始時に名前を確定し、後からの変更で過去のデータを識別しにくくならないようにしてください。

手順 2：クラスター B に収集コンポーネントをデプロイする

まず、B から A のゲートウェイポートにアウトバウンド接続できることを確認します。デフォルトは NodePort 30881 です。A から B への接続は不要です。

# クラスター B の任意のノードで実行します。
curl -s -o /dev/null -w '%{http_code}\n' http://クラスターAのアドレス:30881/mdis/web/

k8s-addons.tar.gz をダウンロードし、30-prometheus-incluster.yaml の次の 3 つの変数を変更します。

- name: ENV_PROMETHEUS_REMOTE_WRITE_URL
  value: "http://クラスターAのアドレス:30881/mdis/prometheus/server/api/v1/write"
- name: ENV_PROMETHEUS_REMOTE_WRITE_TOKEN
  value: "クラスターAの運用プラットフォームの ENV_OPS_TOKEN"
- name: ENV_K8S_CLUSTER_NAME
  value: "prod-k8s"

マニフェストを適用します（クラスター B の kubeconfig を使用してください）。

kubectl apply \
  -f k8s-addons/00-namespace.yaml \
  -f k8s-addons/10-kube-state-metrics.yaml \
  -f k8s-addons/30-prometheus-incluster.yaml

手順 3：送信が成功していることを確認する

クラスター B で収集コンポーネントのログを確認します。remote_write 関連の再試行エラーが出ていないことを確認してください。

kubectl -n mdis-monitoring logs deploy/ops-prometheus | grep -iE '\[k8s\]|remote|error' | tail

運用プラットフォームに戻り、「リソース監視 → Kubernetes」パネル上部の「クラスター」ドロップダウンに main-k8s と prod-k8s の両方が表示されることを確認します。運用プラットフォームの Prometheus に直接クエリを実行して、データを送信しているクラスターを確認することもできます。

count by (origin_prometheus) (kube_node_info)

3 つ目以降のクラスターを追加する

手順 2 を繰り返します。各クラスターでは ENV_K8S_CLUSTER_NAME のみを変更し、書き込み先アドレスとトークンには同じ運用プラットフォームの値を指定します。

クラスター	設定方法	`ENV_K8S_CLUSTER_NAME`
A（運用プラットフォームが稼働）	自動収集済み。ConfigMap を変更	`main-k8s`
B	収集コンポーネント一式	`prod-k8s`
C	収集コンポーネント一式	`test-k8s`
…	…	…

クラスター名は分かりやすい名前にし、IP アドレスや重複する名前は避けてください

この名前がパネルのドロップダウンに表示されます。2 つのクラスターに同じ名前を使用すると、メトリクスが混在して区別できなくなります。

運用プラットフォーム側の追加設定は不要ですが、ストレージ容量に注意してください。N 個のクラスターのメトリクスがすべて運用プラットフォームの TSDB に保存されます。クラスター数や規模が大きい場合は、必要に応じて ENV_PROMETHEUS_RETENTION_SIZE を増やすか、ディスクを拡張してください。

動作確認

ServiceAccount と apiserver proxy により、kubelet、cAdvisor、kube-state-metrics、Pod が自動検出されます。 kubelet ポートの公開や kubeconfig は不要です。

運用プラットフォームが稼働する HAP/HDP Kubernetes クラスターを自動収集する場合（ops.yaml の名前空間は hap-ops、k8s-cluster/ も同じ）：

kubectl -n hap-ops get deploy kube-state-metrics
kubectl -n hap-ops exec deploy/ops-prometheus -- \
  curl -s localhost:9090/prometheus/server/api/v1/targets | grep -o '"job":"k8s-[^"]*"'

収集コンポーネント方式の場合（監視対象クラスターの mdis-monitoring にデプロイ）：

kubectl -n mdis-monitoring get pods
kubectl -n mdis-monitoring logs deploy/ops-prometheus | grep '\[k8s\]'

起動ログに [k8s] incluster 采集已启用，集群标识 origin_prometheus="..."（incluster 収集が有効になり、クラスター識別名が設定されたことを示すログ）が表示されることを確認してください。 remote_write を設定すると送信先もログに表示されます。アドレスのプレフィックスが正しくない場合、このログに警告が出力されます。

どちらの方式でも、k8s-kubelet、k8s-cadvisor、k8s-kube-state-metrics の 3 つのジョブがすべて UP になる必要があります。その後、「リソース監視 → Kubernetes」パネルを開くと、ノードと Pod のビューを確認できます。

運用プラットフォームのデプロイ先を確認する​

HAP/HDP Kubernetes クラスター内にデプロイする場合：自動収集​

収集コンポーネント方式：対象クラスター外からの監視・複数クラスターの監視​

収集コンポーネントのマニフェスト​

複数クラスターの監視​

手順 1：運用プラットフォームが稼働するクラスター A に名前を付ける​

手順 2：クラスター B に収集コンポーネントをデプロイする​

手順 3：送信が成功していることを確認する​

3 つ目以降のクラスターを追加する​

動作確認​