https://docs.makgol.com/study/istio-mesh/Recent content in 한 요청의 여행 on makgol's noteHugo -- gohugo.ioko-KR© 2026 MontSat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/01-l4-l7-before-mesh/Sat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/01-l4-l7-before-mesh/ <h1>01 · 한 연결에 묶인 길 — 메시 이전의 L4와 L7</h1><p>입구에서 HTTP 요청을 나눠도 서비스 사이의 호출은 다시 연결 단위로 묶입니다. 먼저 사이드카가 없는 경로를 봅니다.</p> <figure class="vm-flow"> <figcaption class="flow-caption">입구의 L7 규칙은 외부 요청에 적용되고, 앱 A가 시작한 내부 호출은 ClusterIP의 연결 단위 선택을 따릅니다.</figcaption> <script type="application/json" class="flow-spec">{ "caption": "입구의 L7 규칙은 외부 요청에 적용되고, 앱 A가 시작한 내부 호출은 ClusterIP의 연결 단위 선택을 따릅니다.", "token": true, "nodes": [ { "id": "c", "col": 0, "row": 0, "label": "외부 클라이언트", "kind": "src" }, { "id": "g", "col": 1, "row": 0, "label": "Ingress", "kind": "proc", "sub": "L7 · 경로별 분기" }, { "id": "a", "col": 2, "row": 0, "label": "앱 A", "kind": "proc" }, { "id": "k", "col": 2, "row": 1, "label": "ClusterIP", "kind": "query", "sub": "L4 · 연결별 선택" }, { "id": "b", "col": 1, "row": 1, "label": "앱 B", "kind": "sink" } ], "edges": [ { "from": "c", "to": "g", "label": "HTTP" }, { "from": "g", "to": "a", "label": "요청" }, { "from": "a", "to": "k", "label": "새 호출" }, { "from": "k", "to": "b", "label": "DNAT" } ] } </script><details class="vm-spec-text"> <summary>도식 텍스트</summary> <ul> <li>외부 클라이언트</li> <li>Ingress — L7 · 경로별 분기</li> <li>앱 A</li> <li>ClusterIP — L4 · 연결별 선택</li> <li>앱 B</li> </ul> <ul> <li>HTTP</li> <li>요청</li> <li>새 호출</li> <li>DNAT</li> </ul> </details> </figure> <h2>입구 너머의 ClusterIP<span class="hx:absolute hx:-mt-20" id="입구를-지난-서비스-호출은-다시-clusterip로"></span> <a href="#%ec%9e%85%ea%b5%ac%eb%a5%bc-%ec%a7%80%eb%82%9c-%ec%84%9c%eb%b9%84%ec%8a%a4-%ed%98%b8%ec%b6%9c%ec%9d%80-%eb%8b%a4%ec%8b%9c-clusterip%eb%a1%9c" class="subheading-anchor" aria-label="이 섹션에 대한 고유 링크"></a></h2><p>앱 A가 Service 이름으로 B를 부르면 DNS가 ClusterIP를 돌려줍니다. kube-proxy의 iptables 모드에서는 새 연결의 대상을 고르고 목적지를 파드 IP로 바꿉니다(DNAT). 이후 패킷은 conntrack이 기억한 대상을 따릅니다.</p>https://docs.makgol.com/study/istio-mesh/02-gateway-to-sidecar/Sat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/02-gateway-to-sidecar/ <h1>02 · 다시 길을 고르는 문 — 게이트웨이에서 사이드카까지</h1><p>외부 요청은 게이트웨이에서 HTTP로 읽힌 뒤, 선택된 파드의 사이드카로 향합니다. 아래는 NLB에 <strong>TCP 리스너</strong>를 둔 사이드카 모드의 경로입니다.</p>https://docs.makgol.com/study/istio-mesh/03-proxy-to-proxy/Sat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/03-proxy-to-proxy/ <h1>03 · 신원을 주고받는 두 프록시 — 사이드카와 사이드카 사이</h1><p>앱 A가 <code>http://svc-b:8080</code>을 부르면 양쪽 사이드카가 요청을 주고받습니다. 아래는 HTTP로 인식한 내부 호출의 경로입니다.</p>https://docs.makgol.com/study/istio-mesh/04-l7-only-features/Sat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/04-l7-only-features/ <h1>04 · 요청을 읽는 갈림길 — L7 프록시가 여는 기능</h1><p>HTTP를 읽는 사이드카는 연결 하나 안의 요청을 각각 다른 파드로 보낼 수 있습니다. 재시도·트래픽 분할·경로별 인가도 이 요청 경계에서 시작합니다.</p>https://docs.makgol.com/study/istio-mesh/05-logs-and-tracing/Sat, 07 Nov 2026 00:00:00 +0900https://docs.makgol.com/study/istio-mesh/05-logs-and-tracing/ <h1>05 · 요청 뒤에 남은 발자국 — 메트릭·로그·트레이스</h1><p>같은 요청도 어느 프록시에서 보느냐에 따라 기록이 달라집니다. 먼저 호출 쪽과 대상 쪽을 나눠 봅니다.</p> <figure class="vm-flow"> <figcaption class="flow-caption">정상적인 내부 호출을 양쪽 사이드카가 각각 관측합니다. reporter를 구분하지 않고 합산하면 같은 호출을 중복해서 셉니다.</figcaption> <script type="application/json" class="flow-spec">{ "caption": "정상적인 내부 호출을 양쪽 사이드카가 각각 관측합니다. reporter를 구분하지 않고 합산하면 같은 호출을 중복해서 셉니다.", "font": 1.2, "nodes": [ { "id": "a", "col": 0, "row": 0, "label": "호출 앱", "kind": "src" }, { "id": "cs", "col": 0, "row": 1, "label": "호출 사이드카", "sub": "outbound", "kind": "proc" }, { "id": "ss", "col": 1, "row": 1, "label": "대상 사이드카", "sub": "inbound", "kind": "proc" }, { "id": "b", "col": 1, "row": 0, "label": "대상 앱", "kind": "sink" }, { "id": "cr", "col": 0, "row": 2, "label": "source", "sub": "호출 쪽 메트릭", "kind": "store" }, { "id": "sr", "col": 1, "row": 2, "label": "destination", "sub": "대상 쪽 메트릭", "kind": "store" } ], "edges": [ { "from": "a", "to": "cs", "label": "HTTP" }, { "from": "cs", "to": "ss", "label": "mTLS" }, { "from": "ss", "to": "b", "label": "HTTP" }, { "from": "cs", "to": "cr", "label": "요청마다" }, { "from": "ss", "to": "sr", "label": "요청마다" } ] } </script><details class="vm-spec-text"> <summary>도식 텍스트</summary> <ul> <li>호출 앱</li> <li>호출 사이드카 — outbound</li> <li>대상 사이드카 — inbound</li> <li>대상 앱</li> <li>source — 호출 쪽 메트릭</li> <li>destination — 대상 쪽 메트릭</li> </ul> <ul> <li>HTTP</li> <li>mTLS</li> <li>HTTP</li> <li>요청마다</li> <li>요청마다</li> </ul> </details> </figure> <h2>요청 하나, 두 관측 지점<span class="hx:absolute hx:-mt-20" id="요청-하나에-기록이-두-번-남는-자리"></span> <a href="#%ec%9a%94%ec%b2%ad-%ed%95%98%eb%82%98%ec%97%90-%ea%b8%b0%eb%a1%9d%ec%9d%b4-%eb%91%90-%eb%b2%88-%eb%82%a8%eb%8a%94-%ec%9e%90%eb%a6%ac" class="subheading-anchor" aria-label="이 섹션에 대한 고유 링크"></a></h2><p><code>reporter=&quot;source&quot;</code>는 호출 쪽, <code>reporter=&quot;destination&quot;</code>은 대상 쪽 프록시의 메트릭입니다. 둘을 합하면 정상적인 내부 호출도 중복 집계됩니다. 재시도나 연결 실패가 끼면 양쪽 수치가 달라질 수 있습니다.</p>