Cloud Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Migrer du contrôleur de service canonique au sein du cluster vers le contrôleur de service canonique géré

Remarque:Les services canoniques sont automatiquement pris en charge dans les versions 1.6.8 et ultérieures de Cloud Service Mesh.

Ce guide décrit les étapes à suivre pour passer du contrôleur de service canonique dans le cluster au contrôleur de service canonique géré.

Le contrôleur de service canonique intégré au cluster a été abandonné et ne recevra plus de mises à jour. Bien que les déploiements existants du contrôleur dans le cluster continuent de fonctionner, nous vous recommandons vivement de migrer vers le contrôleur de service canonique géré afin de garantir la compatibilité avec les futures versions, l'accès aux dernières fonctionnalités et une assistance continue. Toutes les installations de Cloud Service Mesh avec asmcli à partir de la version 1.25 seront provisionnées avec le contrôleur de service canonique géré.

1. Activer la fonctionnalité de parc Cloud Service Mesh

Le contrôleur de service canonique géré est installé dans le cadre de la fonctionnalité de flotte Cloud Service Mesh, qui est activée à l'aide de la commande suivante:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID de votre projet hôte de parc. En général, FLEET_PROJECT_ID porte le même nom que le projet.

Notez que si vous envisagez d'enregistrer plusieurs clusters, l'activation de Cloud Service Mesh se produit au niveau du parc. Vous n'avez donc besoin d'exécuter cette commande qu'une seule fois.

Accorder des autorisations aux comptes de service Cloud Service Mesh

Si le projet de votre cluster est différent de votre projet hôte de parc, vous devez autoriser les comptes de service Cloud Service Mesh du projet de parc à accéder au projet de cluster.

Vous ne devez effectuer cette opération qu'une seule fois pour chaque projet de cluster. Si vous avez déjà configuré Cloud Service Mesh géré pour cette combinaison de projets de cluster et de parc, ces modifications ont déjà été appliquées et vous n'avez pas besoin d'exécuter les commandes suivantes.

Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet de cluster:

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

Remplacez CLUSTER_PROJECT_ID par l'ID du projet de votre cluster et FLEET_PROJECT_NUMBER par le numéro du projet de votre parc.

Pour déterminer le numéro de projet de votre flotte, consultez les instructions du document sur les projets Google Cloud.

2. Désactiver le contrôleur de service canonique du cluster

Le contrôleur de service canonique géré ne peut pas fonctionner avec le contrôleur de service canonique du cluster. Par conséquent, vous devez désactiver le contrôleur intégré au cluster.

Check for In-Cluster Controller (Vérifier la présence d'un contrôleur au sein du cluster) : vérifiez si le contrôleur canonique au sein du cluster est présent.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Supprimer le contrôleur dans le cluster: si le déploiement est détecté, vous pouvez le supprimer (et l'intégralité de l'espace de noms asm-system) en exécutant la commande suivante:
```
kubectl delete namespace asm-system
```

3. Vérifier que le contrôleur canonique géré est opérationnel

Le contrôleur de service canonique géré indique son état dans l'état de la fonctionnalité. Vous pouvez donc vérifier que l'installation fonctionne correctement en vérifiant l'état de la fonctionnalité:

Vérifier l'état de l'élément:récupérez l'état de l'élément à l'aide de la commande suivante:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Vérifier l'état:vérifiez l'état de votre cluster et assurez-vous que l'state.code est OK.
- Important:La transition vers l'état OK peut prendre jusqu'à 15 minutes. Attendez et réexécutez la commande.
- Ne passez à l'étape suivante que lorsque state.code est OK.
- Si state.code ne devient pas OK au bout de 15 minutes, consultez la section Résoudre les problèmes liés au contrôleur de service canonique géré pour obtenir des conseils de dépannage.
Exemple de résultat :
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
Vérifier que le contrôleur canonique géré fonctionne:vérifiez que le contrôleur canonique géré fonctionne correctement en déployant un pod avec un sidecar injecté, puis vérifiez si le contrôleur crée automatiquement le service canonique correspondant.
1. Créez un espace de noms dans lequel l'injection side-car automatique est activée:
```
kubectl create namespace NAMESPACE_NAME
```
  Suivez la section Activer l'injection side-car automatique pour activer l'injection side-car automatique dans l'espace de noms nouvellement créé.
2. Créez un fichier YAML nommé simple_pod.yaml avec le contenu suivant:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  Le libellé app détermine le nom du service canonique. Pour en savoir plus, consultez la section Définir un service canonique.
3. Déployez le pod à l'aide de la commande suivante. Remplacez NAMESPACE_NAME par le nom de l'espace de noms dans lequel vous avez activé l'injection side-car automatique.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. Vérifiez que le pod a été créé:
```
kubectl get pods -n NAMESPACE_NAME
```
  Exemple de résultat :
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note: vérifiez que la colonne "PRET" affiche 2/2. Cela indique que le conteneur principal et le proxy sidecar fonctionnent correctement. Si une autre valeur s'affiche, il est probable que l'injection side-car automatique ne soit pas activée pour l'espace de noms.
5. Vérifier la création du service canonique: exécutez la commande suivante pour lister tous les services canoniques de l'espace de noms. Vérifiez que le service canonique my-app est créé.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  Exemple de résultat :
```
  NAME          AGE
  my-app        3s
```
6. Nettoyage: supprimez le pod, le service canonique et l'espace de noms:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Dépannage :
- Si le service canonique requis n'est pas créé, consultez la section Résoudre les problèmes liés aux services canoniques dans Cloud Service Mesh.
- Si le problème persiste, vous pouvez revenir au contrôleur du cluster. Consultez la section Revenir au contrôleur de service canonique du cluster.

Revenir au contrôleur de service canonique du cluster

Si vous rencontrez des problèmes avec le contrôleur de service canonique géré, vous pouvez réinstaller le contrôleur du cluster à l'aide de la commande suivante:

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml

Étape suivante

Apprenez-en davantage sur les points suivants :