<?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>Sds on homelab89</title>
    <link>https://blog.homelab89.com/tags/sds/</link>
    <description>Recent content in Sds 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/sds/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Envoy 정적/동적(xDS) 설정 실습 — Istio in Action Ch.3.2 (출처: 책 &#43; 실습기록 &#43; 공식문서)</title>
      <link>https://blog.homelab89.com/docs/istio/xds-envoy/envoy-static-dynamic-xds-lab/</link>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/xds-envoy/envoy-static-dynamic-xds-lab/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;ABSTRACT&lt;/div&gt;
&lt;p&gt;Envoy 설정은 &lt;code&gt;listener → route → cluster → endpoint&lt;/code&gt;가 서로를 &lt;strong&gt;이름으로&lt;/strong&gt; 참조하는 한 줄 사슬이다. 정적 모드는 이 사슬을 bootstrap에 통째로 인라인하고, 동적 모드(xDS)는 &lt;em&gt;같은 사슬의 각 노드&lt;/em&gt;를 컨트롤 플레인이 런타임에 push로 채운다 — 사슬 자체는 동일하고 &amp;ldquo;공급 방식&amp;quot;만 다르다.
이 문서는 그 한 사슬을 &lt;strong&gt;정적(bootstrap 인라인) → 파일 기반 동적(LDS/RDS) → 실제 ADS(gRPC)&lt;/strong&gt; 세 가지 공급 방식으로 직접 돌려, xDS 계층(LDS/RDS/CDS/EDS/SDS+ADS)이 왜 그렇게 설계됐는지를 손으로 체득하는 실습 기록이다.
결론 먼저: 학습이 목적이면 파일 기반 EDS 삽질을 피하고, 파일 동적 LDS/RDS로 라우팅 변화를 눈으로 본 뒤 곧장 Istio on kind의 &lt;code&gt;istioctl proxy-config&lt;/code&gt;로 진짜 ADS를 관찰하는 경로가 가장 효율적이다.&lt;/p&gt;</description>
    </item>
    <item>
      <title>W3. IGW 커스텀 Deployment 설계 — K8s 매니페스트 구조</title>
      <link>https://blog.homelab89.com/docs/istio/graceful-termination/w3-igw-deployment/</link>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/graceful-termination/w3-igw-deployment/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;ABSTRACT&lt;/div&gt;
&lt;p&gt;홈랩 graceful termination 시리즈 W3. IGW를 Helm 표준 대신 &lt;strong&gt;커스텀 Deployment&lt;/strong&gt;로 구성해 hc 사이드카·volume·probe·preStop·Service NodePort 설계를 manifest 레벨에서 직접 제어한다.
&lt;strong&gt;결론(붙잡을 한 그림)&lt;/strong&gt;: 이 Pod는 &lt;strong&gt;두 개의 독립된 종료 평면(plane)에 신호를 나눠 보내는 health surface&lt;/strong&gt;다. hc 컨테이너가 LB(HAProxy)에는 &lt;code&gt;/health_check.html&lt;/code&gt;로, K8s kubelet에는 &lt;code&gt;/health&lt;/code&gt;·&lt;code&gt;/live&lt;/code&gt; probe로 &lt;em&gt;따로&lt;/em&gt; 종료를 알리고, istio-proxy는 그동안 in-flight를 drain한다. 이 평면 분리 하나가 manifest 전체(포트·probe·preStop·affinity)를 관통하고, &lt;code&gt;current&lt;/code&gt; vs &lt;code&gt;improved&lt;/code&gt;의 in-flight 보존 여부도 이 분리를 얼마나 정교하게 다루느냐의 5가지 차이로 갈린다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
