Mesh Optimization Center

Features

While powerful, a service mesh can also introduce performance overhead, such as:

• Increased latency: In a service mesh, every request must pass through sidecar proxies. The processing in these proxies adds latency.

• Increased resource consumption: Each proxy requires CPU and memory resources. As the number of services grows, the total resource consumption of the proxies increases accordingly.

• If you enable Transport Layer Security (TLS), the sidecar proxies must encrypt and decrypt traffic, which consumes additional resources.

To mitigate this overhead, Alibaba Cloud Service Mesh provides the Mesh Optimization Center, which uses performance optimization techniques across multiple dimensions and layers to improve product performance and high availability:

I. Scope service discovery to improve mesh configuration push efficiency

II. Automatically recommend Sidecar resources based on access log analysis to reduce proxy resource consumption

III. Adaptive xDS optimization

IV. Continuous hardware-aware performance tuning

V. Support for resource overcommitment

I. Scope service discovery

In Istio, you can use several methods to limit the scope of service discovery, which improves the efficiency of the control plane when it pushes mesh configurations. Scoping service discovery helps reduce the CPU and memory consumption of control plane components and lowers the bandwidth usage for communication between the control plane and sidecar proxies.

You can use a Discovery Selector to define a set of filter rules that select the service discovery information to be synchronized to the control plane:

• It filters by namespace to discover services only in specified namespaces within the data plane's Kubernetes cluster.

• It interacts directly with Istiod to improve the processing efficiency of the control plane.

Additionally, you can use exportTo and workloadSelector to limit the scope of configuration rules. This supports global settings (MeshConfig), namespace-level settings, and fine-grained settings for individual services or configurations. The following are examples.

• exportTo: Controls the visibility scope of rules such as VirtualService, DestinationRule, and ServiceEntry.

• workloadSelector: Specifies the services to which rules such as DestinationRule, ServiceEntry, EnvoyFilter, and Sidecar apply.

VirtualService configuration example:

exportTo:
  - default
  - istio-system
hosts:
  - reviews.prod.svc.cluster.local
http:
  - name: reviews-route
    route:
      - destination:
          host: reviews.prod.svc.cluster.local
          port:
            number: 8080

DestinationRule configuration example:

host: reviews.prod.svc.cluster.local
subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v2
    name: v2
workloadSelector:
  matchLabels:
    app: reviews

ASM provides a corresponding feature. You can define the scope of service discovery by selecting or clearing namespaces.

On the Service discovery scope configuration page in the ASM console, select the target cluster. On the Select namespaces tab, you can view the name, selection status, label information, and available actions for each namespace.

You can also select services in the corresponding namespaces by editing label selectors. If a namespace in the data plane Kubernetes cluster matches any label selector, the services in that namespace are included in the automatic discovery scope. A namespace must match all the rules defined in a label selector to be selected by it. For more information, see Configure the service discovery scope to improve mesh configuration push efficiency.

For example, label selectors support both exact match and expression match. For an exact match, you can specify a label name such as kubernetes.io/metadata.name and a label value such as kube-system or istio-system. For an expression match, you can specify a label name such as istio-discovery, the operator in, and label values that include true and enabled. You can add new rules by clicking Add Label Selector. For each selector, you can add or remove match conditions.

II. Automatic Sidecar resource recommendation

This optimization is based on xDS and Sidecar resources.

xDS stands for X Discovery Service. It is the communication protocol between the service mesh control plane and the data plane sidecar proxies. The 'x' represents a collection of discovery services, such as LDS for listeners, CDS for service and version information, EDS for service instances and their attributes, and RDS for routes.

Sidecar proxies use the xDS protocol to obtain configuration information from Istio. You can think of xDS as a collection of service discovery data and governance rules within the mesh. The size of the xDS data is directly proportional to the scale of the mesh.

By default, Istio uses a full push strategy for xDS, which means every sidecar proxy in the mesh stores the service discovery data for the entire mesh in its memory.

In most cases, a workload in a large-scale cluster communicates with only a few other workloads. Configuring a sidecar proxy to be aware of only the necessary services can significantly reduce its memory footprint. The Sidecar resource helps define these configuration constraints.

The automatic generation of Sidecar resource recommendations based on access log analysis works as follows:

1. The system analyzes the access logs generated by data plane sidecar proxies to determine the call dependencies between services. It then automatically recommends a corresponding Sidecar resource for each workload in the data plane.

2. After the Sidecar resource is generated based on the analysis, you can review and confirm it, or customize the automatically generated recommendation.

This method is suitable for scenarios where service call log data already exists and the call dependencies of existing business services do not change frequently. This allows you to perform a one-time optimization. For example, in the Bookinfo application, after a few requests, each sidecar proxy generates corresponding access logs. For the productpage service, the recommended Sidecar resource is as follows:

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  labels:
    provider: asm
    taskid: '297'
  name: asm-rec-for-default-productpage-v1
  namespace: default
