Alibaba Cloud Service Mesh:Reduce push latency using ASM remote control plane

Background

When the data plane cluster is built in an Alibaba Cloud virtual private cloud (VPC), the data plane workload can directly connect to the ASM managed control plane through the Alibaba Cloud VPC network. This results in low network latency, smooth control plane configuration push, and no need to use the remote control plane capability.

When the data plane cluster is located in other cloud services or on-premises data centers, it has to connect to the ASM control plane through the Internet or other specific methods, and the connected network environment is unstable or bandwidth is limited. We recommend using the ASM remote control plane to reduce push latency.

The overall architecture of the remote control plane is as follows:

If all pods in the non-ACK cluster directly connect to the managed ASM control plane, the number of network connections and the bandwidth usage between the managed control plane and the non-ACK cluster is positively correlated with the number of pods. If configuration or service changes occur frequently, push latency issues are likely to arise.

After using the ASM remote control plane capability, the remote control plane pushes configurations to the sidecar proxy of the cluster. Only a small number of network connections exist between the ASM control plane and the non-ACK cluster for control plane component push and service discovery. This greatly reduces the need for low-latency and high-bandwidth network environments and improves configuration push efficiency.

ASM remote control plane usage notes

• After using the ASM remote control plane, Kubernetes resources related to the ASM must be created by using kubeconfig of the ASM. If the kubeconfig of the remote cluster is used, such resources may be overwritten.

• ASM provides global service discovery. This means that workloads managed by the ASM managed control plane can access services managed by the remote control plane, and by default, use mTLS communication, supporting east-west ASM gateways.

• The ASM remote control plane conflicts with the Use the Kubernetes API of clusters on the data plane to access Istio resources feature. Before enabling the remote control plane, ensure that this feature is disabled.

Prerequisites

• An ASM instance is created, and the instance version is 1.22 or above. For more information, see Create an ASM instance.

• Two data plane clusters are added to the ASM instance. For more information, see Add clusters to an ASM instance.

  • cluster-1 refers to the Alibaba Cloud ACK cluster, where the sidecar proxy can directly connect to the ASM control plane.

  • cluster-2 refers to an external registered cluster or remote cluster, where the sidecar proxy cannot directly connect to the ASM control plane, or the network environment for connection is limited. For more information about how to add non-Alibaba Cloud clusters to an ASM instance, see Manage registered cluster applications through ASM or Manage Kubernetes clusters imported through kubeconfig.

• Automatic sidecar proxy injection is enabled.

Step 1: Enable remote control plane capability

1. Use the kubeconfig of the ASM instance and execute the following command to change the ASMMeshconfig resource in the cluster.

   kubectl edit ASMMeshconfig

2. Configure .spec.externalIstiodConfigurations in the following content into ASMMeshconfig.

   apiVersion: istio.alibabacloud.com/v1beta1
   kind: ASMMeshConfig
   metadata:
     name: default
   spec:
     ......
     externalIstiodConfigurations:
       ${cluster-2's ClusterID}:
         replicas: 2
         # Resources configuration is also supported here, and the structure of the resource configuration fields is the same as that of the pod. If empty, the default configuration provided by ASM is used.

   Note

   After switching to the remote control plane, the ASM gateway in the cluster will restart. We recommend that you assess the impact before you perform this operation.

Step 2: Deploy applications and conduct tests

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

2. Use the kubeconfig of cluster-2 and execute 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

   You can see that both pods have been injected with a sidecar and are in the running state.

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

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

   Expected output:

       -=[ teapot ]=-
   
          _...._
        .'  _ _ `.
       | ."` ^ `". _,
       \_;`"---"`|//
         |       ;/
         \_     _/
           `"""`

Step 3: Cluster mutual access instructions

By default, workloads managed by the managed control plane can access services of the remote control plane, while services of the remote control plane cannot access services of the managed control plane.

• If you do not need mutual access between clusters, you can use the intra-cluster traffic retention feature. For more information, see Enable ASM local intra-cluster traffic retention feature in multi-cluster scenarios.

• If you need mutual access between clusters, see Achieve mutual access between remote control plane and managed control plane workloads.