Gateway and VirtualService configurations in the Istio Gateway are deeply parsed

Where do all the requests go?

Through the learning and practice of the previous several articles, we have a preliminary understanding of the concepts and principles of Gateway, VirtualService and Destinationrule. This chapter will conduct in-depth analysis of the configuration files of these object resources. The details will drill down to how each configuration item maps to the Envoy configuration.

Before we start, we need to figure out who gets to handle the object resources we create, and the person responsible for handling those resources is Pilot.

1.Overall Architecture of Pilot

First of all, let’s review the overall architecture of pilot. The above is the official architecture diagram of pilot. Because it is in the old_pilot_repo directory, it may differ from the latest architecture. The so-called Pilot consists of two components: Pilot-Agent and pilot-Discovery. The agent in the diagram corresponds to the Pilot-Agent binary, the proxy to the Envoy binary, they’re both in the same container, the Discovery Service corresponds to the Pilot-Discovery binary, In a separate Deployment that is deployed separately from the application.

discovery service: From Kubernetes Apiserver List/Watchservice,endpoint,pod,nodeListen for ISTIO control plane configuration information (such as VirtualService, DestinationRule, etc.) and translate it into configuration formats that can be understood directly by Envoy.
Proxy: Envoy that connects directly to the Discovery Service and indirectly retrieves registrations of microservices in a cluster from service registries such as Kubernetes.
Agent: Generates an Envoy profile to manage the Envoy life cycle.
Service A/B: The incoming and outgoing network traffic of Istio applications, such as Service A/B, is taken over by the proxy.

To put it simply, Istio, as a management side, brings together configuration center and service center functions and provides configuration discovery and service discovery as a unified set of xDS interfaces. The data side Envoy retrives information needed for inter-service communication and service governance through xDS.

2.Pilot – Discovery’s XDS service for Envoy

The so-called XDS

Pilot-discovery provides control information services for data surfaces (Envoy and other proxy components running in sidecar), known as Discovery Services or XDS services. Here x is a pronoun, similar to XaaS in cloud computing, which can refer to IaaS, PaaS, SaaS, etc. In Istio, XDS includes cluster Discovery Service (CDS), Listener Discovery Service (LDS), Route Discovery Service (RDS), and ENDPOINT (EDS) And aggregated Discovery Service (ADS), aggregated discovery Service (ADS), is a unified encapsulation of these services.

Detailed descriptions and implementation details of cluster, endpoint, route, and other concepts can be found in the Data Plane API promoted by Envoy in the community (github.com/envoyproxy/…). , here is a brief introduction:

Endpoint: a specific “application instance” corresponding to an IP address and port number, similar to a Pod in Kubernetes.
clusterA:clusterIs an “application cluster” that corresponds to one or more of the same servicesendpoint. Cluster is similar to KubernetesServiceA Kubernetes Service corresponds to one or more pods that start with the same image and provide the same Service.
route: When we do grayscale publishing, canary publishing, the same service will run multiple versions at the same time, each version corresponds to a cluster. You need to go throughrouteRules dictate how requests are routed to one of the versions of the cluster.

So all of this is actually configuration information for proxies like Envoy, The so-called cluster Discovery Service, route Discovery Service and other XXX discovery services are dynamically retrieved from the pilot- Discovery Envoy Protocol and implementation of configuration information, such as endpoint and Cluster. The reason for dynamic configuration loading is to use istioctl and other tools to configure the Service mesh in a unified and flexible manner. How to view XDS information through istioctl is explained in more detail below.

The reason why ADS is used to “aggregate” a series of XDS is not just to realize multiple XDS on the same gRPC connection to save several network connections. Ads also plays a very important role in solving the problem of the order dependence of INFORMATION update of CDS and RDS, so as to ensure the synchronization of various configuration information in a certain order. A discussion of this can be seen on the Envoy’s website.

How do I view XDS

Pilot-discovery init various modules in turn during initialization, where the Discovery Service is the xDS related implementation. The ENVOY API Reference contains two versions of the V1 and v2 API documents. The Envoy Control plane gives the data structure and interface related to the V2 GRPC interface.

So how do you view XDS information? V2 is the GRPC interface, but the Pilot provides InitDebug. You can use the debug interface to query service and routes information and configuration information.

Check the eds

