This article is shared from Huawei Cloud Community " Introduction to istio resources and reversing the relationship with kubernetes resources ". The author: You can make friends.

1. Istio principle

The principle of Istio is to intercept the event of creating a Pod in Kubernetes, and then inject a container containing Envoy into the Pod. The traffic in and out of the Pod will be "hijacked" to Envoy for processing. Since the traffic is "hijacked", Istio can analyze the traffic, such as collecting request information, perform a series of traffic management operations, and verify authorization information. After Envoy intercepts the traffic and performs a series of operations, if the request is OK, it will forward the traffic to the Pod of the business application.

2. istio architecture

The architecture of istio is divided into control plane, data plane, and entrance and exit gateways.

Control plane: The control plane is istiod, which is deployed in the istio-system namespace by default. Entering the istiod container you can see that the name of the main process is pilot. So we can know that the main body of the control plane is pilot, and other components, such as citadel Galley, are started by pilot management. As the core of the istio control plane, pilot has two main responsibilities: 1) Monitor the k8s platform to obtain resource information such as svc, endpoint, virtualservice, gateway, destinationrule, etc. This information must be relied upon for traffic forwarding; 2) Put the obtained information Abstract aggregation is generated into a configuration structure that Envoy can recognize, and finally the configuration is delivered to the data plane Envoy through the xds protocol. Envoy has created a set of protocols for Envoy to dynamically deliver configurations and take effect hot, collectively called xds. The xds server is implemented in pilot, and the aggregated and converted configuration information is sent to envoy on the data plane to achieve hot validation of traffic policies.
Data plane: After installing istio, you need to perform the following operations to automatically inject the data plane.

#Automatically inject the entire namespace:
kubectl label namespace default istio-injection=enabled
#Automatic injection of a single workload:
Add annotation sidecar.istio.io/inject=true

After automatic injection is turned on, istio will inject sidecar containers into the pod. One is the initcontainer that modifies the iptables in the pod, and the other is the istio data plane istio-proxy. Enter istio-proxy and you can see that the name of the main process is pilot-agent. Envoy is started and managed by pilot-agent in the form of a child process. Pilot-agent has two responsibilities: 1) pilot-agent will interact with pilot, and the xds request issued by pilot is received by pilot-agent; 2) start the management envoy process, and perform hot update of envoy according to the received configuration .

Entry and exit gateway: istio-ingressgateway Like the sidecar in the grid, the core processing component is also an envoy. It serves as the entrance to the grid and allows services to access services inside the service grid from outside the grid, playing a role similar to nginx-ingress .

The main functions of istio-ingressgateway include the following functions: 1) Receive traffic outside the cluster and route requests to appropriate internal services (acting as a gateway) according to Istio configuration; 2) Load balancing and traffic control functions, including request routing , retry, timeout, circuit breaker, etc. (traffic management); 3) Support TLS configuration to encrypt traffic before entering the service grid (configure a certificate for the domain name); 4) Support two-way TLS authentication to improve the service grid Security (inter-service communication); 5) Provide Metrics, Tracing and Logging collection to better observe and monitor traffic (you need to install the corresponding components yourself)

3. Commonly used CRD resources in istio

3.1 gateway

In istio, the resource that defines the binding relationship between "monitoring information and entry gateway" is called Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-test
spec:
  selector:    
    istio: ingressgateway # Select the effective ingress gateway based on the label
  servers:
    - port: # Listening port
        number: 8080
        name: http
        protocol: HTTP # Protocol for receiving requests
      hosts:
        - "*" # Domain name to receive requests

3.2 virtualService

Mainly provided: 1) Routing function: declare a backend service and the routing information of this backend service; 2) Traffic control: mirror traffic, fault injection, cross-domain configuration, etc.; 3) Bind gateway: through the spec.gateways field Bind the gateway, and the routing rules and traffic control rules will take effect on the gateway; 4) Bind the backend: the spec.http.route.destination field declares the forwarding address of each route.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-virtualservice
  namespace: istio-test
