クラスター名の確認

outbound|9080|v2|reviews.default.svc.cluster.local 이라는 클러스터 이름에서 읽을 수 있는 것은?

• 이 파드가 reviews 서비스의 9080 포트로 나갈 때, 서브셋 v2 엔드포인트로 보내는 클러스터다
• reviews 파드가 9080 포트로 들어오는 요청을 v2 컨테이너로 넘기는 클러스터다
• reviews 서비스의 두 번째 판(v2)이 9080 포트로 노출된 게이트웨이 리스너다
• 9080 포트를 쓰는 모든 서비스 중 v2 라벨이 붙은 파드를 모은 클러스터다

DestinationRule 에 서브셋 v1·v2 를 정의한 서비스 하나에 대해 istiod 가 나가는 쪽에 만드는 클러스터 수는(포트 하나 기준)?

• 두 개 — 서브셋마다 하나
• 하나 — 서브셋은 라우트에서만 쓰이므로
• 세 개 — 서브셋 없는 기본 클러스터 하나와 서브셋마다 하나
• 네 개 — 서브셋마다 나가는 쪽과 들어오는 쪽 하나씩

VirtualService 가 DestinationRule 에 없는 서브셋 v3 을 가리킨다. 사이드카에서 일어나는 일로 맞는 것은?

• Envoy 가 동적 설정을 통째로 거절해 이전 설정을 계속 쓴다
• 설정은 받아들여지고, 그 라우트로 오는 요청이 503(응답 플래그 NC)이 된다
• istiod 가 서브셋 없는 기본 클러스터로 자동으로 바꿔 보낸다
• 요청이 BlackHoleCluster 로 가서 연결이 끊긴다

서브셋 클러스터 outbound|9080|v1|… 의 엔드포인트는 어떻게 정해지는가?

• DestinationRule 에 적은 IP 목록이 그대로 들어간다
• VirtualService 의 weight 비율만큼 서비스 엔드포인트를 나눠 담는다
• v1 이라는 이름의 별도 쿠버네티스 서비스의 엔드포인트를 쓴다
• 같은 서비스의 엔드포인트 중 서브셋 라벨(version: v1)이 붙은 파드만 추린다

통계 cluster.outbound|9080|v2|reviews….upstream_rq_503 이 대시보드에서 갑자기 사라지고 cluster.outbound_9080_v2_reviews.… 가 생겼다. 가장 그럴듯한 원인은?

• v2 서브셋이 삭제되고 같은 파드를 가리키는 새 이름의 서비스가 만들어졌다
• Envoy 판이 올라가면서 클러스터 통계의 이름 형식이 통째로 바뀌었다
• 메시 설정의 outboundClusterStatName 이 바뀌어 istiod 가 alt_stat_name 을 붙였다
• 프로메테우스가 긁어 갈 때 이름의 | 를 _ 로 자동 치환하기 시작했다

카나리 배포 때 VirtualService 와 DestinationRule 을 적용하는 안전한 순서는?

• VirtualService 먼저 — 라우트가 있어야 서브셋이 만들어진다
• 동시에 — 한 파일에 넣으면 istiod 가 원자적으로 처리한다
• 순서는 상관없다 — istiod 가 일관된 스냅샷만 내려보낸다
• DestinationRule 먼저 — 서브셋 클러스터가 먼저 있어야 라우트가 가리킬 곳이 생긴다