Enable mutual access between workloads on remote and managed control planes - Alibaba Cloud Service Mesh

Cette rubrique explique comment établir un accès mutuel entre les clusters après avoir activé la fonctionnalité de plan de contrôle distant d'ASM.

Prérequis

Avez effectué toutes les étapes décrites dans la rubrique Réduire la latence de push à l'aide du plan de contrôle distant d'ASM. Dans cette rubrique, cluster-1 représente un cluster Alibaba Cloud Container Service for Kubernetes (ACK) géré par le plan de contrôle géré d'ASM, tandis que cluster-2 représente un cluster non-ACK géré par le plan de contrôle distant d'ASM.
Les procédures de cette rubrique nécessitent de basculer entre différents fichiers kubeconfig. Ajoutez les fichiers kubeconfig de cluster-1 et cluster-2 au même fichier de configuration et utilisez la commande kubectl config use-context pour basculer d'un cluster à l'autre. Vous pouvez également utiliser kubecm ou kubectx pour gérer les fichiers kubeconfig de plusieurs clusters.
Avez configuré le réseau du cluster et la passerelle est-ouest, et déployé les applications httpbin et sleep dans cluster-1 et cluster-2. Pour plus d'informations, consultez la rubrique Mettre en œuvre l'interconnexion multi-clusters inter-réseaux à l'aide de la passerelle est-ouest d'ASM.

Étape 1 : Tester l'accès depuis cluster-1 vers cluster-2

Utilisez le fichier kubeconfig de cluster-1 pour exécuter la commande suivante. Cette commande réduit le nombre de réplicas de l'application httpbin dans cluster-1 à 0 à des fins de test.
```
kubectl scale deployment httpbin --replicas 0
```
Utilisez le fichier kubeconfig de cluster-1 pour exécuter la commande suivante afin d'accéder à l'application httpbin depuis l'application sleep dans cluster-1.
```
kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418
```
Résultat attendu :
```
    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`
```
Ce résultat indique que l'accès a réussi. La requête est traitée par l'application httpbin située dans cluster-2, et la communication est chiffrée via le protocole mTLS (mutual Transport Layer Security).

Étape 2 : Tester l'accès à cluster-1 depuis cluster-2

Créez les ressources ClusterRole et ClusterRoleBinding dans cluster-1 à l'aide du fichier YAML suivant. Le plan de contrôle distant de cluster-2 utilise cette ClusterRole pour obtenir les informations de service depuis cluster-1.

Développer pour afficher le fichier YAML

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

Assurez-vous que les contextes kubectl sont correctement configurés. Le contexte pour cluster-1 doit être nommé cluster-1 et celui pour cluster-2 doit être nommé cluster-2.
Installez l'outil istioctl. Vérifiez que la version d'istioctl est compatible avec votre version d'ASM. Placez-vous dans le dossier istio décompressé et exécutez la commande suivante.
```
# Replace <YOUR_CLUSTER1_ID> with the ID of cluster-1.
bin/istioctl create-remote-secret \
--context=cluster-1 \
--name=<YOUR_CLUSTER1_ID> | \
kubectl apply -f - --context=cluster-2
```
Une fois cette étape terminée, un secret est généré dans le namespace istio-system de cluster-2. Ce secret contient les identifiants d'accès utilisés pour se connecter à cluster-1. Gérez soigneusement les permissions associées à ce secret afin d'éviter toute fuite.
Utilisez le fichier kubeconfig de cluster-1 pour exécuter la commande suivante et définir le nombre de réplicas de l'application httpbin à 1.
```
kubectl scale deployment httpbin --replicas 1
```
Utilisez le fichier kubeconfig de cluster-2 pour exécuter la commande suivante et définir le nombre de réplicas de l'application httpbin à 0.
```
kubectl scale deployment httpbin --replicas 0
```

Utilisez le fichier kubeconfig de cluster-2 pour exécuter la commande suivante afin de tester l'accès depuis cluster-2 vers l'application httpbin dans cluster-1.

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

Résultat attendu :

    -=[ teapot ]=-

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