Mises à jour de la configuration pour la modernisation

Ce document décrit les mises à jour de configuration que vous devrez peut-être apporter à votre Cloud Service Mesh géré avant de moderniser votre maillage vers le plan de contrôle TRAFFIC_DIRECTOR à partir du plan de contrôle ISTIOD.

Pour en savoir plus sur le workflow de modernisation, consultez la page Modernisation du plan de contrôle géré.

Migrer des secrets Istio vers multicluster_mode

Les secrets multiclusters ne sont pas compatibles lorsqu'un cluster utilise le plan de contrôle TRAFFIC_DIRECTOR. Ce document explique comment passer des secrets multiclusters Istio à multicluster_mode.

Présentation des secrets Istio par rapport aux API déclaratives

La détection de point de terminaison multicluster Istio Open Source fonctionne en utilisant istioctl ou d'autres outils pour créer un secret Kubernetes dans un cluster. Ce secret permet à un cluster d'équilibrer la charge du trafic vers un autre cluster du réseau maillé. Le plan de contrôle ISTIOD lit ensuite ce secret et commence à acheminer le trafic vers cet autre cluster.

Cloud Service Mesh dispose d'une API déclarative pour contrôler le trafic multi-clusters au lieu de créer directement des secrets Istio. Cette API traite les secrets Istio comme un détail d'implémentation et est plus fiable que la création manuelle de secrets Istio. Les futures fonctionnalités de Cloud Service Mesh dépendront de l'API déclarative, et vous ne pourrez pas utiliser directement ces nouvelles fonctionnalités avec les secrets Istio. L'API déclarative est la seule voie à suivre.

Si vous utilisez des secrets Istio, passez à l'API déclarative dès que possible. Notez que le paramètre multicluster_mode dirige chaque cluster vers le trafic de tous les autres clusters du maillage. L'utilisation de secrets permet une configuration plus flexible, ce qui vous permet de configurer pour chaque cluster vers quel autre cluster il doit diriger le trafic dans le maillage. Pour obtenir la liste complète des différences entre les fonctionnalités compatibles de l'API déclarative et les secrets Istio, consultez la section Fonctionnalités compatibles à l'aide des API Istio.

Migrer des secrets Istio vers une API déclarative

Si vous avez provisionné Cloud Service Mesh à l'aide de la gestion automatique avec l'API de la fonctionnalité Parc, vous n'avez pas besoin de suivre ces instructions. Cette procédure ne s'applique que si vous avez effectué l'intégration à l'aide de asmcli --managed.

Notez que ce processus modifie les secrets qui pointent vers un cluster. Au cours de ce processus, les points de terminaison sont supprimés, puis réajoutés. Entre la suppression et l'ajout des points de terminaison, le trafic revient brièvement au routage local au lieu de l'équilibrage de charge vers d'autres clusters. Pour en savoir plus, consultez ce problème sur GitHub.

Pour passer des secrets Istio à l'API déclarative, procédez comme suit. Effectuez ces étapes en même temps ou l'une après l'autre sans tarder:

Activez l'API déclarative pour chaque cluster du parc pour lequel vous souhaitez activer la découverte de points de terminaison multiclusters en définissant multicluster_mode=connected. Notez que vous devez définir explicitement multicluster_mode=disconnected si vous ne souhaitez pas que le cluster soit détectable.

Utilisez la commande suivante pour activer la découverte de points de terminaison multiclusters dans un cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Utilisez la commande suivante pour désactiver la détection des points de terminaison pour un cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Supprimez les anciens secrets.

Une fois multicluster_mode=connected défini sur vos clusters, un nouveau secret est généré pour chaque cluster qui a également multicluster_mode=connected défini. Le secret est placé dans l'espace de noms istio-system et a le format suivant:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Le libellé istio.io/owned-by: mesh.googleapis.com sera également appliqué à chaque secret.

Une fois les nouveaux secrets créés, vous pouvez supprimer tous les secrets créés manuellement avec istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Une fois la migration effectuée, vérifiez les métriques de vos requêtes pour vous assurer qu'elles sont acheminées comme prévu.