Skip to main content

Shared ingress trunk — common to all three paths

top-down · three conditions branch into A · B · C · D1 · D2

Kubernetes · Istio Ambient Mesh — Network Datapath — Architecture & Sequence Flows: node-level datapaths, then the message order between components. · interactive original ↗

Standard K8s routingkube-proxy / Calicoistio-cni interceptionztunnel proxyHBONE / mTLSGateway API ingressHTTPRouteMetalLB LoadBalancerVIPPolicy miss / bypassed ClientExternal HTTP(S) requesti1 · HTTP(S) → LoadBalancer VIPMetalLBService LoadBalancer VIP · L2 / BGPi2 · VIP → Gateway listenerGatewayListener · Gateway API impl. (Envoy)Match host / path / headersi3 · Route per backendRef rulesHTTPRoutebackendRef(s) → Service / ServiceEntryCONDITION 1HTTPRoute backendRef — single or weighted canary?single backendRef → Service (Pod-A)weighted backendRefs · canary (RKE2 guest ingress)CONDITION 2Pod-A namespace mesh enrollment?CONDITION 3weighted split — 90% / 10%?→ Ano mesh installed→ Blabel ENABLED→ Clabel ABSENT→ D1weight 90% · production→ D2 (ServiceEntry)weight 10% · canary

Conditions​

  • CONDITION 1 — HTTPRoute backendRef — single or weighted canary? single backendRef → Service (Pod-A) leads to CONDITION 2; weighted backendRefs · canary (RKE2 guest ingress) leads to CONDITION 3.
  • CONDITION 2 — Pod-A namespace mesh enrollment? no mesh installed → A · label ENABLED → B · label ABSENT → C.
  • CONDITION 3 — weighted split — 90% / 10%? weight 90% · production → D1 · weight 10% · canary → D2 (ServiceEntry).

The message order of each path is on 04 · Sequence flows.

Why is Pod-A drawn first?​

These diagrams follow the packet's lifecycle across space boundaries. At the OS level, a Pod isn't really a "thing" — it's a small private room the Linux kernel walls off for it: a Network Namespace (NetNS), giving each Pod its own IP and ports. That's why Pod-A sits before veth-A and kube-proxy.

1 · veth is the room's doorway​

The app code runs in the room's user space, so packets are born inside the Pod. A veth pair is a virtual cable: the end inside the room (eth0) is the socket on the wall, and veth-A is the other end, poking out into the host kernel.

2 · kube-proxy is the signage on the public road​

Its iptables / IPVS (or eBPF) rules live in the host's shared kernel space. You pack a parcel at home (Pod NetNS) and drop it in the box at your front door (veth-A) — only out on the main road does the courier see the road signs (kube-proxy): "traffic for this Service IP → over to that Pod IP."

In one sentence: Pod-A comes first because it is the traffic's source — a packet must be born inside the Pod's isolated room and step out through veth-A into the host kernel before it can meet istio-cni, kube-proxy, and Calico waiting on the kernel's main road.