Some personal summaries for easy memorization

architecture

The overall architecture is that the platform adapter pulls the models of each platform into a unified abstract model (the adapter pattern) and then the user API configates some rules, which are delivered to the corresponding container via the Envoy API

The container, when it starts, it uses auto-injection to inject some other containers into the configuration, and one of them, the pilot-Agent container is the process that the agent starts, and it generates some basic static configuration that initializes the proxy, and then it launches the proxy envoy, Then the shell script initialized before init starts modifies the IPtable to proxy all the traffic from the container into the corresponding proxy container envoy

So now the control layer is all centralized, using IStiod to include the previous Polit, Citade, Galley, and then the Mix is discarded and the mix that was deployed independently is put into each envoy using the plug-in mechanism of the Envoy to run the V8 engine in the plug-in, This engine can then execute the WebAssembly code to implement this new mix

envoy

A proxy middleware similar to nginx, written in c++, with a filter plug-in mechanism allows users to achieve a lot of rich functions

The basic concept

Host: An entity (such as a mobile device, an application on a server) that can communicate with a network. In this document, the host is a logical network application. It is possible to have multiple hosts running on a piece of physical hardware, as long as they are individually addressable. An EDS interface also uses Endpoint to indicate an application instance, which corresponds to an IP address and Port.

Downstream: A Downstream host connects to an Envoy and sends a request and receives a response.

Upstream: The Upstream host receives a connection and request from an Envoy and returns a response.

Listener: A Listener is a named network address (for example, a port, Unix domain socket, etc.) that can be connected by downstream clients. Envoy exposes one or more listeners to the downstream host for connection. In an Envoy, a Listener can be bound to a port to serve directly outside, or it can be unbound to a port and receive requests forwarded by another Listener.

Cluster: A Cluster is an Envoy connected set of upstream hosts that are peer hosts providing the same services, forming a service Cluster that can provide load balancing and high availability. Envoy finds cluster members through service discovery. You can choose to perform an active health check to determine the health status of cluster members. The Envoy determines which cluster member to route the request to using a load-balancing policy.

xds

It’s made up of a lot of DS like LDS, CDS, EDS, SDS, RDS, etc

XDS is a protocol that dynamically modifies the configuration of the Nginx conf proxy based on the API

XDS interfaces are ultimately consistent. To ensure service availability, XDS updates the content of each DS in a sequential order to ensure service availability

ADS

In fact, it is the service access in the form of stream in GRPC. It is to send the separate updates in each XDS in the form of stream at one time, so as to avoid the inconsistent configuration data caused by the update sequence

istiod

After version 1.6, the whole control layer is now isTIod, which includes polit, Citade and Galley functions. At present, ISTIod uses this to replace those components in order to make the service more clear and simple, because the control layer is basically delivered as a configuration. The telemetry and strategy from the previous MIX has been moved to envoy

Benefits of using ISTIOD

Installation becomes easier. Fewer Kubernetes Deployment and associated configurations are required, so Istio’s configuration options and parameter set are significantly reduced. In the simplest case, you only need to start a single Pod to enable an Istio control plane with all the functionality.

Configuration becomes easier. Many of the configuration options Istio currently has are ways of orchestrating control plane components and are therefore no longer needed. You also no longer need to change the cluster-wide PodSecurityPolicy to deploy Istio.

It’s easier to use virtual machines. To add the workload to the grid, you now only need to install an agent and the generated certificates. This agent only connects to a single background service.

Maintenance becomes easier. Installing, upgrading, and removing Istio no longer requires complex version dependencies and startup sequences. For example, to upgrade the control plane, you simply start a new ISTIOD version next to the existing control plane, deploy it with canary, and then move all traffic to that plane.

Scaling becomes easier. There is now only one component that needs to scale.

Debugging becomes easier. Fewer components means less debugging across component environments.

The startup time decreases. Components no longer need to wait for each other when started in a predefined order.

The resource usage decreases and the response capability increases. Communication between components is guaranteed and is not limited by gRPC packet size. Caches can be securely shared, reducing resource usage.

polit

As an envoy proxy configuration refresh and distribution tool, the purpose of this tool is to change the user’s configuration into the XDS API and then send it to each envoy proxy

istio-polit

Prior to version 1.6, a component of the control layer that runs separately

citade

As an ISTIO security component, a secure access mechanism is established between services. In other words, encrypted access is configured for each service. When the certificate expires, the service does not need to change

istio-citade

Prior to version 1.6, a component of the control layer that runs separately

galley

Provides support to other components at the control layer, configures management components, verifies the format and correctness of configuration information, and provides this configuration information to the control layer components

istio-galley

Prior to version 1.6, a component of the control layer that runs separately

