共用 ingress 主幹 — 三條路徑共通

由上而下 · 三個條件分流到 A · B · C · D1 · D2

Kubernetes · Istio Ambient Mesh — 網路資料路徑 — 架構與序列流程：先看節點層級的資料路徑，再看元件之間的訊息順序。 · 互動原版 ↗

條件

• 條件 1 — HTTPRoute backendRef — 單一或加權 canary？ 單一 backendRef → Service (Pod-A) 進入條件 2；加權 backendRefs · canary (RKE2 guest ingress) 進入條件 3。
• 條件 2 — Pod-A 命名空間是否加入 mesh？ 未安裝 mesh → A · 標籤已啟用 → B · 標籤不存在 → C。
• 條件 3 — 加權分流 — 90% / 10%？ 權重 90% · 正式 → D1 · 權重 10% · canary → D2 (ServiceEntry)。

各路徑的訊息順序見 04 · 序列流程。

為什麼先畫 Pod-A？

這些圖沿著封包的生命週期跨越各個空間邊界。在 OS 層級，Pod 其實不是一個「東西」——它是 Linux 核心為它圍出來的一個小私人房間：一個 Network Namespace (NetNS)，讓每個 Pod 擁有自己的 IP 與 port。這就是 Pod-A 排在 veth-A 與 kube-proxy 之前的原因。

1 · veth 是房間的門口

應用程式碼在房間的使用者空間執行，所以封包是在 Pod 裡面誕生的。veth pair 是一條虛擬纜線：房間內的那一端（eth0）是牆上的插座，veth-A 則是另一端，探出到主機核心。

2 · kube-proxy 是公共道路上的路標

它的 iptables / IPVS（或 eBPF）規則位於主機共用的核心空間。你在家裡（Pod NetNS）打包包裹，放到家門口的信箱（veth-A）——快遞員要到了大馬路上才會看到路標（kube-proxy）：「送往這個 Service IP 的流量 → 轉到那個 Pod IP」。

一句話總結： Pod-A 排在最前面，因為它是流量的來源——封包必須先在 Pod 的隔離房間裡誕生，經 veth-A 走出到主機核心，才會遇到在核心大馬路上等著的 istio-cni、kube-proxy 與 Calico。