proxy-config 수백 줄을 표로 읽는 법

한 줄 요약

사이드카의 클러스터 이름은 방향|포트|서브셋|호스트 네 칸으로 규칙대로 만들어진다. DestinationRule 의 서브셋 하나가 클러스터 하나가 되고, 통계와 오류 메시지가 전부 이 이름을 달고 나온다. 이름을 읽을 줄 알면 proxy-config 출력 수백 줄이 표로 보인다.

왜 이게 필요했나

istioctl proxy-config clusters <파드> 를 처음 열면 이런 줄이 끝없이 나온다.

outbound|9080||reviews.default.svc.cluster.localoutbound|9080|v1|reviews.default.svc.cluster.localoutbound|9080|v2|reviews.default.svc.cluster.localinbound|9080||

이 이름을 읽지 못하면 두 가지를 할 수 없다. 첫째, "v2 로 가는 요청이 왜 503 인가" 를 볼 때 v2 서브셋 클러스터가 있기는 한지, 엔드포인트가 몇 개인지 확인할 수 없다. 둘째, 대시보드의 cluster.outbound|9080|v2|…upstream_rq_503 같은 지표가 어느 서비스의 무엇인지 알 수 없다. Istio 는 수천 개의 클러스터를 사람 손 없이 만들어야 해서 이름을 규칙으로 정했고, 그 규칙이 곧 읽는 법이다.

어떻게 동작하나

| 칸 | 값 | 비는 경우 |
| --- | --- | --- |
| 방향 | outbound(이 파드가 남을 부를 때) / inbound(남이 이 파드를 부를 때) | 없음 |
| 포트 | 서비스 포트(9080) | 없음 |
| 서브셋 | DestinationRule 의 subsets[].name | 서브셋을 안 고른 기본 클러스터 |
| 호스트 | 서비스의 FQDN | 들어오는 쪽(자기 앱으로 보내니까) |

istiod 는 메시의 서비스·포트마다 서브셋 없는 클러스터를 늘 만들고, DestinationRule 에 서브셋이 있으면 서브셋마다 하나씩 더 만든다. 서브셋 클러스터의 엔드포인트는 같은 서비스의 엔드포인트 중 라벨이 맞는 것만 추린 부분집합이다. 그래서 라벨이 없는 파드는 서브셋 클러스터 어디에도 들지 않는다.

VirtualService 의 destination: {host: reviews, subset: v1} 은 라우트가 outbound|9080|v1|reviews… 클러스터를 가리키는 것으로 번역된다. 여기서 흔한 사고가 나온다. DestinationRule 에 없는 서브셋을 가리키면 istiod 는 없는 클러스터를 가리키는 라우트를 내려보낸다. Envoy 는 동적으로 받은 라우트의 클러스터를 미리 확인하지 않으므로(validate_clusters 기본값이 false) 설정은 받아들여지고, 요청이 올 때 503 이 나며 접근 로그에 NC(no cluster)가 찍힌다. 파일로 적은 정적 설정은 기본값이 true 라 같은 설정을 기동 때 거절한다 — 같은 실수가 어디서 드러나는지가 다르다.

통계는 cluster.<이름>.<지표> 로 쌓인다. | 가 든 이름은 프로메테우스 레이블로 옮길 때 번거로워서, 메시 설정의 outboundClusterStatName 에 무늬를 주면 istiod 가 각 클러스터에 alt_stat_name 을 붙인다. 라우팅은 원래 이름으로 하고 통계 이름만 바뀐다.

현장에서 만나는 모습

카나리를 걸었더니 v2 로 가는 요청만 전부 503. VirtualService 를 먼저 배포하고 DestinationRule 을 나중에 배포한 경우다. 그 사이 몇 초~몇 분 동안 v2 서브셋 클러스터가 없다. proxy-config clusters 에 v2 줄이 있는지부터 본다. 그래서 순서는 늘 DestinationRule 먼저, VirtualService 나중이다.

서브셋 클러스터의 엔드포인트가 0개. 이름은 있는데 proxy-config endpoints 가 비어 있으면 서브셋의 라벨과 파드 라벨이 어긋난 것이다(version: v2 대 version: 2.0). 이때 응답 플래그는 NC 가 아니라 UH(건강한 업스트림 없음)이므로, 플래그 두 글자만 보고도 '클러스터가 없다' 와 '클러스터는 있는데 비었다' 를 가를 수 있다.

대시보드가 갑자기 비었다. 누군가 메시 설정의 outboundClusterStatName 을 바꾸면 통계 이름이 통째로 바뀌어 옛 이름으로 짠 쿼리가 전부 빈다. 라우팅은 멀쩡하므로 한참 뒤에야 발견된다.

공식 문서: [Debugging Envoy and Istiod](https://istio.io/latest/docs/ops/diagnostic-tools/proxy-cmd/) · [DestinationRule](https://istio.io/latest/docs/reference/config/networking/destination-rule/)

다음 실습에서 할 것

DestinationRule 을 쓰고 규칙으로 클러스터 이름 네 개를 도출한 뒤, 그 이름 그대로 Envoy 를 세워 서브셋별로 요청을 나눠 본다. 통계 이름을 alt_stat_name 으로 바꾸고, 없는 서브셋을 가리켜 503 과 no_cluster 를 만든 다음, 서브셋이 같은 엔드포인트의 부분집합이라는 것을 /clusters 로 센다.