istio architecture and concepts

istio features

Traffic management

Istio's simple rule configuration and traffic routing allow you to control the traffic between services and the process of API calls. Istio simplifies the configuration of service-level attributes (such as fuses, timeouts, and retries) and makes it easy to perform important tasks (such as A/B testing, canary releases, and grayscale releases).

Safety

The security features of istio free developers to focus on application-level security. Istio provides the underlying secure communication channel and manages authentication, authorization, and encryption for large-scale service communication. With Istio, service communication is protected by default, allowing you to implement consistent policies across different protocols and runtimes—all of which require little or no application modification.

Istio is platform independent and can be used with Kubernetes (or infrastructure) network policies. But it is more powerful and can protect pod-to-pod or service-to-service communication at the network and application level.

Observability

Istio's robust tracking, monitoring, and logging features give you in-depth understanding of service mesh deployment. Through Istio's monitoring capabilities, you can truly understand how the performance of the service affects upstream and downstream; and its customized Dashboard provides the ability to visualize the performance of all services and let you see how it affects other processes.

Scalability

WebAssembly is a sandbox technology that can be used to extend the capabilities of the Istio proxy (Envoy). The Proxy-Wasm sandbox API replaces Mixer as the main extension mechanism of Istio. In Istio 1.6, a unified configuration API will be provided for the Proxy-Wasm plug-in.

istio architecture

The istio service grid is logically divided into a data plane and a control plane.

• The data plane consists of a set of intelligent proxies (Envoy), which are deployed as sidecars. These agents are responsible for coordinating and controlling all network communications between microservices. They also collect and report telemetry data for all grid traffic.
• The control plane manages and configures proxies for traffic routing.
  
  Traffic in Istio is divided into data plane traffic and control plane traffic. Data plane traffic refers to the messages sent and received by the business logic of the workload. Control plane traffic refers to the configuration and control messages sent between Istio components to orchestrate the behavior of the grid. Traffic management in Istio specifically refers to data plane traffic.

Istio only implements the servicemesh control plane, integrates Envoy as the sidecar of the data plane, and controls the flow together

Main components

• Envoy
  Istio uses an extended version of the Envoy proxy. Envoy is a high-performance proxy developed in C++ to coordinate the inbound and outbound traffic of all services in the service grid. The Envoy proxy is the only Istio component that interacts with data plane traffic.
  The Envoy proxy is deployed as the sidecar of the service, logically adding many built-in features of Envoy to the service, such as: dynamic service discovery, load balancing, TLS, HTTP/2 and gRPC proxies, fuses, health checks, and percentage-based traffic segmentation Phased release, fault injection, rich indicators

• Istiod
  Starting Istio 1.5, change packaging Istio manner, the control plane functions (Pilot, Galley, Citadel and sidecar injector) into a binary file is called istiod (formerly micro service architecture). Why eat your own dog food? See https://preliminary.istio.io/latest/zh/blog/2020/istiod/

• Mixer is
  used to extend the functionality of istio. The new version of this component is obsolete. You can now use Wasm to extend Envoy. See https://preliminary.istio.io/latest/zh/blog/2020/wasm-announce/ for details

• Pilot
  Pilot provides the Envoy sidecar with service discovery, traffic management functions for intelligent routing (for example, A/B testing, canary release, etc.), and elastic functions (timeout, retry, fuse, etc.).
  Pilot converts the advanced routing rules that control traffic behavior into environment-specific configurations and propagates them to the sidecar at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that can be used by any sidecar that conforms to the Envoy API.
  

• Citadel
  Citadel can support powerful service-to-service and end-user authentication through built-in identity and certificate management. You can use Citadel to upgrade unencrypted traffic in the service mesh.

• Galley
  Galley is the configuration verification, extraction, processing, and distribution component of Istio. It is responsible for isolating the remaining Istio components from the details of obtaining user configuration from the underlying platform (such as Kubernetes). It does not directly provide business capabilities to the data plane, but provides support to other components on the control plane. As the component responsible for configuration management, Galley verifies the correctness of the format and content of the configuration information, and provides the configuration information to the Pilot service of the control plane, so that other control plane components can only deal with Galley, thereby decoupling from the underlying platform .

• Sidecar injector
  is a component responsible for injecting into motion. As long as automatic injection is turned on, istio-sidecar-injector will be automatically called to inject the Sidecar container into the Pod when the Pod is created.
  In the Kubernetes environment, according to the automatic injection configuration, when Kube-apiserver intercepts the request created by the Pod, it will call the automatic injection service istio-sidecar-injector to generate the description of the Sidecar container and insert it into the definition of the original Pod. In addition to the business container, the created Pod also includes the Sidecar container. This injection process is transparent to users, and users create workloads in the original way. For the principle of sidecar injection, please refer to https://zhaohuabing.com/2018/05/23/istio-auto-injection-with-webhook/

Traffic management related concepts

Service discovery ensures the accessibility between services, but for the service grid, it is more important to be able to control the access between services. Essentially, it is necessary to define the access rules between services. Users only need to use the abstract resource objects provided by Istio to define the access relationships between services, without having to care about the underlying complex traffic forwarding process, and can easily implement a series of complex A/B testing, canary release, fusing, fault injection, etc. Traffic management operations.
The resource objects (k8s CRD) related to traffic management in Istio mainly include:

