Istio Egress — 문서 지도
NOTE
Istio egress(외부로 나가는 트래픽) 문서를 주제별로 모은 아카이브의 지도(MOC)다. 좌측 카탈로그의 6개 토픽(지도 → 멘탈모델 → 구성·재현 랩 → 신원·mTLS → 필드 정본 → 실측 리포트)이 그대로 읽는 순서이고, 이 페이지는 각 문서에 한두 줄 설명을 붙인 큐레이션 인덱스다. 전체 istio 카탈로그(비-egress 포함)는 istio 도메인에 있다.
왜 이 아카이브인가: istio 도메인이 58편으로 커지면서 arch/gt/gw/sec/xds가 한 카탈로그에 섞여 "egress만"
찾기 어려웠다. 그래서 egress 19편을 이 도메인으로 주제별 토픽으로 나눠 복사하고(원본은 istio에 유지),
비-egress로 나가는 링크는 ../istio/로, egress 내부 링크는 로컬로 재작성했다 — egress만 보고 싶을 때
여기 하나만 열면 되게. (원본 문서는 hand-SVG 보존을 위해 렌더된 HTML을 그대로 미러했다.)
1. 🧭 멘탈모델 먼저
egress를 처음 만졌거나, "CRD가 왜 이렇게 많지"에서 막힌다면 여기부터.
- Egress 4-CRD 직관 — 모든 것의 출발점. "한 번의 curl = 두 hop, CRD 4개는 그 두 hop의 질문 4개"라는 멘탈모델. 이 지도의 다른 문서 대부분이 이 골격을 전제로 한다.
- DestinationRule 기초→심화 (신규·라이브 실측) — DR host가 레지스트리와 매칭되어 cluster에 컴파일되는 전 과정, 레벨 3층(top/subset/port)의 "통째 교체" 병합 규칙(portLevelSettings 2단 함정 실측 포함), 같은 host 다중 DR의 조용한 병합, 검증 3단계. "설정했는데 적용 안 됨" 디버깅의 출발점.
- Egress route 스코핑 —
exportTo로 SE/VS 가시성을 좁히는 이유. 안 좁히면 mesh-wide 누수·다른 gateway의 CDS NACK으로 번진다. - Sidecar scope 개념 노트 · 운영 가이드(전체 YAML) —
Sidecar리소스의egress.hosts(config 경량화)와outboundTrafficPolicy(REGISTRY_ONLY 거버넌스). Mesh/Namespace/Workload 세 scope는 merge가 아니라 "가장 좁은 것이 override"라는 의미론이 핵심.
2. 🔀 패턴별 구성 & 재현 랩
실제로 무엇을 어떻게 만들었는지 — 전체 YAML과 왜 그렇게 했는지가 담긴 실습형 문서들.
- Egress 도입 가이드 — passthrough vs mTLS — 4-CRD 멘탈모델을 실전 의사결정 1벌로 압축한, 사내 공유 목적의 표준안.
- 이중 gateway 검증 랩 — passthrough gateway와 mTLS gateway를 별도 pod로 나란히 띄워 대조.
- HTTPS passthrough 가이드 — TLS를 종단하지 않고 SNI로만 라우팅하는 가장 기본적인 egress 패턴.
- TCP 장애 재현 — 한계를 줄여서 관찰 — TCP 병목 정본의 실측 한계(Envoy 1024, 포트 28k, conntrack 26만)를 그대로 재현하려면 연결 수만 개가 필요한데, 이 랩은 한계를 5~20으로 줄여 같은 메커니즘을 연결 수십 개로 재현한다. 실패 시그니처(
UO/UF/무응답/정시절단) 4종이 곧 운영 런북이 된다. - DNS/GSLB resolution 재현 랩 (신규·라이브 실측) —
ServiceEntry.resolution(DNS vs DNS_ROUND_ROBIN)이 GSLB처럼 매번 다른 IP를 주는 도메인에서 "기존 세션이 끊기는가/유지되는가"를 사설 GSLB 시뮬레이터로 라이브 재현. 실측 완료(2026-07-01) — STRICT는 flip 시upstream_cx_destroy +2로 기존 연결 drain(트래픽 이전), LOGICAL은 델타 0으로 세션 유지(단 endpoint 덤프는 새 IP를 보여주는 stale-pin 함정). - Pod 커널 파라미터 정본 (신규) — TCP 병목 정본 §06-4의 확장. 호스트 sysctl이 pod에 전파되지 않는 이유(netns는 상속이 아니라 커널 기본값으로 초기화),
tcp_tw_reuse=1의 안전 근거(PAWS), unsafe sysctl의 3중 관문(kubelet allowlist → PSA → securityContext)과 관문별 실패 시그니처. - Egress TCP 문제별 처방전 (신규) — TCP 병목 정본이 "왜"의 정본이라면 이 문서는 "그래서 뭘 어디에"의 실행본. 문제 5종(연결 거부·포트 고갈·silent drop·유휴 절단·배포 절단) 각각에 증상→설정→위치→YAML→검증을 처방하고, 예시 채널(peak 1,500 / 250 conn/s / FW 30분)로 모든 값을 도출. 4레이어 전체 YAML 종합본 포함.
3. 🔐 신원 · mTLS
"gateway만 세우면 통제된다"는 착각을 깨는 3편 — 신원을 무엇으로 증명하고 어디서 판정하는지.
- mTLS 없이 신원 통제하기 — "신원 확인엔 HTTPS over mTLS(이중 TLS)가 필요하다"는 통념에 대한 반론. 강제는 어차피 chokepoint(gateway)에서 일어나므로, 식별 수단으로 mTLS handshake 대신 Calico pod-selector를 쓰면 단일 클러스터·노드 신뢰 환경에서 더 싸게 같은 결과를 낸다.
- mTLS 신원 통제 가이드 — 반대로 mesh mTLS를 쓰기로 했다면: SPIFFE 신원 + gateway의 AuthorizationPolicy(principal × SNI)로 "누가 어느 목적지를 쓸 수 있나"(Q2)까지 판정하는 법.
- HTTPS over mTLS 해부 — 이중 TLS(outer mesh mTLS + inner 앱 TLS)의 필드 단위 정본. 종단 시 SNI가 소비된다는 것이 이 패턴 전체의 핵심 제약.
4. 📖 필드 정본 (사전)
개념을 다시 훑기보다, 특정 필드가 뭘 하는지 바로 찾아볼 때.
- Egress Gateway 개념 정본 — 필드 단위 사전.
- tcpKeepalive 필드 노트 (신규) — DR
connectionPool.tcp.tcpKeepalive의 time/interval/probes가 커널 소켓 옵션(TCP_KEEPIDLE/KEEPINTVL/KEEPCNT)에 1:1 매핑되는 구조와, 한 설정이 겸하는 두 역할(FW 세션 유지 vs 죽은 상대 감지)의 분리. probe는 데이터가 아니라 Envoy idleTimeout을 리셋하지 못한다. - HTTP vs HTTPS 처리 차이 — 프로토콜에 따라 라우팅·가시성이 어떻게 갈리는지.
- Egress operations — 운영 관점 정리.
- TCP 병목 정본 — 연결·포트·conntrack 한계 수치. §2의 재현 랩이 이 수치를 축소 재현한다.
5. 📊 실측 리포트
홈랩에서 실제로 띄워보고 관측한 결과 기록.
- Ingress·Egress 통합 리포트 — 전체 트래픽 경로를 처음 엮어본 검증 기록.
- 이중 TLS 실측 — SNI 소비 — sidecar↔gw는 mTLS로, 앱 HTTPS는 end-to-end로 보존하는 패턴을 실측. 처음 manifest는 깨졌고, 그 실패 두 개가 "종단하면 SNI가 소비된다"는 핵심 원리를 그대로 드러냈다.
- ServiceEntry DNS resolution 정본 — STRICT_DNS/LOGICAL_DNS, dead IP 처리, GSLB 권장까지. §2의 재현 랩이 이 문서의 이론을 라이브로 증명한다.
참조
- istio 도메인 전체 카탈로그 — 이 지도에 없는 문서(arch/gt/xds/sec 등 비-egress 주제)는 여기서.
- Istio 홈랩 워크스테이션 포털