Working principle of envy of istio I

I'm learning istio Let's first understand the two terms service grid (Service Mesh) and sidecar.
Service Grid (Service Mesh)： It is used to describe the micro service network that constitutes these applications and the interaction between applications . Its needs include service discovery 、 Load balancing 、 Fault recovery 、 Indicator collection and monitoring, etc . Or more complex operation and maintenance requirements , for example A/B test 、 Release of canary 、 Current limiting 、 Access control and end-to-end authentication . The service grid is shown in the following figure

SideCar： Dividing the functions of an application into separate processes can be considered Sidecar Pattern .Sidecar Mode allows you to add more functionality next to your application , Without the need for additional third-party components to configure or modify the application code . It's like connecting Sidecar Like a three wheeled motorcycle , In software architecture , Sidecar Connect to the parent application and add extensions or enhancements to it .Sidecar The application is loosely coupled with the main application . It can shield the differences between different programming languages , Unified implementation of observability of microservices 、 monitor 、 logging 、 To configure 、 Circuit breaker and other functions .sidecar As shown in the figure below

To realize service grid management , There are several tools that can support , As shown in the figure below , Green indicates the outstanding ability supported in horizontal comparison .

Why choose istio Well ？istio The main advantages are as follows ：

• Support HTTP、gRPC、WebSocket and TCP Automatic load balancing of traffic .
• Provide rich routing rules 、 retry 、 Fail over 、 Fault injection capability , It can control the fine particle size of the flow .
• Automatic index measurement of all flows in and out of the cluster entrance and exit 、 Logging and tracking .
• Provide powerful authentication and authorization based capabilities , Realize the communication security between services in the cluster .

Istio The three core features of are traffic management 、 Security 、 Observability .

Traffic management ：Istio Simple rule configuration and traffic routing allow you to control traffic and API Call the process .Istio Simplified service level attributes （ Such as fuse 、 Timeout and retrying ） Configuration of , And make it easy to perform important tasks （ Such as A/B test 、 Canary releases and phased releases by percentage of traffic ）.

Security ：Istio Liberated developers , Make it just focus on application level security .Istio Provides the underlying security communication channel , And manage authentication for large-scale service communication 、 Authorization and encryption . With Istio, Service communication is protected by default , Enables you to implement consistent policies across different protocols and runtimes —— And all of this requires little or no application modification .Istio It's platform independent , It can be done with Kubernetes（ Or infrastructure ） The network strategy is used together . But it's more powerful , Be able to protect at the network and application level pod To pod Or service to service communication .

Observable ：Istio Robust tracking 、 Monitoring and logging features give you an in-depth understanding of service grid deployment .
indicators ：istio be based on 4 Gold indicators for monitoring （ Delay 、 Traffic 、 error 、 saturated ） Generate a series of service indicators .
Distributed tracking ：istio Generate distributed tracking for each service span, The operation and maintenance personnel can obtain the dependency and call process of services in the grid .
Access log ： All requests that flow into the grid service ,istio Generate a complete record of each request , Include source 、 Target metadata .

istio Including data plane and control plane , The data plane consists of a set of sidecar Smart agents deployed in (Envoy) form , These agents can regulate and control microservices and Mixer All network communications between . The control plane is responsible for managing and configuring agent traffic , In addition, control plane configuration Mixer To implement strategies and collect telemetry data . among Envoy Is a very critical component , Mainstream 7 Layer agents are supported by a variety of tools , The details are as follows ：

What then? Istio Will choose Envoy As a data plane ？ Mainly because Envoy It has the following advantages ：

performance ：Envoy When providing very high throughput and low tail delay difference ,CPU and RAm Consumption is relatively small .
Scalable ：Envoy stay L4 and L7 Both provide rich pluggable filtering capabilities , Users can easily add capabilities that are not available in the open source version .
API Configurable ：Envoy It provides a set of management that can be realized through control platform services API, Thus making Envoy You can refresh the configuration without restarting .
in addition ,Envoy Adopt single process multithreading mode , Suggest Envoy Configured worker Quantity and Envoy The number of hardware threads is the same . It says Envoy Theoretical knowledge of , So let's see Envoy Configuration of .static_resource Here are three key configurations ,listener,route_config,cluster here Listener monitor 10000 Port number ,route The configuration is if the request is “/” So sent targetCluster To deal with ( We need to pay attention to ：Envoy in cluster The concept of is a group IP A collection of addresses )

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
                - "*"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: targetCluster
          http_filters:
          - name: envoy.router

Then we need to define cluster Information about , The template is shown below

clusters:
- name: targetCluster
  connect_timeout: 0.25s
  type: STRICT_DNS
  dns_lookup_family: V4_ONLY
  lb_policy: ROUND_ROBIN
  hosts: [
    { socket_address: { address: 172.17.0.3, port_value: 80 }},
    { socket_address: { address: 172.17.0.4, port_value: 80 }}
  ]

Introduction after Envoy After configuration , Next, let's take a look at a practical example Envoy Working process of . First, deploy a simple Service for .

apiVersion: apps/v1
kind: Deployment
metadata:
  name: simple
spec:
  replicas: 1
  selector:
    matchLabels:
      app: simple
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "80"
      labels:
        app: simple
    spec:
      containers:
        - name: simple
          imagePullPolicy: Always
          image: cncamp/httpserver:v1.0-metrics
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: simple
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: simple

Envoy Serving oneself Deployment yaml file , Let Envoy Service startup . Pod Load static at startup Envoy Profile information , The configuration file information passes configmap In the form of mount To /etc/envoy Under the table of contents .

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: envoy
  name: envoy
spec:
  replicas: 1
  selector:
    matchLabels:
      run: envoy
  template:
    metadata:
      labels:
        run: envoy
    spec:
      containers:
        - image: envoyproxy/envoy-dev
          name: envoy
          volumeMounts:
            - name: envoy-config
              mountPath: "/etc/envoy"
              readOnly: true
      volumes:
        - name: envoy-config
          configMap:
            name: envoy-config

Here is Envoy Configuration information , In the configuration information routes The definition is also “/”,cluster Of address yes simple, That is, when a request is sent to Envoy Of 10000 Port time , Requested URL contain “/”, The request is forwarded to simple This service Handle . That's what we created above service.Envoy The configuration information of is stored in ConfigMap in .

kubectl create configmap envoy-config --from-file=envoy-config.yaml

admin:
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address: { address: 0.0.0.0, port_value: 10000 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: AUTO
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: ["*"]
                      routes:
                        - match: { prefix: "/" }
                          route: { cluster: some_service }
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
    - name: some_service
      connect_timeout: 0.25s
      type: LOGICAL_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: some_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: simple
                      port_value: 80

After creation , You can see envoy Of pod Successful startup , Visit at this time envoy pod Of IP Address +10000 port , And access simple service The result is the same , Explain that when the request is sent envoy,envoy according to route Configure to forward requests to subsequent services for processing . The results are shown in the following figure , Starting up envoy pod Of ip The address is 10.20.1.119, Access to ip Address of the 1000 port , Requested URL yes /hello, The request response information is returned , This response information and direct access simple service The result is the same .

The above example demonstrates that if you pass envoy Complete the process of forwarding requests by agents , More about envoy The configuration description of can be viewed Official website information .