Shulou(Shulou.com)06/02 Report--

[this article is transferred from the official account of Wechat: Liu Chao's popular cloud computing]

Service Mesh became popular after Kubernetes called it a standard for container orchestration, but many articles talked more about concepts and less about technical details, so I wrote an article specifically to analyze the technical details behind Service Mesh.

1. Service Mesh is the last piece of Kubernetes's jigsaw puzzle supporting micro-service capabilities.

In the previous article on why kubernetes is naturally suitable for micro-services, we mentioned that Kubernetes is a strange place, its components are complex, the concept is complex, before the implementation of micro-services, you may wonder why Kubernetes design is so complex, but once you want to implement micro-services, you will find all the concepts in Kubernetes useful.

In our microservice design is a key point, we will find that Kubernetes can have the corresponding components and concepts, provide the corresponding support.

The last piece of the puzzle is service discovery, with circuit breaker current-limiting downgrade.

As we all know, the service discovery of Kubernetes is realized through Service, and the forwarding between services is realized through iptables rules issued by kube-proxy, which can only achieve the most basic service discovery and forwarding capabilities, and can not meet the advanced service features of highly concurrent applications. There is a certain gap between SpringCloud and Dubbo, so Service Mesh was born. He expects to talk about circuit breakers, current limiting, degradation and other features, from the application layer. Sink to the infrastructure layer to implement it, allowing Kubernetes and containers to take over the microservices.

2. Take Istio as an example to describe the key technical points in Service Mesh.

Just like SDN, Service Mesh divides the forwarding of service requests into the control plane and the data plane, so to analyze him is to first analyze the forwarding ability from the data side, and then analyze how the control plane issues commands. Today's article focuses on two components, Envoy and Pilot

It all started with Envoy.

First of all, let's look at what can be done without being integrated into Service Mesh,Envoy itself.

Envoy is a high-performance proxy transponder written by C++, so how does Envoy forward requests? You need to set some rules and forward them according to them.

Rules can be static, placed in the configuration file, loaded at startup, and generally need to be restarted in order to reload, but Envoy supports hot loading and hot restart, which alleviates this problem to some extent.

Of course, the best way is to set the rules to dynamic and maintain them in a unified place. In the eyes of Envoy, this unified place is called Discovery Service. After a period of time, you can pick up the configuration here and modify the forwarding policy.

Whether static or dynamic, four things are often configured in the configuration.

First, listener, that is, since envoy is a proxy and specializes in forwarding, it has to listen to a port and access requests before it can be forwarded according to the policy. This listening port is called listener.

The second is endpoint, which is the ip address and port of the destination, which is where the proxy eventually forwards the request.

The third is cluster. A cluster is multiple endpoint with exactly the same behavior, that is, if there are three containers running, there will be three IP and ports, but the same three services are deployed. They form a Cluster. The process from cluster to endpoint is called load balancing, which can be polled.

Fourth, route, sometimes multiple cluster have similar functions, but with different version numbers, you can choose to route the request to a certain version number, that is, a certain cluster, through route rules.

Examples of static configurations for these four are as follows:

As shown in the figure, listener is configured to listen on the local interface 10000 of 127.0.0.1, and route is configured to configure load balancing policy in which cluster,cluster the prefix of a url is forwarded to. There are all endpoint in hosts.

If you want to simply use envoy, do not need any service mesh, a process, plus this configuration file, can be used to forward the request.

For dynamic configuration, you should also configure the Discovery Center, that is, Discovery Service. For the above four configurations, each corresponds to the corresponding DS, so there are LDS, RDS, CDS, EDS.

Examples of dynamic configuration are as follows:

The working mode of the control plane Pilot

Envoy on the data side can be run by installing static configuration files, while dynamic information needs to be obtained from Discovery Service.

Discovery Service is deployed on the control plane, and in istio, it is Pilot.

As shown in the figure of Pilot architecture, the bottom layer is the API of envoy, which is the API that provides Discovery Service. The rules of this API are determined by envoy, but instead of Pilot calling Envoy, Envoy actively calls the API of Pilot.

The top layer of Pilot is called Platform Adapter. What is this layer for? This layer is not Kubernetes, where Mesos calls Pilot, but Pilot discovers the relationship between services by calling Kubernetes.

This is a point around understanding Istio. That is, pilot uses Kubernetes's Service and only uses its service discovery function instead of its forwarding function. Pilot listens for events by registering a controller in kubernetes to obtain the Endpoint and Pod relationship between Service and Kubernetes, but at the forwarding level, it will no longer use kube-proxy to forward according to the iptables rules issued by service. Instead, these mapping relationships will be transformed into pilot's own forwarding model and sent to envoy for forwarding. Envoy does not use kube-proxy 's iptables rules. This completely separates the control plane from the data plane, and the interrelationship between services is a matter of management, not tied to the actual forwarding, but around the back of the pilot.

Another external interface of Pilot is Rules API, which is an interface for administrators. Administrators set some rules through this interface, these rules are often applied to Routes, Clusters, and Endpoints, and which Clusters and Endpoints are found by Platform Adapter through services.

The automatic discovery of these Clusters and Endpoints, coupled with the rules set by the administrator, forms the data model of Pilot, which is actually a series of data structures defined by himself, and then exposed through envoy API, waiting for envoy to pull these rules.

A common manual rule is Routes. Through service discovery, Pilot can know from Kubernetes that there are two versions of Service B, usually two Deployment belonging to the same Service. The administrator calls the Rules API of Pilot to set the Route rules between the two versions, one accounting for 99% of the traffic and one accounting for 1% of the traffic. These two aspects of information form the data structure model of Pilot, and then send it through Envoy API. Envoy will set the forwarding policy according to this rule.

Another common scenario is load balancing. Pilot finds that Service B contains one Deployment but has three replicas through Kubernetes's Service, so it issues rules through Envoy API to make Envoy load balance among the three replicas, rather than through the load balancing mechanism of Kubernetes's own Service.

Third, take Istio as an example to analyze the technical details of Service Mesh

After getting a general idea of how Service Mesh works, let's parse the technical details with an example.

All students who have tried Istio should have tried the following example of BookInfo, which is not very complicated, but the sparrow has all kinds of organs.

In this example, we focus on the ProductPage service, the invocation of the Reviews service, which involves routing policy and load balancing.

Productpage is a Python program.

Productpage is a simple program written in python that provides restful API.

There are a lot of route defined in it to receive API requests and do corresponding operations.

When you need to request other services, such as reviews or ratings, you need to make a restful call to the rear.

As can be seen from the code, productpage's calls to the backend are all through the domain name.

As far as the productpage program is concerned, he thinks it is very simple and can be called through this domain name. He does not need to obtain the domain name through the service discovery system, nor does he need to care about forwarding, let alone realize that he is deployed on kubernetes and whether he uses service mesh or not, so the communication between services is completely handed over to the infrastructure layer.

Orchestrating productpage through Kubernetes

With the productpage program, the next step is to deploy it to kubernetes, nothing special here, using kubernetes's default orchestration file.

First a Deployment is defined, using a container image of bookinfo, and then a Service is defined for service discovery of this Deployment.

Orchestrating reviews through Kubernetes

This is a little more complicated, defining three Deployment, but the version numbers are V1, V2, and V3, but the label is all app: reviews.

Finally, a Service is defined, and the corresponding label is app: reviews as the service discovery of the three Deployment.

One of the customizations of productpage by istioctl: embedding proxy_init as InitContainer so far, everything has been fine, and then it's time to witness miracles, that is, istio has a tool istioctl that can customize yaml files.

The first item of customization is to add an initContainer, this type of container can do some initialization work, after a successful exit, kubernetes will not keep it running for a long time.

What do you do in this InitContainer?

We logged in and found that we had run a shell script in this InitContainer.

It is this shell script that writes a large number of iptables rules in the container.

The first rule defined is the ISTIO_REDIRECT forwarding chain, which forwards network packets to port 15000 of envoy.

But at first this chain was not linked to the default chains of iptables, so it didn't work.

The next step is in the PREROUTING rule, using this forwarding chain, all traffic entering the container is first forwarded to port 15000 of envoy.

Envoy, as an agent, has been configured to forward the request to the productpage program.

When a productpage program receives a request, it turns to an external reviews or ratings. From the above analysis, we know that productpage is just a normal domain name call.

When productpage makes a call to the backend, it encounters the output chain, which uses the forwarding chain to forward all requests out of the container to port 15000 of envoy.

In this way, both incoming and outgoing traffic is made into hamburgers with envoy.

Envoy knows how to access reviews or ratings based on the configuration of service discovery, so it makes the final external call.

At this time, the iptables rule will make a special treatment for the traffic coming out of the envoy, allowing it to send it out and no longer use the above output rule.

The second part of customizing productpage by istioctl: embedding proxy container as sidecar

The second customization that istioctl does is to embed the proxy container as sidecar.

This may seem more complex, but when we enter the container, we can see that two processes are started.

One is the familiar envoy. He has a configuration file called / etc/istio/proxy/envoy-rev0.json.

As we said earlier when we talked about envoy, with the configuration file, envoy can be forwarded. Let's take a look at what's in the configuration file.

The management port of envoy is configured in this port. We will use this port to see which forwarding policies envoy has been sent by pilot.

Then there are dynamic resources, that is, to get forwarding strategies from various discovery service.

There are static resources, that is, statically configured, that need to be restarted to load.

This is the role of pilot-agent, he is a simple manager of envoy, because there are some static resources, if TLS's certificate, envoy does not support dynamic issuance, so it needs to be reconfigured statically, and then pilot-agent is responsible for hot restart loading of envoy.

Fortunately, envoy has a good hot restart mechanism. When restarting, a standby process will be started first, and the forwarded statistics will be shared between the two processes through shared memory.

In-depth analysis of the working mechanism of pilot

The working mechanism of Pilot is shown in the figure.

Istio config is a forwarding rule issued by an administrator through the management interface.

For Kubernetes, the Service Discovery module creates a controller to listen to the events created and deleted by Service. When there is a change in service, it will notify pilot,pilot that it will update the rules sent to envoy according to the change.

Pilot changes the current state of forwarding policy configuration and service discovery entered by the administrator into pilot's own data structure model, and then exposes it to envoy's api. Because it is called by envoy, it is necessary to implement a server, where there are lds, rds, cds, and eds.

Let's see what happens after we configure route on pilot.

As shown in the figure, we send all traffic to version 1.

When we look at the management port of envoy, we can see that only reviews is configured for v1.

When we modify the route to v1 and v3, the ratio is 50 to 50.

You can see the management port of envoy, and the routing has two versions of the configuration, which also corresponds to the two ip addresses at the back end.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.