<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Filesystem-Xds on homelab89</title>
    <link>https://blog.homelab89.com/tags/filesystem-xds/</link>
    <description>Recent content in Filesystem-Xds on homelab89</description>
    <generator>Hugo</generator>
    <language>ko-KR</language>
    <lastBuildDate>Sun, 07 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.homelab89.com/tags/filesystem-xds/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>파일 기반 xDS는 DiscoveryResponse 포맷·move 교체만 감지하고 EDS의 &#34;클러스터당 CLA 1개&#34; 제약 때문에 디버깅이 까다롭다</title>
      <link>https://blog.homelab89.com/docs/istio/xds-envoy/file-based-xds-constraints/</link>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/xds-envoy/file-based-xds-constraints/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;ABSTRACT&lt;/div&gt;
&lt;p&gt;머릿속에 둘 한 장면: &lt;strong&gt;파일 기반 xDS는 gRPC ADS의 구독 계약을 그대로 둔 채 전송(transport)만 &amp;ldquo;로컬 파일&amp;quot;로 바꾼 것&lt;/strong&gt;이다. 그래서 세 가지 좁은 제약은 따로 생긴 규칙이 아니라 모두 &lt;em&gt;그 계약&lt;/em&gt;에서 흘러나온다 — ① 파일은 인라인 조각이 아니라 루트에 &lt;code&gt;resources:&lt;/code&gt; 배열을 둔 &lt;strong&gt;DiscoveryResponse 응답&lt;/strong&gt;이어야 하고, ② 파일 watcher가 신뢰하는 변경 신호는 &lt;strong&gt;move(rename) 이벤트&lt;/strong&gt; 하나뿐이며, ③ EDS만은 &amp;ldquo;응답 1개 = 클러스터 1개&amp;quot;라 &lt;strong&gt;클러스터당 ClusterLoadAssignment 1개&lt;/strong&gt;만 허용된다. 결론: LDS/RDS 학습용으로는 훌륭하지만 &lt;strong&gt;파일 EDS는 함정&lt;/strong&gt;이고, xDS를 진짜로 보려면 gRPC ADS(Istio면 &lt;code&gt;istioctl proxy-config&lt;/code&gt;)로 우회하는 편이 빠르다. 깊은 실습 절차는 &lt;a href=&#34;../../docs/istio/xds-envoy/envoy-static-dynamic-xds-lab/&#34;&gt;정적/동적 xDS 실습&lt;/a&gt;에 위임하고, 여기서는 &lt;strong&gt;왜 그런 제약이 생기고 어떻게 판단할지&lt;/strong&gt;의 멘탈모델만 다룬다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
