https://blog.homelab89.com/tags/eds/ Recent content in Eds on homelab89 Hugo ko-KR Sun, 07 Jun 2026 00:00:00 +0000 https://blog.homelab89.com/docs/istio/control-plane-ops/phantom-workloads-lab/ Sun, 07 Jun 2026 00:00:00 +0000 https://blog.homelab89.com/docs/istio/control-plane-ops/phantom-workloads-lab/ <div class="callout abstract"> <div class="ct">ABSTRACT</div> <p>Phantom workload는 이미 사라진 Pod의 endpoint IP가 Envoy의 EDS-CLA에 stale로 남아 트래픽이 죽은 IP로 흘러 발생하는 유령 라우팅이다. 머릿속에 담을 단 하나의 그림: <strong>&ldquo;이벤트 발생 → 새 EDS 도달&rdquo; 사이의 시간축 윈도</strong>(phantom window). 이 윈도가 열려 있는 동안 들어온 요청이 죽은 IP로 간다. 근본 원인은 컨트롤→데이터 플레인 전파의 <strong>최종 일관성(propagation lag)</strong> 이라 윈도를 0으로 만들 수 없고, 대응은 같은 윈도를 두 각도에서 친다 — <strong>(A) 윈도 폭 줄이기</strong>(전파 가속, 마지막 수단)와 <strong>(B) 윈도 안 요청 흡수</strong>(retry + outlier detection + graceful drain, 실무 표준).</p> https://blog.homelab89.com/docs/istio/xds-envoy/file-based-xds-constraints/ Sun, 07 Jun 2026 00:00:00 +0000 https://blog.homelab89.com/docs/istio/xds-envoy/file-based-xds-constraints/ <div class="callout abstract"> <div class="ct">ABSTRACT</div> <p>머릿속에 둘 한 장면: <strong>파일 기반 xDS는 gRPC ADS의 구독 계약을 그대로 둔 채 전송(transport)만 &ldquo;로컬 파일&quot;로 바꾼 것</strong>이다. 그래서 세 가지 좁은 제약은 따로 생긴 규칙이 아니라 모두 <em>그 계약</em>에서 흘러나온다 — ① 파일은 인라인 조각이 아니라 루트에 <code>resources:</code> 배열을 둔 <strong>DiscoveryResponse 응답</strong>이어야 하고, ② 파일 watcher가 신뢰하는 변경 신호는 <strong>move(rename) 이벤트</strong> 하나뿐이며, ③ EDS만은 &ldquo;응답 1개 = 클러스터 1개&quot;라 <strong>클러스터당 ClusterLoadAssignment 1개</strong>만 허용된다. 결론: LDS/RDS 학습용으로는 훌륭하지만 <strong>파일 EDS는 함정</strong>이고, xDS를 진짜로 보려면 gRPC ADS(Istio면 <code>istioctl proxy-config</code>)로 우회하는 편이 빠르다. 깊은 실습 절차는 <a href="../../docs/istio/xds-envoy/envoy-static-dynamic-xds-lab/">정적/동적 xDS 실습</a>에 위임하고, 여기서는 <strong>왜 그런 제약이 생기고 어떻게 판단할지</strong>의 멘탈모델만 다룬다.</p>