Mutual access between remote and managed control plane workloads - Alibaba Cloud Service Mesh

This topic describes how to achieve mutual access between clusters after using the ASM remote control plane feature.

Important

This topic continues to use cluster-1 and cluster-2 described in Reduce push latency using the ASM remote control plane, where cluster-1 represents an ACK cluster on the cloud (managed by the ASM managed control plane) and cluster-2 represents a non-ACK cluster (managed by the ASM remote control plane). Make sure that you have completed all the steps in Reduce push latency using the ASM remote control plane.
Steps in this topic involve switching kubeconfig multiple times. We recommend configuring the kubeconfig of cluster-1 and cluster-2 into the same config file and use kubectl config use-context to switch between them. You can also use kubecm or kubectx to manage the kubeconfig for multiple clusters.

Step 1: Accesse cluster-2 from cluster-1

Configure the cluster network and east-west gateway. For more information, see Achieve multi-cluster cross-network interconnection using the ASM east-west gateway.
Use the kubeconfig of cluster-1 to deploy the httpbin and sleep applications. For specific deployment steps, see Deploy the httpbin application.
Both clusters have the httpbin and sleep applications. ASM will treat the httpbin services in both clusters as a service. If you use sleep in cluster-1 to access httpbin, requests will be evenly distributed to the httpbin workloads in both clusters.
Execute the following command to scale in the httpbin service in cluster-1 to 0 for testing purposes:
```
kubectl scale deployment httpbin --replicas 0
```
Execute the following command to access the httpbin service from sleep in cluster-1:
```
kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418
```
Expected output:
```
    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`
```
You can see that the access is still successful. The request is processed by the httpbin service in cluster-2, and the communication between cluster-1 and cluster-2 is encrypted using mTLS.

Step 2: Test accessing cluster-1 from cluster-2

Note

Steps in this section depend on the istiocli tool. Make sure that the installed istiocli version is compatible with the ASM version.

By default, workloads managed by the remote control plane do not discover services managed by the managed control plane. This section describes how to access services in cluster-1 from cluster-2.

Create role.yaml with the following content:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
rules:
- apiGroups:
  - config.istio.io
  - security.istio.io
  - networking.istio.io
  - authentication.istio.io
  - rbac.istio.io
  - telemetry.istio.io
  - extensions.istio.io
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  - pods
  - services
  - nodes
  - replicationcontrollers
  - namespaces
  - secrets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - workloadentries
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - networking.x-k8s.io
  - gateway.networking.k8s.io
  resources:
  - gateways
  - gatewayclasses
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceexports
  verbs:
  - get
  - list
  - watch
  - create
  - delete
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceimports
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - replicasets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create", "get", "list", "watch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istio-reader-clusterrole-istio-system
subjects:
- kind: ServiceAccount
  name: istio-reader-service-account
  namespace: istio-system

Switch the working directory to the extracted istio folder and execute the following command to create ClusterRole and ClusterRoleBinding in cluster-1, allowing the remote control plane of cluster-2 to obtain service information from cluster-1 through ClusterRole.
```
bin/istioctl create-remote-secret \
--context=cluster-1 \
--name=${cluster-1 ID} | \
kubectl apply -f role.yaml --context=cluster-2
```
Note
After completing this step, a secret will be generated in the istio-system namespace of cluster-2. The secret contains the certificate used to connect to cluster-1. You must keep this secret properly.
Switch the context to cluster-1 and execute the following command to change the replica count of the httpbin service to 1:
```
kubectl scale deployment httpbin --replicas 1
```
Switch the context to cluster-2 and execute the following command to change the replica count of the httpbin service to 0:
```
kubectl scale deployment httpbin --replicas 0
```

Execute the following command to test accessing the httpbin service from cluster-2.

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

Expected output:

    -=[ teapot ]=-

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

You can see that the access is successful.