Alibaba Cloud Service Mesh:Utiliser le proxy de maillage inter-cluster ASM pour implémenter la communication inter-réseau entre plusieurs clusters

Contexte

ASM prend en charge le mode multi-cluster, ce qui signifie que vous pouvez ajouter plusieurs clusters ACK à la même instance ASM. Ce mode vous permet d'ajouter des clusters ACK résidant dans différents réseaux à une même instance ASM. Si la communication de niveau 3 (couche réseau) ne peut pas être établie entre ces clusters pour diverses raisons (restrictions infrastructurelles, conflits de plages CIDR, coûts élevés, etc.), utilisez les proxys de maillage inter-cluster ASM pour les connecter. Ces proxys permettent de relier les clusters de manière flexible via des réseaux publics et privés. Ainsi, vous résolvez les conflits de plages CIDR sans modifier le code de vos services et mettez en œuvre une gouvernance centralisée du trafic, une protection de sécurité ainsi qu'une observation de bout en bout pour plusieurs clusters. Cette rubrique décrit comment utiliser les proxys de maillage inter-cluster ASM pour configurer la communication inter-réseau entre plusieurs clusters ajoutés à la même instance ASM. Dans cet exemple, l'application sleep accède à l'application HTTPBin d'un autre cluster.

Avantages

Les proxys de maillage inter-cluster ASM fournis par les instances ASM version 1.22 et ultérieures implémentent entièrement l'équilibrage de charge au niveau 7 (couche application). Les capacités de routage des passerelles ASM est-ouest dans les scénarios de communication inter-cluster sont identiques à celles des scénarios de communication intra-cluster.

Prérequis

• Une instance ASM version 1.22 ou ultérieure a été créée. Pour plus d'informations, consultez Créer une instance ASM.

• Plusieurs clusters ont été ajoutés à l'instance ASM. Pour plus d'informations, consultez Ajouter un cluster à une instance ASM. (Dans cet exemple, deux clusters sont ajoutés.)

• L'injection automatique du proxy sidecar est activée pour l'instance ASM. Pour plus d'informations, consultez la section « Activer l'injection automatique du proxy sidecar » de la rubrique Gérer les namespaces globaux.

• L'accès inter-cluster entre les services n'est disponible que si l'une des deux conditions suivantes est remplie :

  • La fonctionnalité de proxy DNS est activée dans l'instance ASM. Pour plus d'informations, consultez Utiliser le proxy DNS dans ASM. Cette méthode est recommandée.

  • Un service de destination identique à celui présent dans le cluster hébergeant le serveur est créé manuellement dans le cluster hébergeant le client.

Étape 1 : Associer une adresse IP élastique (EIP) au plan de contrôle de l'instance ASM

Si votre cluster du plan de données ne peut pas communiquer avec le Virtual Private Cloud (VPC) où réside votre instance ASM et que vous souhaitez connecter le plan de données au plan de contrôle de l'instance ASM via Internet, associez une EIP à l'instance SLB du point de terminaison Istio Pilot du plan de contrôle. Cela expose le point de terminaison Istio Pilot à Internet.

1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.

2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez ASM Instance > Base Information.

3. À droite de la page Basic Information, sélectionnez Istio Pilot Endpoint et cliquez sur Bind EIP.

Étape 2 : Configurer les paramètres réseau des clusters et activer les proxys de maillage inter-cluster

Vous pouvez spécifier un réseau logique pour chaque cluster. Les services appartenant au même réseau logique peuvent s'accéder directement. Les services situés sur différents réseaux logiques doivent utiliser des proxys de maillage inter-cluster pour communiquer entre eux.

1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.

2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Cluster & Workload Management > Kubernetes Clusters.

3. Cliquez sur Multi-cluster Network Configurations et configurez comme suit :

   • Définissez Homing Logical Network Name sur network1 pour ACK 1.

   • Définissez Homing Logical Network Name sur network2 pour ACK 2 et activez Enable Access Through Cross-cluster Mesh Proxy dans ACK 2.

   

Après avoir appliqué les configurations précédentes, ASM crée un proxy de maillage inter-cluster par défaut dans ACK 2. Ce proxy de maillage est associé à une EIP. Les services dans ACK 1 utilisent automatiquement ce proxy de maillage inter-cluster pour accéder aux services dans ACK 2, et le chiffrement mTLS (mutual Transport Layer Security) est activé par défaut pour ce chemin de communication.

Vous pouvez afficher la définition du proxy de maillage inter-cluster dans le fichier kubeconfig du cluster correspondant. Un proxy de maillage inter-cluster est nommé selon le format suivant : asm-cross-network-${ACK ID}. Vous pouvez ajuster les configurations d'un proxy de maillage inter-cluster, telles que les ressources et le nombre de réplicas, en fonction de vos besoins métier.

Étape 3 : Vérifier l'accès inter-cluster

