Mental-Model on homelab89

Egress 4-CRD 직관 — "한 번의 curl = 두 hop", 4개를 어떤 순서로 어떻게 채우나

Thu, 02 Jul 2026 00:00:00 +0000

ABSTRACT

egress gateway 설정이 “Gateway·VirtualService·ServiceEntry·DestinationRule을 왜 4개나, 어느 필드를 어디에"로 막히는 이유는 멘탈모델 없이 필드부터 보기 때문이다. 이 문서는 거꾸로 간다 — 먼저 “한 번의 외부 호출이 두 hop으로 쪼개지고, 4개 CRD는 각자 다른 hop의 다른 질문에 답하는 부품"이라는 그림을 세운 뒤, 실제로 두 패턴(passthrough / outer-mTLS)을 어떤 순서로 어떻게 만들었는지를 그때의 YAML과 함께 따라간다. 결론: 4개는 따로 노는 게 아니라 두 hop을 굴리기 위한 질문 4개이고, 패턴 전환은 “3개 델타"일 뿐이다. 필드 단위 레퍼런스(=사전)는 Egress Gateway 정본·HTTPS over mTLS 해부, 검증 랩은 이중 gateway 가이드.

Phantom workload는 컨트롤 플레인의 endpoint 전파 지연으로 stale 스냅샷을 믿는 데이터 플레인이 이미 사라진 워크로드로 트래픽을 보내는 현상이다

Wed, 10 Jun 2026 00:00:00 +0000

ABSTRACT

Phantom workload는 버그가 아니라 메시 아키텍처의 본질적 트레이드오프 — 데이터 플레인 설정의 최종 일관성(eventual consistency) — 가 시간 축에 투영된 현상이다. Pod가 사라진 시점과 그 사실이 모든 Envoy의 EDS 스냅샷에 반영되는 시점 사이에는 항상 전파 지연(propagation lag) 윈도가 존재하고, 그 윈도 안에서 Envoy는 죽은 IP를 healthy로 믿고 트래픽을 보낸다. 이 note는 왜 phantom이 구조적으로 불가피한가 라는 멘탈모델에 집중한다. 단계별 발생 표·완화 YAML·운영 detail은 Phantom workloads 처리에 위임한다.

xDS는 Envoy 설정을 LDS/RDS/CDS/EDS/SDS 계층으로 나누고 ADS가 이를 단일 스트림으로 묶어 적용 순서를 보장한다

Wed, 10 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

Envoy의 동적 설정은 단일 덩어리가 아니라 5개 xDS API(LDS/RDS/CDS/EDS/SDS)로 분리되어 “리스닝 지점 / 라우팅 / upstream pool / 실제 endpoint / TLS secret"이라는 서로 다른 계층을 각각 담당한다. 이 분리는 부분 업데이트를 가능하게 하지만 동시에 순서 문제를 낳는다 — route가 아직 없는 cluster를 가리키면 트래픽이 깨진다. ADS(Aggregated Discovery Service) 가 이 여러 xDS를 하나의 gRPC 스트림으로 묶어 적용 순서를 보장함으로써 그 문제를 푼다. 이 문서는 그 개념·멘탈모델에 집중하고, istioctl proxy-config로 각 계층을 진단하는 운영 상세는 xDS 5계층과 istioctl 진단으로 위임한다.