Service Mesh

First of all, the concept of service grid is introduced. Service Mesh was proposed many years ago, but it didn’t take off until the era of microservices. Istio is actually the implementation and implementation of the concept of service grid. Service grid is upgrade of traditional agent (can be understood as a distributed micro service agent), from the original one or a few agents into each pod in a proxy (can be understood as each pod in comes with a small nginx), be responsible for the work flow, so all traffic by agent to take over, The user’s business and control panel are completely decoupled. The control center is responsible for gathering the information of the whole cluster, and the administrator can manage the whole cluster through the API of the service grid control surface.

Service grid architecture diagram

Here is a sequence diagram of Service1 accessing Service2: Service1 accessing Serivce2 must be intercepted through two SiderCars, and Service1 and Service2 do not communicate directly, but have their own Sidecars

Istio is introduced:

Istio is an open platform for service orders, which makes up for the shortcomings of K8S (such as dynamic routing, link tracing, fusing limiting, etc.) and greatly reduces the complexity of microservice operation and maintenance. According to Istio’s official website, it includes several features of connection, protection, control, and observation services. Istio takes a lot of the burden off the responsible microservices architecture. Developers don’t have to worry about timeout and retry implementations of service calls, and security and authorization between services are automatically guaranteed.

Istio’s official website explains

  • Connect: Intelligently control the call flow between services, which can realize gray upgrade, AB test, red-black deployment and other functions
  • Secure: Automatically provides authentication, authorization, and encryption for calls between services.
  • Control: Apply user-defined policies to ensure fair distribution of resources among consumers.
  • Observe: View various data during service running, such as logs, monitoring, and tracing.

Architecture composition:

Istio architecture diagram

Istio can be roughly divided into two parts: data plane and control plane

Data plane:

Consists of a group of agents that receive and enforce Mixer’s policies

Proxy :(sidecar proxy)

Responsible for efficient forwarding and policy implementation (Envoy type NGINx) Envoy deployed in every POD that needs to manage K8S intercepts all traffic, validated by rules

It will pass through the Enovy agent of this Pod, and Enovy will complete the operations such as rule verification, data collection and log, and then forward it out. It is worth noting that traffic forwarded by Enovy on the requester is sent to Enovy on the receiver before it can reach the real receiver data-product container. Of course, these operations are Istio’s job. All we need to do is tell Istio what we want to do with which traffic through configuration.

Control plane:

Mixer :(reported data)

It is the core of the control plane, and its main responsibility is to obtain the user configuration information from the registry. According to the user configuration information, it processes the request mediation components on the envoy. The communication between the data plane and the control plane is accomplished through Mixer, providing policies and data reporting for the proxy

  • Telemertry components:

  • Policy component: Similar to telemetry, the data plane invokes the Check interface of policy before forwarding a request to the service to check whether access is allowed. Mixer forwards the request to Adapter for corresponding check according to the configuration and returns to the agent whether access is allowed.

Pilot :(service discovery, configuration delivery)

Configure the policy component to provide service discovery, intelligent routing, and error handling for the Proxy, mainly for traffic management, similar to the Master service in the C/S architecture. There’s also a feature that delivers rules to data surfaces, such as VirtualService, DestinationRule, Gateway, ServiceEntry, traffic governance rules, security rules, etc. Pilot is responsible for converting these rules into Envoy readable formats. Sent to the Envoy via the standard xDs protocol to instruct the Envoy to perform the action. In communications, Envoy subscribes to pilot configuration resources via gRPC streaming, and Envoy forwards traffic according to the routing rules.

Citadel :(certificate and key verification)

Citadel always listens to Kube- Apiservicr, generates certificates and keys for each service in the form of Serect, and mounts them on pod when pod is created. Proxy container uses these files for service authentication. Then, the services on both ends of the proxy realize security functions such as two-way TLS authentication, channel encryption and access authorization. This saves the user from having to maintain the certificate key in the code.

Galley :(configuration management)

Configuration management, validation, distribution, component responsible for configuration management, validation of the format and content of configuration information

Gateway :(entrance to a network that uniquely accesses the grid)

It is the only entry in the grid that contains the sidecar

Set up the ISTIO platform

IO/en /docs/set…

Download a.

1. Download istio. If the isTIO file cannot be downloaded from the server, download it to the local PC and upload it to the server

curl -L https://istio.io/downloadIstio | sh -
Copy the code

2. Switch to the Istio package directory. For example, if the Istio package name is ISTIO-1.6.8, :

