Istio Mesh Network 그리고 Timeout

현상

Istio Mesh Network를 통해 멀티 클러스터 환경에서 노드 재기동 절차중 발생한 어플리케이션 호출 응답 에러 발생

분명 Pod는 정상적으로 살아 있고 클러스터 내부 네트워킹에는 전혀 문제가 없어보였다.

 

윗 단 네트워크부터 몇달간 보이지 않는 로그를 긁어가며 드디어 원인을 밝히게 되었다.

 

( 공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다.

이는 정확한 정보가 아닐 수 있음을 알려드립니다. )

공식 사이트

https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshNetworks

Global Mesh Options

---

사전 환경 설명

클러스터가 두 개 이상 존재하며, Istio가 meshNetwork를 통해 어플리케이션이 반대 편 엔드포인트를 바라봐야한다.
각 클러스터의 east-west 게이트웨이는 NodePort 형태로 노출되어 있고, meshNetworks endpoint는 NodeIP:NodePort가 직접 나열되어 있는 상태이다.

 

---

 

원인

[Client]
   │ 
   │ 어플리케이션 호출
   ▼
[IngressGateway Envoy]
   │  (1) Gateway가 호스트 수신, VirtualService 매칭 → route.destination = POD.SVC
   │  (2) DestinationRule(POD.SVC)로드 - 연결 정책 확인(라운드 로빈 방식, least 연결 방식 등)  
   │  (3) EDS 조회: 엔드포인트 조회
   │      - 로컬에 POD.SVC 없음
   │      - 원격 네트워크 meshNetworks endpoint 사용
   ▼
[업스트림 선택]
   └─ (정적 게이트웨이 사용) meshNetworks endpoint address: 192.168.x.x:15xxx(실제노드)
          │  Real Node IP이기에 K8s/EDS의 노드 상태 반영 없음
          │
          ├─ (1) Envoy가 선택된 주소(192.168.x.x:15xxx)로 TCP Connect 시도
          │      - 대상 노드 Down → SYN/Connect 실패 (connectTimeout 경과)
          │
          ├─ (2) (VirtualService에 retry가 있으면) 다음 정적 주소로 재시도
          │      - 다음 주소 Alive ⇒ 성공
          │      - 다음 주소도 Down/불통 ⇒ 반복 실패
          │
          └─ (3) (재시도 없거나 모두 실패한 경우)
                 - 클라이언트: 타임아웃 / 504 Gateway Timeout
                 - (추가) DR의 OutlierDetection이 있어도 “최초 연결 시도” 자체는 막지 못함

 

 

멀티클러스터에서 meshNetworks(istio-system/ConfigMap istio)에 게이트웨이 엔드포인트를

정적 IP(예: address: 192.168.x.x, port: 15xxx) 로 등록해두면, Istiod/Envoy는 이를 정적 업스트림 노드 목록으로만 취급한다.

→ 노드 상태/헬스는 감시하지 않는다.

 

따라서 Envoy가 게이트웨이로 연결 시 라운드로빈(또는 내부 기본 정책) 으로 해당 IP에 바로 TCP 연결을 시도하게된다.

→ 대상 노드 Down(혹은 Network가 도달할 수 없는)상태이면 SYN 타임아웃(혹은 connectTimeout 초과)까지 대기하게 되고,

그동안 요청이 지연/실패한다.

 

(추가)이 현상은 서비스에 설정한 DestinationRule의 OutlierDetection/로드밸런싱과 별개이다.
결과적으로 게이트웨이 IP가 죽어 있어도 첫 연결 시도는 타임아웃으로 끝나며, 재시도 정책이 없다면 연쇄적인 지연이 발생한다.
DR은 서비스 파드 엔드포인트 선택/퇴출 단계에서 동작하고, meshNetworks 게이트웨이 IP 선택에는 적용되지 않는다.

 

임시방편

정말 급하다면 Endpoint 자체를 configmap에서 임시로 제거한 뒤 노드 정상화 이후 복구하는걸 추천, 혹은 EnvoyFilter를 사용할것 

---

한줄 정리

이슈의 핵심은 meshNetworks는 Endpoint의 상태를 감지하지 않으며,

DR의 outlierDetection은 게이트웨이에는 적용되지 않는다.

따라서, 게이트웨이 계층에도 헬스 기반 퇴출 로직을 적용하거나,

VIP 단일화로 구조를 개선해야 connect timeout 반복을 방지할 수 있다.

 

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.