1 Istio injection and platform ecological impact

Although Istio is platform independent and supports not only K8s, Consul, but also virtual machines, this article focuses on K8s deployment platform environment.

1.1 Environment Preparations

Istio injection of resources was mentioned in the second article in this series, so here’s a review.

Create jiuxi namespace:

# kubectl create ns jiuxi
Copy the code

Write the nginx deployment resource file nginx-deploy.yaml:

apiVersion: apps/v1 kind: Deployment metadata:   name: nginx     namespace: jiuxi     labels:     app: nginx spec:     replicas: 1     selector:         matchLabels:             app: nginx     template:         metadata:             labels:                 app: nginx         spec:             containers:             –   name: nginx                 image: nginx:1.14-alpine                 ports:                 – containerPort: 80

New Nginx Deployment resource:

# kubectl apply -f nginx-deploy.yaml
Copy the code

The following screenshot is displayed:

1.2 Istio Injection operations

Before performing Istio injection, ensure that Istio and IStioctl are correctly installed.

Manually perform Istio injection:

# istioctl kube-inject -f nginx-deploy.yaml | kubectl apply -f -
Copy the code

The screenshot is as follows:

Nginx pods now have two internal containers instead of one.

1.3 Istio infuses the essence

Let’s look at the Istio injection process again:

# istioctl kube-inject -f nginx-deploy.yaml | kubectl apply -f -
Copy the code

The command through the pipe “|” will be two step to step, “|” in nginx before – the deploy. Yaml resource files into istio content, “|” after deployment through istio injected new nginx – deploy. Yaml files.

So what exactly does Istio inject? Run the following command to view the information:

# kubectl edit deployment -n jiuxi nginx
Copy the code

It is found that an init container has been added on the original basis:

Add another isTIO-proxy container:

There is also some environment variable information, as shown below:

Thus, Istio injection is essentially adding Istio features to host resources to enhance the capabilities of the entire platform. It’s the same way Clark turned superman with a cape, braddock sucked alien matter into venom.

The following figure shows Istio injecting istio-init and istio-proxy into nginx Pod:

1.4 Functions and relationships of containers after POD is injected into Istio

The figure above illustrates the pod’s creation of two new containers after Istio injection, so that the original single container pod is now three containers in the same POD, and the host container (Nginx) and isTIO-proxy container are in the same network space.

Istio-init: initializes the container. Initialize pod network space and create iptables rules.

Istio-proxy: indicates a sidecar container. The effect is to start the Pilot – Agent and envoy processes.

You can use kubectl exec-it to enter the nginx and istio-proxy containers of nginx pod and find that the two containers share the same network space. As shown below:

1.5 ISTIo-proxy and envoy relationships

Envoy, like Nginx and HaProxy, is essentially a web proxy server that runs as a process. Envoy also uses nginx-like design patterns (multi-threaded, non-blocking, asynchronous IO) in his architectural design, which I’ll cover in more detail in later lectures.

Istio-proxy is a container that runs in a POD. When the container runs, two key processes, pilot-Agent and envoy, are launched. The Pilot-Agent process periodically communicates with Istio’s Pilot components and envoy receives incoming and outgoing network traffic. The following figure shows the processes in the IStio-Proxy container:

1.6 Relationship between IStio-proxy and Kube-proxy

Formally, istio-Proxy is a container (running inside a POD) and Kube-Proxy is a POD (resource type is Daemonset).

In terms of network traffic processing, istio-proxy and Kube-proxy essentially use iptables/netfilter to process network traffic. It’s just that istio-proxy and Kube-proxy are active in different network Spaces. Istio-proxy is located in pod network space and deals with network traffic within POD, while Kube-Proxy is located in host network space and deals with network traffic within host (kube-Proxy is daemonset, So it is on every node in the K8S cluster).

1.7 Envoy service port

As described above, envoy is a process that runs inside the Istio-Proxy container. Its purpose is to manage network traffic (analogous to Nginx). The following image shows the network ports opened by the envoy process, through which web traffic can enter the inside of the process. Just like the relationship between wind, Windows and houses, wind enters a house through Windows (Internet ports) and a house can have more than one window (Internet ports).

The following image shows the envoy listening port numbers:

The following screenshot shows the functions of the service port:

2 summary

Since then, I’ve taken you through Istio injection and its impact on the platform ecosystem. The following sections continue to describe changes in network traffic flow after Istio injection.