Alibaba Cloud Service Mesh:Overview

Feature description

Service Mesh (ASM) instances whose versions are 1.18 or later support the Ambient Mesh mode. Ambient Mesh introduces a sidecarless data plane to simplify the integration of applications with service meshes, provide users with a way to use service meshes in an incremental fashion, and reduce the infrastructure cost of Istio users.

Ambient Mesh supports both data planes with or without sidecars. You can use one or both of them based on your application requirements. In ASM instances whose versions are 1.18, sidecar proxies support HTTP-Based Overlay Network Environment (HBONE). Therefore, such sidecar proxies can interoperate with sidecar-less applications by using zero-trust tunnels (ztunnels) or waypoint proxies. In some cases, ztunnels and waypoint proxies are used together. Ztunnels provide the secure overlay layer and waypoint proxies provide Layer 7 processing capabilities.

Design philosophy

Ambient Mesh splits the data plane into two distinct layers: Layer 4 and Layer 7. Fundamental processing is performed at Layer 4, which features high efficiency and less resource consumption. Advanced features for handling traffic are provided at Layer 7, which requires more resources. You can adopt the service mesh technology incrementally depending on the features that you require.

In Ambient Mesh mode, Layer 4 proxies (also called ztunnels) and the Layer 7 proxies (also called waypoint proxies) are decoupled. The capabilities of a Layer 4 proxy are implemented by using the Container Network Interface (CNI) plugin. A Layer 4 proxy runs as DaemonSet on every node. This means that the Layer 4 proxy is a shared component that provides services for all pods running on the same node.

A Layer 7 proxy is no longer deployed as a sidecar, but as a per-service-account pod for Layer 7 processing.

The configurations of Layer 4 and Layer 7 proxies are still managed by the components on the control plane of ASM. The decoupling of Layer 4 and Layer 7 proxies enables further decoupling of applications from the data plane of ASM.

The implementation of Ambient Mesh in Istio involves the following three parts:

• Waypoint proxy:

  • It is a Layer 7 component that is separated from applications, which enhances security.

  • A specific waypoint proxy is provided for each identity (a service account in Kubernetes). This avoids the complexity and instability introduced by the multi-tenant Layer 7 proxy mode.

  • The waypoint proxy is enabled by configuring a Kubernetes gateway CustomResourceDefinition (CRD).

• Ztunnel: Ztunnel implements Layer 4 processing by using the CNI plugin. Traffic from a workload is redirected to the corresponding ztunnel which then identifies the workload and selects an appropriate certificate for traffic processing.

• Compatibility with sidecar: The data plane with sidecar proxies configured is still most widely used by users when they use the service mesh. Waypoint proxies can communicate with workloads in which sidecar proxies are deployed.

In the traditional mode, you must inject a sidecar proxy into each application. However, in Ambient Mesh mode, you do not need to redeploy or modify the existing application. Therefore, Ambient Mesh is less invasive than the traditional mode. The less invasiveness helps reduce the implementation risks and simplify the use of Ambient Mesh.

Ambient Mesh is non-invasive. In Ambient Mesh mode, you can add an application to the service mesh by adding a specific label to the namespace in which the application resides. Once an application is added to the service mesh in Ambient Mesh mode, the mutual transport layer security (mTLS) method and the observability feature provided by Layer 4 are available for the application.

Routing in Ambient Mesh mode

In Ambient Mesh mode, workloads can be divided into the following three categories:

• Uncaptured: a standard pod in which no mesh feature is enabled.

• Captured: a pod in which traffic is intercepted by a ztunnel. Pods can be captured by adding the istio.io/dataplane-mode=ambient label to namespaces.

• Waypoint-enabled: a pod in which traffic is intercepted by a ztunnel and a waypoint proxy is deployed. By default, a waypoint proxy is shared by all pods in the same namespace. You can also specify that a waypoint proxy is dedicated to a specific service account by adding the istio.io/for-service-account annotation in the Kubernetes gateway CRD. If both a namespace-specific waypoint proxy and a service account-specific waypoint proxy are configured, the service account-specific waypoint proxy takes precedence.

Ztunnel routing