Service istio-Pilot Cluster IP

$ export PILOT_SVC_IP=$(kubectl -n istio-system get svc istio-pilot -o go-template='{{.spec.clusterIP}}')
Copy the code

Then look at EDS:

$ curl http://$PILOT_SVC_IP:8080/debug/edsz
Copy the code

[{
    "clusterName": "outbound|9080||reviews.nino.svc.cluster.local"."endpoints": [{
        "lbEndpoints": [{
            "endpoint": {
                "address": {
                    "socketAddress": {
                        "address": "10.244.0.56"."portValue": 9080}}}}, {"endpoint": {
                "address": {
                    "socketAddress": {
                        "address": "10.244.0.58"."portValue": 9080}}}}, {"endpoint": {
                "address": {
                    "socketAddress": {
                        "address": "10.244.2.25"."portValue": 9080}}}}]}]}, {"clusterName": "outbound|9080|v3|reviews.nino.svc.cluster.local"."endpoints": [{
        "lbEndpoints": [{
            "endpoint": {
                "address": {
                    "socketAddress": {
                        "address": "10.244.0.58"."portValue": 9080}}}}]}]}]Copy the code

Check the CDS

$ curl http://$PILOT_SVC_IP:8080/debug/cdsz
Copy the code

[{"node": "Sidecars 172.30.104.45 ~ ~ fortio - deploy - 56 dcc85457 - b2pkc. Default to the default. The SVC. The cluster. The local - 10"."addr": "172.30.104.45:43876"."connect": "2018-08-07 06:31:08.161483005 +0000 UTC m=+ 1"."Clusters": [{"name": "outbound|9080||details.default.svc.cluster.local"."type": "EDS"."edsClusterConfig": {
    "edsConfig": {
      "ads": {}},"serviceName": "outbound|9080||details.default.svc.cluster.local"
  },
  "connectTimeout": "1.000 s"."circuitBreakers": {
    "thresholds": [{}]}},... {"name": "outbound|9090||prometheus-k8s.monitoring.svc.cluster.local"."type": "EDS"."edsClusterConfig": {
    "edsConfig": {
      "ads": {}},"serviceName": "outbound|9090||prometheus-k8s.monitoring.svc.cluster.local"
  },
  "connectTimeout": "1.000 s"."circuitBreakers": {
    "thresholds": [{}]}}, {"name": "BlackHoleCluster"."connectTimeout": "5.000 s"}}]]Copy the code

Look at the ads

$ curl http://$PILOT_SVC_IP:8080/debug/adsz
Copy the code

3.Review of basic terms Envoy

To make this a little bit easier to understand, let’s review some of the basic terms Envoy.

Listener: A Listener is a Listener of a service (program) that actually does the work. It is a named network location (for example, port, Unix domain socket, and so on) that can be connected by downstream clients. Envoy exposes listeners connected to one or more downstream hosts. Typically each host runs an Envoy, using a single process, but any number of listeners can be launched in each process. Currently, only TCP is listened on, and each Listener is configured with a number of network filters (L3/L4) independently. The Listenter can also be obtained dynamically through the Listener Discovery Service (LDS).
Listener Filter: The Listener uses the Listener filter to manipulate the linked metadata. Its role is to add more integration functionality without changing Envoy’s core functionality. The Listener Filter API is relatively simple, because the filters end up running on the newly accepted socket. Links can be made in chains to support more complex scenarios, such as call rate limiting. Envoy already contains multiple listener filters.
Http Route Table: Http routing rules, such as the requested domain name, rules that Path complies with, and which Cluster to forward to.
Cluster: A Cluster is a logically similar set of upstream hosts connected to an Envoy. Envoy finds members of a cluster through service discovery. Envoy can use active health checks to determine the health of cluster members. How the Envoy routes requests to the cluster members is determined by load balancing policies.

For more details, see the architecture and basic terms Envoy. This article highlights the three basic terms Listener, Route, and Cluster. Note the order in which traffic passes through these terms. The Http Route Table is then used to go to the specific Cluster, which finally responds to the request.

4.Gateway and VirtualService configuration resolution

Using the example from the Istio traffic Management article, we created a Gateway with the following configuration file:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
Copy the code

Then create a VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080
Copy the code