• Virtualservice: Used to define routing rules, such as formulating rules based on source or header, or splitting traffic between different service versions.
• DestinationRule: Define the configuration strategy and routable subset of the destination service. Strategies include circuit breakers, load balancing, and TLS.
• ServiceEntry: You can use ServiceEntry to add additional service entries to Istio, so that the grid can make requests to services outside the istio service grid.
• Gateway: Configure a gateway for the grid to allow a service to be accessed outside the grid.
• Workload: Capable of describing the attributes of a single non-Kubernetes workload, such as a VM or bare metal server, which has been loaded into the grid. WorkloadEntry must be accompanied by an Istio ServiceEntry, the Istio selects the workload and provides the service definition MESH_INTERNAL (host name, port attributes, etc.) through the appropriate label. A ServiceEntry object can select multiple workload entries and Kubernetes Pods based on the label selector specified in the service entry.
• WorkloadGroup: describes a collection of workload instances. It provides a specification that workload instances can be used to bootstrap its agents, including metadata and identity. It is designed to be used with non-k8s workloads (such as virtual machines) and imitates the existing Sidecar injection and deployment specification model for Kubernetes workloads to guide Istio agents.
• SideCar: By default, Pilot will send all services related to Envoy Sidecar's namespace, including inbound and outbound listeners, clusters, routes, etc., to Envoy. Sidecar can be used to make more fine-grained adjustments to the configuration delivered by Pilot to Envoy Sidcar, for example, only the outbound configuration of those external services that the sidecar service needs to access is delivered to it.
• EnvoyFilter: EnvoyFilter provides a mechanism for customizing the Envoy configuration generated by Istio Pilot.

Data plane related concepts

• Host: An entity capable of network communication (such as mobile devices, applications on servers). In this document, the host is a logical network application. There may be multiple hosts running on a piece of physical hardware, as long as they are independently addressable. In the EDS interface, "Endpoint" is also used to represent an application instance, corresponding to a combination of IP+Port.
• Downstream: The downstream host connects to Envoy, sends requests and receives responses.
• Upstream: The upstream host receives connections and requests from Envoy, and returns a response.
• Listener: The listener is a named network address (for example, port, unix domain socket, etc.), which can be connected by downstream clients. Envoy exposes one or more listeners to connect to downstream hosts. In Envoy, the Listener can be bound to the port to serve externally directly, or not bound to the port, but to receive requests forwarded by other listeners.
• Cluster: A cluster refers to a group of upstream hosts connected by Envoy. The hosts in the cluster are peers and provide the same services externally, forming a service cluster that can provide load balancing and high availability. Envoy discovers the members of the cluster through service discovery. You can choose to determine the health status of cluster members through active health checks. Envoy decides which cluster member to route the request to through the load balancing strategy. It can be understood that a microservice is composed of multiple instances, and these multiple instances are a Cluster.

pilot subcomponent

• The pilot-discovery
  service discovery component. Get service information from Service provider (such as kubernetes or consul), get traffic rules (K8S CRD Resource) from K8S API Server, convert service information and traffic rules into a format understandable by the data plane, and use standard data plane APIs Send to each sidecar in the grid.
• pilot-agent
  agent component. According to the configuration information in the K8S API Server, the Envoy configuration file is generated and is responsible for starting the Envoy process. Note that most of Envoy's configuration information is dynamically obtained from Pilot through the xDS interface, so the Agent generates only a small amount of static configuration used to initialize Envoy.

xDS

The Istio data plane API defines the xDS service interface through which the Pilot delivers dynamic configuration information to the data plane sidecar to control the data flow in the Mesh. The DS in xDS stands for discovery service, which means that the xDS interface uses dynamic discovery to provide configuration data required by the data plane. And x is a pronoun, which means there are multiple discover services. Envoy can dynamically obtain Listener, Route, Cluster, Endpoint, and Secret configurations through the xDS API.

• LDS (Listener Discovery Service)
  LDS is Listener Discovery Service. Listener controls Envoy to start port monitoring (currently only supports TCP protocol), and is equipped with L3/L4 layer filters. When the network connection is reached, the configured network filter stack starts to process subsequent events. This pass-monitor architecture is used to perform most different proxy tasks (current limiting, client authentication, HTTP connection management, TCP proxy, etc.).

• RDS (Route Discovery Service)
  Route discovery service, used for HTTP connection management filters to dynamically obtain routing configuration. The routing configuration includes HTTP header modification (adding or deleting HTTP header key value), virtual hosts (virtual machine), and virtual hosts definition Each routing entry.

• CDS (Cluster Discovery Service)
  Cluster discovery service is used to dynamically obtain Cluster information. The Envoy cluster manager manages all upstream clusters. In view of the fact that the upstream cluster or host can be used for any agent forwarding task, all upstream clusters are generally abstracted from Listener or Route.

• EDS (Endpoint Discovery Service)
  Endpoint Discovery Service. Endpoint is composed of ip+port. In Envoy terminology, Cluster members are called Endpoints. For each CLuster, Envoy dynamically obtains the Endpoint through the EDS API. There are two reasons why EDS is the preferred service discovery:
  Compared with the routing through a load balancer resolved by DNS, Envoy can clearly know the information of each upstream host, so it can make a more intelligent load balancing strategy.
  Endpoint configuration includes additional host attributes such as load balancing weights and available domains. These attributes can be used in the process of service grid load balancing and statistics collection.

• SDS (Secret Discovery Service)
  Secret Discovery Service, used to dynamically obtain TLS certificates at runtime. If there is no SDS feature, a Secret containing the certificate must be created in the k8s environment. The Secret must be mounted to the sidecar container before the agent starts. If the certificate expires, it needs to be redeployed. Using SDS, the centralized SDS server distributes the certificate to all Envoy instances. If the certificate expires, the server will distribute the new certificate. After Envoy receives the new certificate, it reloads without redeploying.

Citation reference

https://istio.io/latest/zh/docs/ops/deployment/architecture/
https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro