In a previous blog, I explained the detailed process of sidecar injection in Istio, using iptables for transparent traffic interception and traffic routing, and took the productpage service in the productpage example to access the reviews service, and the reviews service to access the ratings service as an example to draw Schematic diagram of transparent traffic hijacking. In that diagram, only the routing of the reviews pod to receive traffic and external access is shown, in fact, the traffic inside the sidecar is much more than that.
This article will show you the six traffic types in the Istio sidecar and their iptables rules, and give you an overview of them in schematic form.
iptables traffic routing in sidecar
Traffic in a sidecar can be divided into the following categories:
- Remote service access local service: Remote Pod -> Local Pod
- Local services access remote services: Local Pod -> Remote Pod
- Prometheus crawls metrics for local services: Prometheus -> Local Pod
- Traffic between local Pod services: Local Pod -> Local Pod
- Interprocess TCP traffic inside Envoy
- Sidecar to Istiod traffic
The following will explain the iptables routing rules in Sidecar in each scenario in turn.
Type 1: Remote Pod -> Local Pod
The following are the iptables rules for remote services, applications or clients to access the local Pod IP of the data plane.
Remote Pod -> RREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> Envoy 15006 (Inbound) -> OUTPUT -> ISTIO_OUTPUT RULE 1 -> POSTROUTING -> Local Pod
We see traffic going through Envoy 15006 inbound port only once. A schematic diagram of the iptables rules in this scenario is as follows.
Type 2: Local Pod -> Remote Pod
The following are the iptables rules through which the local Pod IP accesses the remote service.
Local Pod -> OUTPUT -> ISTIO_OUTPUT RULE 9 -> ISTIO_REDIRECT -> Envoy 15001 (Outbound) -> OUTPUT -> ISTIO_OUTPUT RULE 4 -> POSTROUTING -> Remote Pod
We see that traffic only goes through the Envoy 15001 outbound port. A schematic diagram of the iptables rules in this scenario is as follows.
The traffic in the above two scenarios only goes through Envoy once, because there is only one scenario in which a request is made or received in the Pod.
Type 3: Prometheus -> Local Pod
Traffic that Prometheus crawls data plane metrics does not and does not have to go through the Envoy proxy.
The iptables rules that these traffic pass through are as follows.
Prometheus-> RREROUTING -> ISTIO_INBOUND (for ports destined for 15002, 15090, traffic will go to INPUT ) -> INPUT -> OUTPUT -> ISTIO_OUTPUT RULE 3 -> POSTROUTING -> Local Pod
A schematic diagram of the iptables rules in this scenario is as follows.
Type 4: Local Pod -> Local Pod
A Pod may have two or more services at the same time. If the service accessed by the Local Pod is also on the current Pod, the traffic will pass through Envoy 15001 and Envoy 15006 ports in turn and finally reach the service port of the local Pod.
The iptables rules that these traffic pass through are as follows.
Local Pod -> OUTPUT -> ISTIO_OUTPUT RULE 9 -> ISTIO_REDIRECT -> Envoy 15001 (Outbound) -> OUTPUT -> ISTIO_OUTPUT RULE 2 -> ISTIO_IN_REDIRECT -> Envoy 15006 (Inbound) -> OUTPUT -> ISTIO_OUTPUT RULE 1 -> POSTROUTING – > Local Pod
A schematic diagram of the iptables rules in this scenario is as follows.
Type 5: Interprocess TCP traffic inside Envoy
The UID and GID of Envoy’s internal process is 1337, and the traffic between them will use the lo network card to communicate using the localhost domain name.
The iptables rules that these traffic pass through are as follows.
Envoy process (Localhost) -> OUTPUT -> ISTIO_OUTPUT RULE 8 -> POSTROUTING -> Envoy process (Localhost)
A schematic diagram of the iptables rules in this scenario is as follows.
Type 6: Traffic from Sidecar to Istiod
Sidecars need access to Istiod to sync configuration, so Envoy will send traffic to Istiod.
The iptables rules that these traffic pass through are as follows.
Local Pod -> OUTPUT -> ISTIO_OUTPUT RULE 4 -> POSTROUTING -> Istiod
A schematic diagram of the iptables rules in this scenario is as follows.
Summarize
Istio injects all sidecar proxies installed in Pods or virtual machines to form the data plane of the service mesh, and is also the location of Istio’s main workloads. Through transparent traffic hijacking in Istio and this blog, I believe you must be in the sidecar proxy. In my next blog , I will take you to understand the ports and their functions of various components in Envoy, which will give us a good understanding of what is in Istio. have a more comprehensive view of the traffic.
This article is reprinted from https://jimmysong.io/blog/istio-sidecar-traffic-types/
This site is for inclusion only, and the copyright belongs to the original author.