<?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>Revision on homelab89</title>
    <link>https://blog.homelab89.com/tags/revision/</link>
    <description>Recent content in Revision 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/revision/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>control plane과 data plane의 설치·수명주기를 분리하면 istiod 업그레이드가 data plane에 투명해진다</title>
      <link>https://blog.homelab89.com/docs/istio/control-plane-ops/cp-dp-decoupling/</link>
      <pubDate>Sun, 07 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.homelab89.com/docs/istio/control-plane-ops/cp-dp-decoupling/</guid>
      <description>&lt;div class=&#34;callout abstract&#34;&gt;
&lt;div class=&#34;ct&#34;&gt;이 문서가 다루는 것&lt;/div&gt;
&lt;p&gt;&amp;ldquo;Istio를 업그레이드한다&amp;quot;가 왜 &amp;ldquo;mesh 전체를 한 번에 흔드는 일&amp;quot;이 아니라 &amp;ldquo;proxy를 하나씩 새 control plane으로 옮기는 일&amp;quot;이 될 수 있는지를 다룬다. 결론부터: &lt;strong&gt;istiod(control plane)와 Envoy(data plane)는 xDS라는 느슨한 gRPC 계약으로만 묶인 별개 컴포넌트&lt;/strong&gt;라서, 새 istiod를 옆에 나란히 띄우고(revision canary) workload를 한 namespace씩 옮길 수 있고, 그래서 control plane 교체가 data plane에 투명해진다. 설치 단위(base/istiod/gateway 3 Helm chart)·revision 메커니즘·canary 흐름을 &amp;ldquo;왜 이렇게 설계됐나&amp;quot;의 원리로 풀고, 운영 detail(canary 명령·합격 기준)은 &lt;a href=&#34;../../docs/istio/control-plane-ops/operations-playbook/&#34;&gt;운영 플레이북 §06&lt;/a&gt;에 위임한다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
