<?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>Control Plane Ops on homelab89</title>
    <link>https://blog.homelab89.com/docs/istio/control-plane-ops/</link>
    <description>Recent content in Control Plane Ops on homelab89</description>
    <generator>Hugo</generator>
    <language>ko-KR</language>
    <lastBuildDate>Wed, 10 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.homelab89.com/docs/istio/control-plane-ops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Phantom workload는 컨트롤 플레인의 endpoint 전파 지연으로 stale 스냅샷을 믿는 데이터 플레인이 이미 사라진 워크로드로 트래픽을 보내는 현상이다</title>
      <link>https://blog.homelab89.com/docs/istio/control-plane-ops/phantom-workloads/</link>
      <pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/control-plane-ops/phantom-workloads/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;ABSTRACT&lt;/div&gt;
&lt;p&gt;Phantom workload는 버그가 아니라 메시 아키텍처의 본질적 트레이드오프 — &lt;strong&gt;데이터 플레인 설정의 최종 일관성(eventual consistency)&lt;/strong&gt; — 가 시간 축에 투영된 현상이다. Pod가 사라진 시점과 그 사실이 모든 Envoy의 EDS 스냅샷에 반영되는 시점 사이에는 항상 &lt;strong&gt;전파 지연(propagation lag)&lt;/strong&gt; 윈도가 존재하고, 그 윈도 안에서 Envoy는 죽은 IP를 healthy로 믿고 트래픽을 보낸다. 이 note는 &lt;em&gt;왜 phantom이 구조적으로 불가피한가&lt;/em&gt; 라는 멘탈모델에 집중한다. 단계별 발생 표·완화 YAML·운영 detail은 &lt;a href=&#34;../../../public/istio/arch__src-phantom-workloads.html&#34;&gt;Phantom workloads 처리&lt;/a&gt;에 위임한다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