VirtualService maps Http Route Table Envoy. Notice that a Gateway field exists in the VirtualService configuration file. The Http Route Table is bound to the Listener of ingressGateway. The absence of this field indicates that the Http Route Table is tied to the Pod of all microservice applications managed by Istio.

In order to prioritize, I have decided to split this article into two articles. This article focuses on parsing Gateway and VirtualService around ingressGateway. The VirtualService and DestinationRule parsing of the microservice application itself will be discussed in the next article.

VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService: VirtualService Debug Envoy and Pilot.

First look at the Listener configuration item:

$ istioctl -n istio-system pc listeners istio-ingressgateway-b6db8c46f-qcfks --port 80 -o json
Copy the code

[{" name ":" 0.0.0.0 _80 ", "address" : {" socketAddress ": {" address" : "0.0.0.0", "portValue" : 80}}, "filterChains" : [ { "filters": [ { "name": "envoy.http_connection_manager", "config": { ... "rds": { "config_source": { "ads": {} }, "route_config_name": "http.80" }, ... } } ] } ] } ]Copy the code

The name of the Http Route Table used by the Listener is HTTP.80 based on the RDS configuration item route_config_name.

Viewing Http Route Table configuration items:

$ istioctl -n istio-system pc routes istio-ingressgateway-b6db8c46f-qcfks --name http.80 -o json
Copy the code

[ { "name": "http.80", "virtualHosts": [ { "name": "bookinfo:80", "domains": [ "*" ], "routes": [ { "match": { "path": "/productpage" }, "route": { "cluster": "outbound|9080||productpage.default.svc.cluster.local", "timeout": "S" 0.000, "maxGrpcTimeout" : "0.000 s"}, {...},... "match" : {" prefix ":"/API/v1 / products "}, "route" : {" cluster ": "Outbound | 9080 | | productpage. Default. SVC. The cluster. The local", "timeout" : "0.000 s", "maxGrpcTimeout" : "0.000 s"},...},...]}], "validateClusters" : false}]Copy the code

In the VirtualServicehostsField in Http Route TablevirtualHostsThe configuration itemsdomainsField. This means that any domain name can be used to access the service through ingressGateway (or directly through IP).
In the VirtualServiceexactField in Http Route Tableroutes.matchThe configuration itemspathField.
In the VirtualServiceprefixField in Http Route Tableroutes.matchThe configuration itemsprefixField.
In the VirtualServiceroute.destinationThe configuration item is in the Http Route Tableroutes.routeThe configuration itemsclusterField.

For information on HTTP route parsing in Envoy see my previous article: HTTP Route parsing.

View Cluster configuration items:

$ istioctl -n istio-system pc clusters istio-ingressgateway-b6db8c46f-qcfks --fqdn productpage.default.svc.cluster.local  --port 9080 -o jsonCopy the code

[{"name": "outbound|9080||productpage.default.svc.cluster.local"."type": "EDS"."edsClusterConfig": {
            "edsConfig": {
                "ads": {}},"serviceName": "outbound|9080||productpage.default.svc.cluster.local"
        },
        "connectTimeout": "1.000 s"."circuitBreakers": {
            "thresholds": [{}]}}]Copy the code

As you can see, the Cluster eventually forwards requests from outside the Cluster via ingressGateway to the actual endpoint, This is the Pod (specified by the serviceName field) under Service ProductPage in the Kubernetes cluster.

Istioctl uses the PILOT’s XDS interface to view Listener, Route, and Cluster information.

Ok, now that the request has been forwarded to ProductPage, how will the request complete its journey? Join us next time!

5.reference

Service Mesh deep learning series (3) | istio pilot – discovery module analysis of source code analysis (in the)
Debug Envoy and Pilot
Envoy’s architecture and basic terminology

Gateway and VirtualService configurations in the Istio Gateway are deeply parsed

1.Overall Architecture of Pilot

2.Pilot – Discovery’s XDS service for Envoy

The so-called XDS

How do I view XDS

3.Review of basic terms Envoy

4.Gateway and VirtualService configuration resolution

5.reference

Related Posts

Java Advanced Features – Reflection: How can you create new objects without dying in code?

Lu Qi’s strategy: Xiaomi + Baidu, but can Lei Jun and Li Yanhong work closely together?

Python self-study tutorial | 30000 word explanation every important knowledge for you