Mix (obsolete)

Two functions, telemetry and policy, are available. Users can write their own adapters to implement the various functions themselves. Currently this component is deprecated and the telemetry function is moved directly to the Envoy, while the policy function is also handed over to the V8 engine running on the Envoy and implemented via WebAssembly

istio-telemetry

A mix service component for data telemetry, the service reports data to MIX and then summarizes and reports the data to other components, such as Zikip and Prometheus

istio-policy

Another MIX service, which is essentially the same process and mechanism as IStio-TelemEntry, returns whether access is allowed, that is, components that are accessed as a policy

WebAssembly

WebAssembly (Wasm) is a portable bytecode format written in multiple languages that executes at near-native speeds. Its original design goals fit well with the challenges outlined above, and it has considerable industry support behind it. Wasm is the fourth standard language (after HTML, CSS, and JavaScript) to run natively in all major browsers and became an official W3C recommendation in December 2019. That gives us the confidence to make a strategic bet on it.

Although WebAssembly was born as a client-side technology, it has many advantages when used on servers. The runtime is memory safe and sandboxed to ensure safety. It has a large ecosystem of tools for compiling and debugging Wasm in text or binary format. The W3C and BytecodeAlliance have become active centers for other server-side efforts. For example, the Wasm community is standardizing the “WebAssembly System Interface” (WASI) at the W3C with an example that provides an OS-like abstraction for Wasm “programs.”

Envoy uses Wasm’s architecture

  • Set up the local cache for Wasm extensions
  • Extract the required Wasm extensions into the local cache
  • Mount wASM-Cache to the appropriate workload
  • Configure the Envoy to use the Wasm filter using EnvoyFilter CRD

serviceEntry

An abstract concept, an object created to include external services in ISTIO traffic control. This object can be used to access external services and use many of ISTIO’s functions

Gateway

The gateway manages layer l3-L6 traffic, while the ingress manages layer L7 traffic. In fact, I feel that the gateway is the ingress

ingressGateway

The gateway for incoming traffic, essentially envoy, also intended for reusing and unifying traffic, is a Loadbanlance type of service that works with VirtualService and Gateway

engressGateway

The outbound traffic gateway, essentially envoy, also intended for reusing and unifying traffic management, is a Loadbanlance type of service that works with VirtualService and Gateway

VirtualService

concept

Represents the mapping between one or more user-addressable targets to actual workloads within the grid. Where the user-addressable target can be any DNS name with an optional wildcard prefix or CIDR prefix used to locate the service. This is particularly useful for migrating applications from monolithic to microservice architectures. After monolithic applications are split into multiple independent microservices, VirtualService can continue to expose multiple microservices to the same target address without requiring service consumers to modify to accommodate the change

In general, the purpose of VirtualService is to locate the destination of the traffic, while the purpose of DestinationRule is to locate the policy execution after the traffic arrives

function

HTTPRoute

  • Redirect (HTTPRedirect)
  • Rewrite (HTTPRewrite)
  • Retry (HTTPRetry)
  • Fault injection (HTTPFaultInjection)
  • Cross-site (CorsPolicy)
  • Mirror (Mirror)

HTTPMatchRequest

Support conditional matching of HTTP attributes such as URL, Scheme, Mechod, Authority, port, headers, sourceLabels, etc

Then a matching rule can specify gateways

HTTPRouteDestination

The route field is an HTTPRouteDestination array that defines the direction of a route, and the destination field is an HTTPRouteDestination array that defines the destination of a request, described by host,subset, and port.

Weight is used to set the route weight

Headers can be given way based on the request headers

TLSRoute routing

TLS has several configurations, one is to self-configure the address of the public and private key, in fact, to create a secret file with the specific name k8S, which contains the public and private key, and the gateway default configuration will automatically load the secret of the specific name, and another is to use SNI to infiltrate traffic. Let the service do the security management (that is, the traffic goes directly to the Nginx service, let the Nginx service do the security), and finally, the credentialName in the form of SDS directly configures the corresponding secret

DestinationRule

Subsets (or named versions) of the target host are defined. These subsets are used in VirtualService routing rules to direct traffic to certain versions of the service. After a version is named in this way, you can explicitly reference the subset of the named version in different virtual services, simplifying the statistics sent by the Istio agent. All request traffic for the service is automatically re-routed through the Envoy. Envoy distributes traffic between instances in a load-balancing pool

function

  • TrafficPolicy, which defines load balancing, connection pooling policies, outlier checking (similar to circuit breakers), port trafficPolicy Settings (which define local traffic policies and override global traffic policies), TLS authentication configuration
  • Subsets, which define a subset of services used to define a service version