Les configurations réseau précédentes prennent effet lorsque les pods d'application correspondants sont démarrés. Si un pod d'application est déjà démarré avant que vous ne modifiiez les configurations réseau, redémarrez-le.

1. Créez l'application sleep dans ACK 1. Exemple de contenu YAML :

   sleep.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

2. Créez l'application HTTPBin dans ACK 2. Exemple de contenu YAML :

   httpbin.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: httpbin
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: httpbin
     labels:
       app: httpbin
       service: httpbin
   spec:
     ports:
     - name: http
       port: 8000
       targetPort: 80
     selector:
       app: httpbin
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: httpbin
         version: v1
     template:
       metadata:
         labels:
           app: httpbin
           version: v1
       spec:
         serviceAccountName: httpbin
         containers:
         - image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/httpbin:0.1.0
           imagePullPolicy: IfNotPresent
           name: httpbin
           ports:
           - containerPort: 80

3. Accédez à l'application HTTPBin depuis le pod exécutant l'application sleep. (Connectez-vous au pod en vous basant sur les informations du fichier kubeconfig d'ACK 1.)

   1. Obtenez le nom du pod exécutant l'application sleep.

      kubectl get pod | grep sleep

   2. Exécutez la commande curl pour accéder à l'application HTTPBin depuis l'application sleep.

      kubectl exec ${Name of the pod running the sleep application} -- curl httpbin:8000/status/418

      La sortie suivante indique que l'accès a réussi :

        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100   135  100   135    0     0  16075      0 --:--:-- --:--:-- --:--:-- 16875
      
          -=[ teapot ]=-
      
             _...._
           .'  _ _ `.
          | ."` ^ `". _,
          \_;`"---"`|//
            |       ;/
            \_     _/
              `"""`

4. Vérifiez que l'application sleep utilise le proxy de maillage inter-cluster pour accéder à l'application HTTPBin.

   1. Consultez les journaux du pod exécutant l'application sleep. (Connectez-vous au pod en vous basant sur les informations du fichier kubeconfig d'ACK 1.)

      kubectl logs ${Name of the pod running the sleep application} -c istio-proxy | tail -1

      Le résultat de la commande suivante est renvoyé :

      {"authority_for":"httpbin:8000","bytes_received":"0","bytes_sent":"135","downstream_local_address":"xxx.xxx.xxx.xx:8000","downstream_remote_address":"xx.x.xxx.xxx:xxxxx","duration":"7","istio_policy_status":"-","method":"GET","path":"/status/418","protocol":"HTTP/1.1","request_id":"08dc43e9-60c8-4f2f-910a-b727172ce311","requested_server_name":"-","response_code":"418","response_flags":"-","route_name":"default","start_time":"2024-05-23T10:06:27.289Z","trace_id":"-","upstream_cluster":"outbound|8000||httpbin.default.svc.cluster.local","upstream_host":"xxx.xx.xxx.xxx:15443","upstream_local_address":"xx.x.xxx.xxx:60248","upstream_response_time":"7","upstream_service_time":"7","upstream_transport_failure_reason":"-","user_agent":"curl/8.1.2","x_forwarded_for":"-"}

      Le champ upstream_host identifie le service de destination auquel accède directement le pod exécutant l'application sleep. La sortie montre que l'accès est effectué sur le port 15443. Le port 15443 est le port dédié du proxy de maillage inter-cluster.

   2. Consultez les journaux du proxy de maillage inter-cluster. (Connectez-vous aux pods en vous basant sur les informations du fichier kubeconfig d'ACK 2.)

      Commencez par obtenir le pod exécutant le proxy de maillage inter-cluster.

      kubectl -n istio-system get pod | grep asm-cross-network
      
      istio-asm-cross-network-c0859be51XXX   1/1     Running   0          20h
      istio-asm-cross-network-c0859be51XXX   1/1     Running   0          20h

      La sortie indique que deux pods exécutent le proxy de maillage inter-cluster par défaut. Vous pouvez consulter les journaux de ces deux pods séparément. Leurs journaux sont similaires.

       kubectl logs istio-asm-cross-network-c0859be51XXX -n istio-system  | tail -1
      
      {"authority_for":"-","bytes_received":"xxxx","bytes_sent":"xxxx","downstream_local_address":"xx.xx.x.xx:15443","downstream_remote_address":"xx.xx.xx.xx:xxxxx","duration":"1568569","istio_policy_status":"-","method":"-","path":"-","protocol":"-","request_id":"-","requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local","response_code":"0","response_flags":"-","route_name":"-","start_time":"2024-05-23T08:41:16.618Z","trace_id":"-","upstream_cluster":"outbound_.8000_._.httpbin.default.svc.cluster.local","upstream_host":"xx.xx.xx.xxx:80","upstream_local_address":"xx.x.xx.xx:xxxxx","upstream_response_time":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"-","x_forwarded_for":"-"}