Platform & Observability

Cluster Map

요청이 게이트웨이에서 라우트, 서비스, 워크로드를 거쳐 노드까지 가는 경로를 한 화면의 지도로 봅니다.

문제

/checkout은 어느 Pod가 처리할까요? kubectl 목록 6개를 봐야 압니다

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

장애가 나면 요청 하나의 경로가 Gateway, HTTPRoute, Service, EndpointSlice, Pod, Node에 흩어져 있습니다. 경로를 다시 그리려면 kubectl 명령 여러 개와 많은 확인이 필요합니다.

엔지니어는 업무 시간의 33%를 장애 대응에 씁니다(New Relic, 2025 Observability Forecast).

Wave 도입 전

장애가 나면 게이트웨이부터 노드까지의 경로가 kubectl 목록 여섯 개에 흩어져 있습니다.

Wave 도입 후

Cluster Map이 그 오브젝트로 경로를 다시 그립니다: 게이트웨이, 라우트, 서비스, 워크로드, 노드.

오브젝트 종류는 Cluster Map 기능 페이지 기준입니다.

kubectl 목록 여섯 개에서 지도 한 장으로

kubectl 기본 방식목록 6개를 직접 읽음

Cluster Map지도 한 장

기본 동작: kubernetes.io (Service, EndpointSlices)와 Gateway API. Wave: 이 페이지의 Cluster Map 단계.

게이트웨이, 라우트, 서비스, 워크로드, 노드를 하나의 지도로 그립니다. 노드에 마우스를 올리면 그 노드를 지나는 경로만 남습니다.

Istio 인그레스와 메시가 있으면 라우트별 rps와 워크로드별 p95 지연, 성공률, CPU throttling을 함께 보여 줍니다.

같은 지도를 트래픽, 요청값 대비 자원 사용, Wave 적용 범위 기준으로 다시 칠합니다.

네임스페이스 단위로 묶고, 워크로드·서비스·노드를 이름으로 찾고, 클러스터 밖으로 나가는 호출도 표시합니다.