Platform & Observability

Cluster Map

リクエストがゲートウェイからルート、サービス、ワークロードを経てノードに至る経路を、1 つのマップで確認します。

課題

/checkout を処理するのはどの Pod? 調べるには kubectl の一覧が 6 つ必要です

Kubernetes Gateway API と core API; New Relic, 2025 Observability Forecast

障害時、1 つのリクエストの経路は Gateway、HTTPRoute、Service、EndpointSlice、Pod、Node に散らばっています。経路をたどり直すには、いくつもの kubectl コマンドと多くの確認が必要です。

エンジニアは業務時間の 33% を障害対応に使っています (New Relic, 2025 Observability Forecast)。

Wave なし

障害時、ゲートウェイからノードまでの経路は 6 つの kubectl 一覧に散らばっています。

Wave あり

Cluster Map がそれらのオブジェクトから経路を描き直します: ゲートウェイ、ルート、サービス、ワークロード、ノード。

オブジェクトの種類は Cluster Map 機能ページより。

kubectl の一覧 6 つから、1 つのマップへ

kubectl のデフォルト一覧 6 つを手で読む

Cluster Mapひとつのマップ

デフォルト: kubernetes.io (Service、EndpointSlices) と Gateway API。Wave: このページの Cluster Map の手順。

ゲートウェイ、ルート、サービス、ワークロード、ノードを 1 つのマップに描きます。ノードにカーソルを合わせると、そのノードを通る経路だけが残ります。

Istio のイングレスとメッシュがあれば、ルートごとの rps と、ワークロードごとの p95 レイテンシ、成功率、CPU スロットリングを表示します。

同じマップを、トラフィック、requests に対するリソース使用量、Wave の適用範囲で塗り分けます。

Namespace 単位でまとめ、ワークロード・サービス・ノードを名前で検索し、クラスタ外への呼び出しも表示します。