CD istio - 1.6.8Copy the code

  1. The installation directory contains the following contents:

    • install/kubernetesKubernetes-related YAML installation files are in this directory
    • samples/Under the directory, there are sample applications
    • bin/Directory containing the istiOCT client files.istioctlThe tool is used to manually inject Envoy Sidecar proxies.

  2. Add the istioctl client path to the path environment variable as follows on macOS or Linux:


    e x p o r t P A T H = export PATH=     PWD/bin:$PATH

2. Use the Demo configuration file to install Istio

  1. The installation

    istioctl manifest apply –set profile=demo

  2. To verify the installation, ensure that the following Kubernetes services are correctly deployed, and then verify that all other services except jaeger-Agent have correct cluster-IP:

    $kubectl get SVC -n istio-system NAME TYPE cluster-ip external-ip PORT(S) AGE grafana ClusterIP 172.21.211.123 3000/TCP 2m istio-Citadel ClusterIP 172.21.177.222 8060/TCP,15014/TCP 2m istio-egressGateway ClusterIP 172.21.113.24 80 / TCP, 443 / TCP, 15443 / TCP 2 m istio – galley ClusterIP 172.21.132.247 443 / TCP, 15014 / TCP, 9901 / TCP 2 m istio – ingressgateway LoadBalancer 172.21.144.254 52.116.22.242 15020:31831/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30318/TCP,15030:32645/TCP,15031:31933/TCP,15032:31188/T CP, 15443:30838 / TCP 2 m istio – pilot ClusterIP 172.21.105.205 15010 / TCP, 15011 / TCP, 8080 / TCP, 15014 / TCP 2 m istio – policy ClusterIP 172.21.14.236 9091 / TCP, 15004 / TCP, 15014 / TCP 2 m istio sidecars – injector ClusterIP 172.21.155.47 443 / TCP, 15014 / TCP 2 m istio – telemetry ClusterIP 172.21.196.79 9091 / TCP, 15004 / TCP, 15014 / TCP, 42422 / TCP 2 m jaeger user-agent ClusterIP None The 5775 / UDP, the 6831 / UDP, 6832 / UDP 2 m jaeger – collector ClusterIP 172.21.135.51 14267 / TCP, 14268 / TCP 2 m jaeger – query ClusterIP 172.21.26.187 16686/TCP 2M Kiali ClusterIP 172.21.155.201 20001/TCP 2m Prometheus ClusterIP 172.21.63.159 9090/TCP 2M Tracing ClusterIP 172.21.2.245 80/TCP 2m Zipkin ClusterIP 172.21.182.245 9411/TCP

Ensure that the associated Kubernetes pod has been deployed and its STATUS is Running:

$ kubectl get pods -n istio-system
NAME                                                           READY   STATUS      RESTARTS   AGE
grafana-f8467cc6-rbjlg                                         1/1     Running     0          1m
istio-citadel-78df5b548f-g5cpw                                 1/1     Running     0          1m
istio-egressgateway-78569df5c4-zwtb5                           1/1     Running     0          1m
istio-galley-74d5f764fc-q7nrk                                  1/1     Running     0          1m
istio-ingressgateway-7ddcfd665c-dmtqz                          1/1     Running     0          1m
istio-pilot-f479bbf5c-qwr28                                    1/1     Running     0          1m
istio-policy-6fccc5c868-xhblv                                  1/1     Running     2          1m
istio-sidecar-injector-78499d85b8-x44m6                        1/1     Running     0          1m
istio-telemetry-78b96c6cb6-ldm9q                               1/1     Running     2          1m
istio-tracing-69b5f778b7-s2zvw                                 1/1     Running     0          1m
kiali-99f7467dc-6rvwp                                          1/1     Running     0          1m
prometheus-67cdb66cbb-9w2hm                                    1/1     Running     0          1m
Copy the code

3. Follow-up steps

1. Automatic injection:

When deploying the application using Kubectl apply, if the POD starts in the namespace marked with IStio-Injection =enabled, the IStio Sidecar injector will automatically inject the application’s POD into the Envoy:

kubectl label namespace <namespace> istio-injection=enabled
Copy the code

or

kubectl create -n <namespace> -f <your-app-spec>.yaml
Copy the code
2. Manual injection:

In namespaces without the IStio-injection flag, the istioctl kube-inject command can be used to manually inject an Envoy into an application’s POD before deployment:

istioctl kube-inject -f <your-app-spec>.yaml | kubectl apply -f -
Copy the code