spec:
  egress:
    - hosts:
        - '*/details.default.svc.cluster.local'
        - '*/reviews.default.svc.cluster.local'
      port:
        name: HTTP-9080
        number: 9080
        protocol: HTTP
    - hosts:
        - istio-system/*
        - kube-system/*
  workloadSelector:
    labels:
      app: productpage
      version: v1

This feature requires you to enable Simple Log Service to collect access logs. The logs must cover all business calls to obtain a complete dependency graph. If a call path is not used, its dependency may be missed. This can result in an inaccurate Sidecar resource definition, causing subsequent calls on that path to fail.

ASM allows you to use Sidecar resources that are automatically recommended based on access log analysis to improve the efficiency of xDS pushes. For more information, see Use Sidecar resources that are automatically recommended based on access log analysis.

On the Ingress and egress traffic configuration (Sidecar) page in the ASM console, a list of recommendation statuses for each workload is displayed. The list includes columns for Workload name, Namespace, Recommendation task status, Last recommendation time, and Actions. For the Bookinfo application, the recommendation task status for the productpage-v1 workload is Recommended, while the status for other workloads is Not recommended. You can manage the Sidecar recommendation configuration for each workload by using the buttons in the Actions column, such as View, Recommend, and Recollect Logs.

III. Adaptive xDS optimization

To address the limitations of the preceding method, ASM provides another optimization technique that pushes xDS configurations on demand and adapts to application service changes.

Adaptive xDS optimization analyzes service dependencies based on access logs within the mesh and automatically generates a Sidecar resource for each service to optimize the configuration push for its corresponding workload. When this feature is enabled, an egress gateway named istio-axds-egressgateway is deployed in the cluster. All initial HTTP traffic between services is directed to this egress gateway, which records access logs to automatically analyze service dependencies.

The following architecture diagram shows:

• On the managed side, the Adaptive XdsController component manages the lifecycle of the AdaptiveXds-EgressGateway and generates the necessary EnvoyFilter and bootstrap configurations.

• After this feature is enabled, the AdaptiveXds-EgressGateway reports access logs to the Access Log Service (ALS).

• The Access Log Service (ALS) receives log data sent from the egress gateway, analyzes the log content using the ALSAnalyzer, and then generates the corresponding Sidecar resource based on service call dependencies.

You can enable adaptive xDS optimization for services in a cluster at the namespace level. After it is enabled, configuration push optimization based on Sidecar resources is automatically performed for all services in the namespace.

Alternatively, you can add the asm.alibabacloud.com/asm-adaptive-xds: true annotation to the annotations of a Kubernetes service to enable this optimization for that specific service.

In a customer scenario using ASM, this optimization method reduced the configuration size in sidecar proxies by 90%, and memory consumption dropped from 400 MB to 50 MB.

ASM provides adaptive xDS optimization to improve the efficiency of xDS pushes and reduce unnecessary configurations in sidecar proxies. For more information, see Use adaptive xDS optimization to improve control plane push efficiency.

IV. Continuous hardware-aware performance tuning

The data plane environment can vary, with different ECS instance types and OS versions. By detecting node features, you can better understand the capabilities of each node. For example, you can determine whether a node supports eBPF-related features based on its kernel version, decide whether to enable TLS encryption and decryption based on support for the AVX instruction set, or check if a Device Plugin is available.

ASM detects hardware features on each node in a Kubernetes cluster, such as CPUID features and instruction set extensions, to dynamically configure and adaptively enable or disable corresponding features. This process is transparent to the user.

For example, ASM supports dynamically enabling the Multi-Buffer feature based on AVX instruction set support to improve TLS encryption and decryption performance. For more information, see Accelerate Encrypted Communication Among Application Services with Intel Architecture-based ASM Technology.

Specifically:

1. On the service mesh control plane, ASM provides a unified declarative configuration definition by extending MeshConfig or using CRDs.

2. The control plane configuration is delivered to the data plane Envoy proxies through the xDS protocol. This is also part of the extended capabilities in ASM.

3. If no suitable nodes are available, these Pods can still be scheduled to other nodes, where the feature is adaptively disabled.

V. Support for resource overcommitment

In a Kubernetes system, the kubelet manages the resource quality for containers on a per-node basis based on a Pod's Quality of Service (QoS) class, which determines factors such as Out of Memory (OOM) priority.

ack-koordinator provides a dynamic resource overcommitment feature. It collects real-time node load data to enable dynamic resource overcommitment by leveraging allocated but unused resources in the cluster.

Resource limits and requests do not have to be the same. We recommend configuring resource limits and requests based on the workload type.

• For workloads with a Guaranteed QoS class, set the resource limit and request to the same value.

• For other types of Pods, follow the native Kubernetes convention by setting requests lower than limits.

ASM supports setting dynamic resource overcommitment for the injected sidecar proxy and the istio-init container. For more information, see Configure sidecar proxies and Configure dynamic resource overcommitment in a sidecar.