spec:
  hosts:
  - "*"
  gateways:
  - my-gateway ## virtualservice associated gateway
  http:
  - name: "nginx-v1-routes"
    match: ## Routing rules, matching based on uri
    - uri:
        prefix: "/aaa"          
    - uri:
        prefix: "/"
    route:
    - destination: ## virtualservice associated destinationrule
        host: nginx.istio-test.svc.cluster.local    
        subset: v1 ## subset.name associated with destinationRule

Precautions:

Spec.http.route.destination.host try to use FQDN (fully qualified domain name)
URI matching is case sensitive
The url matching order of istio vs is from top to bottom, not the longest match. In a production environment, it is recommended to use an unconditional rule as the last rule to ensure that traffic will always match at least one rule to prevent unexpected situations.
When creating a second or more VirtualService for an existing host, istio will merge additional routing rules into the existing configuration of the host. This merging does not guarantee the matching sequence and may cause inconsistency with the expected matching effect. Therefore, it is recommended that the routing configuration of a host be written in a virtualService.yaml file.

3.3 destinationRule

Through the spec.http.route.destination field of VistualService, VistualService and DestinationRule form a binding relationship.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination
  namespace: istio-test
spec:
  host: mynginx.istio-test.svc.cluster.local ## kuberntes internal FQDN domain name, associated with a kubernetes service
  subsets:
  - name: v1
    labels: ##Category pods based on labels, often used in grayscale release scenarios
      version: v1    
  - name: v2
    labels:
      version: v2

DestinationRule main functions:

Load function: Select one from the service endpoint list in the host field to become the real backend that handles this request. There are methods such as polling, consistent hashing, minimum number of connections, location load balancing, etc.
Connection pool: Limit the number of connections to back-end services.
Abnormal point detection: perform health detection on back-end services and kick out abnormal back-end points from the load.
Define subset versions: classify endpoints by label.

4. The relationship between istio resources and kubernetes resources

Istio service grid, its main management object is of course service, that is, service in kubernetes. The istio control plane pilot contains informer to obtain the service, endpoint, and pod resource information in the kubernetes cluster, and convert it into envoy's cluster and endpoint configuration and deliver it to the data plane. In most cases, we can understand envoy cluster as a service in the K8s cluster. A service usually corresponds to a group of pods. The cluster in envoy is also a collection of the same backend.

4.1 Reverse relationship diagram between istio CRD resources and kubernetes resources

The destinationRule of istio defines a set of load balancing backend service addresses, and associates the service in the kubernetes cluster through the spec.host field to obtain the backend address list endpoint in kubernetes. Istio's destinationRule can also filter specific pods from the service by associating pod-label, which is often used for grayscale publishing. The essence of istio-ingressgateway is a deployment deployed in the istio-system namespace, running the envoy process container. We generally need to manually create a kubernetes-service of the LoadBalacne type so that it can obtain an external IP.

4.2 istio needs to obtain the service agreement through kubernetes service port information

istio needs to know what seven-layer protocols the service provides so that it can configure the filter chain of the corresponding protocol. Officially, it is recommended to explicitly declare the protocol. If there is no declaration, istio will automatically detect it, but this detection capability is relatively limited (it can only detect and identify the http https http2 protocol), which may cause it to not work properly.

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 8080
    name: rpc
    appProtocol: grpc # The first type: Specify the port to provide grpc protocol services
  - number: 80    
    name: http-web # The second method: Name the port with the protocol name prefix, and declare that port 80 provides http protocol services

5. Istio common resource operations and relationship display

5.1 Create deployment and service resources

kind: Deployment
apiVersion: apps/v1
metadata:
  name: mynginx
  namespace: istio-test
  labels:
    appgroup: ''
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mynginx
      version: v1
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: mynginx
        version: v1
    spec:
      containers:
        - name: container-1
          image: nginx:1.17.4
          resources:
            limits:
              cpu: 250m
              memory: 512Mi
            requests:
              cpu: 250m
              memory: 512Mi
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
      dnsPolicy: ClusterFirst
      imagePullSecrets:
        - name: default-secret
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: istio-test
  labels:
    app: mynginx
    version: v1
spec:
  ports:
    - name: http-nginx
      port: 80
      targetPort: 80
  selector:
    app: mynginx
    version: v1
  type: ClusterIP