All Products
Search

This Product

    Alibaba Cloud Service Mesh:Reduce Push Latency by Using the ASM Remote Control Plane

    Document Center

    Alibaba Cloud Service Mesh:Reduce Push Latency by Using the ASM Remote Control Plane

    Last Updated:Aug 27, 2026

    The ASM remote control plane deploys Alibaba Cloud Service Mesh (ASM) control plane components to a non-Alibaba Cloud cluster. The sidecar proxies in that cluster then connect directly to the remote control plane, which improves configuration push efficiencies and reduces push latency.

    When to use the ASM remote control plane

    Whether the remote control plane applies to your mesh depends on where your data plane clusters run:

    • Data plane clusters in Alibaba Cloud VPCs — The data plane workloads connect directly to the ASM managed control plane over the Alibaba Cloud virtual private cloud (VPC) network. Network latency is low and control plane configurations are delivered smoothly, so the remote control plane is not needed.

    • Data plane clusters in another cloud service or an on-premises data center — These clusters connect to the ASM control plane over the Internet or other special means, and that network can be unstable or bandwidth-limited. Use the ASM remote control plane to reduce push latency.

    The remote control plane also changes how you operate the mesh: it changes the kubeconfig file that you use for mesh resources, requires another ASM feature to be disabled, and restarts the ASM gateways in the cluster. Review Considerations before you decide.

    How it works

    The following figure shows the overall architecture of the ASM remote control plane.

    If all pods in a non-Alibaba Cloud cluster connect directly to the managed ASM control plane, the number of network connections and the bandwidth usage between the managed control plane and the cluster grow with the number of pods. If configuration or service changes occur frequently, push latency is likely to occur.

    After you use the ASM remote control plane, the remote control plane pushes configurations to the sidecar proxies in the cluster. Only a small number of network connections remain between the ASM control plane and the non-Alibaba Cloud cluster, and they are used to deliver control plane components and to support service discovery. This greatly reduces the dependence on a low-latency, high-bandwidth network and improves configuration push efficiencies.

    image

    Considerations

    Before you enable the ASM remote control plane, consider the following:

    • kubeconfig file for mesh resources — After you use the ASM remote control plane, you must create the Kubernetes resources related to the service mesh by using the kubeconfig file of the ASM instance. If you use the kubeconfig file of the non-Alibaba Cloud cluster, those resources may be overwritten.

    • Mutually exclusive feature — The ASM remote control plane conflicts with the Use the Kubernetes API of clusters on the data plane to access Istio resources feature. Before you enable the remote control plane, make sure that this feature is disabled.

    • Access direction between clusters — Access between workloads on the managed control plane and services on the remote control plane is one-way by default. For the complete rule and the available options, see Cross-cluster access.

    Important

    After you switch to the remote control plane, the ASM gateways in the cluster restart. Assess the impact before you perform this operation.

    Prerequisites

    Step 1: Enable the remote control plane

    1. Use the kubeconfig file of the ASM instance and run the following command to edit the ASMMeshConfig resource:

      kubectl edit ASMMeshconfig

    2. Add the following .spec.externalIstiodConfigurations configuration to the ASMMeshConfig resource:

      apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMeshConfig
metadata:
  name: default
spec:
  # The other existing fields under spec are omitted here.
  externalIstiodConfigurations:
    ${ClusterID of cluster-2}:
      replicas: 2
      # The resources configuration is also supported here. It has the same field structure as the resource configuration of a pod. If it is left empty, the default configurations provided by ASM are used.

      Before you apply this change, review Considerations.

    Step 2: Deploy applications and run a test

    1. Deploy the sleep application and the httpbin application to cluster-2. For instructions, see Deploy the httpbin application.

    2. Use the kubeconfig file of cluster-2 and run the following command:

      kubectl get pod

      Expected output:

      NAME                       READY   STATUS    RESTARTS   AGE
httpbin-7df7fxxxxx-xxxxx   2/2     Running   0          3h15m
sleep-6b7f9xxxxx-xxxxx     2/2     Running   0          3h15m

      A sidecar proxy is injected into both pods, and both pods are in the Running state.

    3. Run the following command to access httpbin from the sleep application:

      kubectl exec deploy/sleep -it -- curl httpbin:8000/status/418

      Expected output:

      -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`

    Cross-cluster access

    ASM provides global service discovery. By default, access between the two control planes is one-way. Workloads managed by the ASM managed control plane can access services managed by the remote control plane. However, services managed by the remote control plane cannot access services managed by the managed control plane. Calls from the managed control plane to the remote control plane use mTLS by default, and the ASM east-west gateway is also supported.

    If you take no action, this default access behavior remains in effect. Otherwise, choose one of the following options: