The first three chapters have given a brief introduction to the use of ISTIO. If you haven’t read it, you can have a better understanding. This time, we will start to study the data plane of ISTIO.

What is the sidecars

Dividing the functionality of an application into separate processes running in the same minimum scheduling unit (such as Pod in Kubernetes) can be considered sidecar mode. As shown in the figure below, sidecar mode allows you to add more features next to your application.



This mode ensures that we do not need to modify the application itself when controlling poD-level traffic.

What are the advantages of Sidecar

In Sidecar mode, traffic control Containers and service Containers share storage and network resources, similar to two threads in a VM. This deployment mode provides the following advantages for Sidecar:

  • Abstracting functionality unrelated to application business logic into a common infrastructure reduces the complexity of microservice code.
  • Because you no longer need to write the same third-party component configuration files and code, you can reduce code duplication in the microservices architecture.
  • Sidecar can be upgraded independently to reduce coupling between application code and the underlying platform.

What’s in the Sidecar at Istio

Using productPage in bookinfo as an example, let’s see what sidecar starts:



During productPage deployment, IStio deployed two SidecArs for it, one is init Container and the other is the accompanying proxy. During the startup process, POD will start init Container first. After the environment is initialized, Start ProductPage and IStio-Proxy, and set the POD state to RUNNING after both Containers are ready.

Init container parsing

Let’s look at the code for init in YAML

initContainers:
  - args:
    - istio-iptables
    - -p
    - "15001"
    - -z
    - "15006"
    - -u
    - "1337"
    - -m
    - REDIRECT
    - -i
    - The '*'
    - -x
    - ""
    - -b
    - The '*'
    - -d
    - 15090, 15021150, 20
    - --run-validation
    - --skip-rule-apply
    env:
    - name: DNS_AGENT
    image: The rancher/istio - proxyv2:1.7.3
    imagePullPolicy: Always
    name: istio-validation
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 10Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 1337
      runAsNonRoot: true
      runAsUser: 1337
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: bookinfo-productpage-token-88mvv
      readOnly: true
Copy the code

To see the key istio-iptables operations, check the corresponding documentation:

Istio-iptables [flags] -p: specifies the sidecar port on which all TCP traffic is redirected$ENVOY_PORT= 15001) -m: specifies the mode for inbound connections to be redirected to sidecar, "REDIRECT" or "TPROXY" (default$ISTIO_INBOUND_INTERCEPTION_MODE) -b: Comma-separated list of inbound ports whose traffic will be redirected to the Envoy (optional). Use wildcard * to redirect all ports. Null disables all inbound redirection (default$ISTIO_INBOUND_PORTS-d: Specifies the optional list of inbound ports to exclude from the sidecar, separated by commas. Use the wildcard '*' to redirect all inbound traffic (default$ISTIO_LOCAL_EXCLUDE_PORTS) -o: comma-separated list of outbound ports, excluding ports redirected to Envoy. -i: Specifies the IP address range (optional) to be redirected to sidecar. It is a comma-separated LIST in CIDR format. Use the wildcard * to redirect all outbound traffic. An empty list disables all outbound redirection (default$ISTIO_SERVICE_CIDR) -x: Specifies the range of IP addresses to exclude from redirection, a comma-separated list in CIDR format. Use the wildcard '*' to redirect all outbound traffic (default$ISTIO_SERVICE_EXCLUDE_CIDR). -k: indicates the list of virtual interfaces separated by commas. The inbound traffic (from VMS) is regarded as the outbound traffic. -g: Specifies the GID of the user that does not apply redirection. (The default value is the same as that of -u param.) -u: specifies the UID of the user that does not apply redirection. Typically, this is the UID of the proxy container (the default is 1337, which is the UID of isTIO-proxy). -z: The port to which all TCP traffic going to pod/VM should be redirected (default)$INBOUND_CAPTURE_PORT= 15006).Copy the code

This container exists so that the Sidecar agent can intercept all traffic going in and out of the POD, All inbound traffic except ports 15090 (used by Mixer) and 15092 (Ingress Gateway) was redirected to port 15006 (Sidecar). Interception Outbound traffic of the application container is processed by sidecAR (listening through port 15001) and then outbound. For details about the port usage in Istio, see the Istio official documentation. To summarize, the init container is used to:

  • Forward all traffic from the application container to port 15006 of sidecar.
  • Run as an IStio-proxy user. The UID is 1337, that is, the user space where Sidecar resides. This is also the default user used by the ISTIo-Proxy container.
  • Use the default REDIRECT mode to REDIRECT traffic.
  • Redirect all outbound traffic to the Sidecar agent (through port 15001).

Iptables injection parsing of the init container

Kubectl does not support root. Log in to the corresponding machine and use docker to view the iptables rules.

su - root Enter the root password
docker top `docker ps|grep "istio-proxy_productpage"|cut -d "" -f1`
Copy the code



Get the corresponding PID

nsenter -n --target 31565
iptables -t nat -L -v
Copy the code



Here are the routing rules for NAT configuration in Iptables, from which we can see some changes to IStio Init

  • PREROUTING chain: Used for destination address translation (DNAT) to redirect all inbound TCP traffic to the ISTIO_INBOUND chain.
  • OUTPUT chain: Jumps all outbound packets to the ISTIO_OUTPUT chain.
  • The INPUT chain and POSTROUTING chain are not processed
  • ISTIO_INBOUND chain: Redirect all inbound traffic to the ISTIO_IN_REDIRECT chain, except traffic destined for ports 15090 (used by Mixer) and 15020 (used by Ingress Gateway for Pilot health checks), Traffic sent to the above two ports will return to the call point of the IPtables rule chain, which is POSTROUTING, a successor to the PREROUTING chain.
  • ISTIO_IN_REDIRECT chain: All inbound traffic is redirected to local port 15006 and successfully intercepted to sidecar.
  • ISTIO_OUTPUT chain: Select outbound traffic that needs to be redirected to an Envoy (i.e. local) and all non-localhost traffic is forwarded to the ISTIO_REDIRECT. To avoid an infinite loop of traffic in this Pod, all traffic to the IStiO-proxy user space is returned to the next rule at its call point, which in this case is the OUTPUT chain, because breaking out of the ISTIO_OUTPUT rule leads to the next chain POSTROUTING. ISTIO_REDIRECT if the destination is not localhost; If the traffic is from the IStio-proxy user space, then it breaks out of the chain and returns to its call chain to proceed to the next rule (the next rule of OUTPUT, without processing the traffic); All non-ISTIO-proxy user space traffic destined to localhost is redirected to ISTIO_REDIRECT.
  • ISTIO_REDIRECT Chain: All traffic is redirected to Sidecar (local) port 15001.

summary

This shows how sidecar hijacks traffic. Init uses iptables to hijack traffic, but proxy does not. Its job is to execute rules issued by the control plane.

reference

  • Sidecar injection and transparent traffic hijacking in Istio
  • istio-istiod
  • istio-Traffic Management