• Outbound

  When an application in a captured pod initiates an outbound request, the request is transparently redirected to the ztunnel of the node on which the pod runs. Then, the ztunnel selects the method to forward the request and the destination for the request. Generally, the traffic routing behaves just like the default traffic routing in Kubernetes. For a request to a Service in Kubernetes, the request is sent to an endpoint within the Service. However, requests to a pod IP address are directly sent to that IP address. The request routing behavior varies with the capabilities of the request destination. If the request destination is also captured or has Istio proxy capabilities (for example, a sidecar proxy or an Istio gateway is deployed), the request is routed by using an encrypted HBONE tunnel. If the destination has a waypoint proxy, in addition to being routed by using an encrypted HBONE tunnel, the request is forwarded to that waypoint proxy.

  Note that when requests are made to a Service, ztunnel of the pod from which requests are initiated selects a pod to check whether a waypoint proxy is configured for the pod. If a waypoint proxy is configured for the selected pod, requests are sent to the waypoint proxy. Then, the waypoint proxy sends the request to the destination. This enables the waypoint proxy to enforce service-oriented policies to the traffic. For a Service, if waypoint proxies are enabled for some but not all of the pods, some requests are sent to the waypoint proxies while other requests to the same Service are not.

• Inbound

  When a captured pod receives an inbound request, the request is transparently directed to the ztunnel of the pod. When the ztunnel receives the request, the ztunnel applies the authorization policies and forwards the request only if the request conforms to the policies. Pods can receive HBONE-compliant traffic or plaintext traffic. By default, ztunnels will accept these two types of traffic. Because plaintext requests do not have a peer identity when the authorization policies are evaluated, you can configure a policy that requires an identity (any identity or a specific one) to block all plaintext traffic.

  When a waypoint proxy is enabled for the destination, all requests must go through the waypoint proxy where policies are executed. The corresponding ztunnel will ensure this occurs. However, the following edge case exists: A well-behaving HBONE client, such as another ztunnel or Istio sidecar, knows that requests must be sent to the waypoint proxy, but other clients such as workloads outside the mesh do not know anything about the waypoint proxy and send requests directly to the destination pod. For such direct calls, the ztunnel will send the received requests to its own waypoint proxy to ensure that the policies are executed correctly.

Waypoint routing

A waypoint proxy receives only HBONE requests. Upon receiving a request, the waypoint proxy will ensure that the destination of the request is a pod that it manages or a Service that contains a pod it manages.

For either type of request, the waypoint proxy will enforce policies, such as AuthorizationPolicy, WasmPlugin, and Telemetry, before it forwards the request.

For direct requests to a pod, the requests are simply forwarded directly after policies are applied.

For requests to a Service, the waypoint proxy also applies routing and load balancing. By default, a Service simply routes traffic to itself and performs load balancing among its endpoints. You can override the default behavior by configuring a route for this Service.

Differences from the sidecar architecture

• In Ambient Mesh mode, Layer 4 and Layer 7 processing capabilities are decoupled. The Rust-based ztunnels are introduced for Layer 4 processing. Ztunnels can serve as high-performance network proxies that consume few resources.

• Waypoint proxies are destination-oriented. The configuration of a waypoint proxy needs to only contain information about limited dynamic clusters, endpoints, and routes that the waypoint proxy needs to connect to rather than details of all Services in the cluster in which the waypoint proxy runs. This effectively eliminates the need for supporting sidecar resources for waypoint proxies. You do not need to manually configure sidecar resources.

Benefits of Ambient Mesh

• The mesh proxies run independently of applications. When the proxies are updated or restarted, you do not need to restart applications.

• This expands the support for applications, including the support for Kubernetes Jobs.

• Ambient Mesh eliminates the requirements for applications in the sidecar architecture, including the limits for server-first protocols.

• In Ambient Mesh mode, you can adopt mesh technologies in an incremental fashion. For example, you can use the secure overlay layer at the initial stage to implement mTLS, simple Layer 4 authorization policies, and observability features.

• If no Layer 7 processing is required, the secure overlay layer can significantly reduce the attack surface and the frequency to update the data plane for common vulnerabilities and exposures (CVE)s and other patches.

• Ambient Mesh allows you to scale the data plane independently of your workload, which reduces infrastructure costs.