Modernisation du plan de contrôle géré

Présentation

Google mettra progressivement à jour les parcs existants qui utilisaient l'implémentation du plan de contrôle géré ISTIOD pour utiliser l'implémentation TRAFFIC_DIRECTOR. Par défaut, Google migrera automatiquement vos parcs, mais vous pouvez choisir d'effectuer la migration vous-même. Pour vérifier le plan de contrôle utilisé par votre parc, consultez Vérifier l'implémentation du plan de contrôle.

Tenez compte des points suivants lorsque vous préparez votre parc à la modernisation :

  1. Pour vous préparer à la modernisation, vous pouvez contrôler le processus de deux manières :

    • Migration automatique gérée par Google (par défaut) : vous pouvez personnaliser l'ordre dans lequel vos clusters sont modernisés en suivant les instructions de la section Modernisation gérée par Google.

    • Migration gérée par le client (facultatif) : vous pouvez choisir de moderniser vous-même vos parcs en les étiquetant conformément aux instructions de la section Modernisation gérée par le client.

  2. La modernisation gérée par Google est l'option par défaut. Avec cette option, Google détermine quand vos parcs sont prêts à être modernisés. Google planifie la modernisation de vos parcs et vous en informe avant de commencer le processus.

  3. La modernisation d'un cluster redémarre les charges de travail qui comportent des proxys. Cela ne devrait pas entraîner de temps d'arrêt si vous suivez les bonnes pratiques Kubernetes. De plus, Google déclenchera la modernisation pendant un intervalle demaintenance , si vous en avez configuré un. Une fois lancée, elle s'exécute jusqu'à la fin, avec un temps de stabilisation supplémentaire de six jours avant d'être marquée comme finalisée. Si votre surveillance détecte des problèmes, vous pouvez demander un rollback.

  4. Pour la modernisation gérée par le client, Google vous informe lorsque vos parcs sont prêts à être modernisés. Vous pouvez ensuite choisir quand déclencher la modernisation, cluster par cluster. Une fois l'opération terminée, vous marquez la modernisation de chaque parc comme terminée.

  5. Une fois un parc modernisé, Google supprime tous les composants basés sur Istiod.

  6. L'implémentation du plan de contrôle TRAFFIC_DIRECTOR nécessite que votre cluster soit enregistré dans un parc avec la fonctionnalité de maillage activée. Si vous avez effectué l'intégration à l'aide d'outils hérités, Google enregistrera automatiquement votre cluster dans le parc de son projet à l'aide de l'API d'appartenance gkehub.googleapis.com. Si vous disposez d'une automatisation qui annule l'enregistrement d'un cluster, vous devez la supprimer avant la modernisation.

Modernisation gérée par Google

Cette option est sélectionnée par défaut si vous n'étiquetez pas vos parcs pour la modernisation gérée par le client. Google surveillera vos parcs pour déterminer quand ils pourront être modernisés en toute sécurité. Lorsque tous les parcs compatibles avec le maillage de votre organisation seront prêts, la modernisation de votre organisation sera planifiée.

Plusieurs parcs

Si votre organisation possède plusieurs parcs avec Cloud Service Mesh géré, vous pouvez contrôler l'ordre dans lequel Google modernise vos parcs en définissant un libellé de projet mesh-modernization-order sur l'une des valeurs suivantes : early, default ou late. Google terminera la modernisation de chaque groupe avant de commencer la modernisation d'un parc du groupe suivant. Les parcs pour lesquels vous avez opté pour la modernisation gérée par le client ne seront pas pris en compte dans cet ordre.

Utilisez la commande suivante pour définir le libellé mesh-modernization-order d'un parc :

gcloud alpha projects update FLEET_PROJECT_ID --update-labels="mesh-modernization-order=VALUE"

Pour obtenir des instructions sur la définition des libellés de projet à l'aide de la console ou de l'API REST, consultez le document Créer et gérer des libellés.

Si vous n'utilisez pas d'organisations, vos parcs seront planifiés et modernisés indépendamment, et vous ne pourrez pas contrôler l'ordre. Google Cloud

Maillages multiclusters

Si un parc comporte plusieurs clusters utilisant Cloud Service Mesh géré, vous pouvez contrôler l'ordre dans lequel Google modernise les clusters en définissant le libellé de cluster mesh-modernization-order sur l'une des valeurs suivantes : early, default ou late. Google commencera la modernisation de chaque groupe et attendra la fin des étapes de modernisation automatisée avant de commencer la modernisation d'un cluster du groupe suivant. Notez que cet ordre ne s'appliquera qu'au sein d'un parc et n'affectera pas les autres parcs de votre organisation qui pourraient être modernisés en parallèle.

Utilisez la commande suivante pour définir le libellé mesh-modernization-order d'un cluster :

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

Notifications et planification

Cette section explique comment vous serez informé de la modernisation à venir de vos parcs et clusters.

Notification indiquant que la modernisation sera bientôt planifiée

Tout d'abord, vous serez informé lorsque vos parcs auront été sélectionnés pour la modernisation gérée par Google au cours des prochaines semaines.

Cette notification sera envoyée avant le premier jour ouvrable du mois aux États-Unis. La date de début de la modernisation du cluster la plus proche possible est 14 jours après le premier jour ouvrable du mois aux États-Unis. Google fera de son mieux pour commencer la première modernisation du cluster pour votre organisation d'ici la fin du mois calendaire suivant. Par exemple, les notifications seront en place avant le 1er avril 2025, les modernisations de cluster pourront commencer à partir du 15 avril 2025, et la première modernisation de votre cluster devrait commencer avant le 31 mai 2025.

Vous recevrez une notification simultanément pour chacun des parcs de votre organisation (à l'exception de ceux pour lesquels vous avez opté pour la modernisation gérée par le client).

Cette notification est disponible dans les conditions d'état des fonctionnalités au niveau du parc. Utilisez la commande Google Cloud CLI suivante pour vérifier la notification :

gcloud alpha container fleet mesh describe --project $FLEET_PROJ

Une fois le parc planifié, une condition s'affiche avec code: MODERNIZATION_WILL_BE_SCHEDULED et des details semblables à ce qui suit :

state:
  servicemesh:
    conditions:
      - code: MODERNIZATION_WILL_BE_SCHEDULED
        details: We will soon schedule clusters in this fleet to be modernized to use the TRAFFIC_DIRECTOR
          control plane implementation. Please confirm your fleet and cluster preferences prior to
          scheduling. Cluster modernization dates will be on or after 2025-03-17.
        documentation_link: ...
        severity: INFO

Notification au niveau du cluster indiquant que la modernisation est planifiée

Vous serez informé, au niveau du cluster, de la date de début estimée de la modernisation gérée par Google pour ce cluster, au moins un jour avant le début de la modernisation du cluster.

Après la notification au niveau du parc, vous obtenez une planification beaucoup plus précise de la modernisation des clusters individuels.

Les notifications sont disponibles dans les conditions d'état des fonctionnalités au niveau du cluster. Utilisez la commande Google Cloud CLI suivante pour vérifier la notification :

gcloud container hub mesh describe --project=PROJECT_ID

Vous verrez des résultats semblables à ce qui suit :

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after 2025-03-17.
        documentationLink: ...
        severity: INFO

Modernisation active pour la migration gérée par Google

Cette section décrit les étapes de la modernisation gérée par Google.

Moderniser les parcs

Google déclenchera la modernisation active de chacun des parcs de votre organisation. Cela signifie que les étapes suivantes sont exécutées pour chaque parc :

  1. Moderniser tous les clusters avec mesh-modernization-order défini sur early.
  2. Moderniser tous les clusters avec mesh-modernization-order défini sur default ou non spécifié.
  3. Moderniser tous les clusters avec mesh-modernization-order défini sur late.
  4. Attendre que la modernisation de chaque cluster soit marquée comme finalisée. Cela signifie attendre au moins six jours ouvrables après le redémarrage du dernier pod dans n'importe quel cluster de ce parc.
  5. Finaliser la modernisation de ce parc, en supprimant éventuellement les composants basés sur Istiod.

Moderniser un cluster

Lors de la modernisation active d'un cluster, les deux implémentations du plan de contrôle sont exécutées temporairement côte à côte, et les tâches suivantes sont traitées de manière sécurisée et contrôlée :

  1. Activer la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster et que vous utilisez la modernisation gérée par Google, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à la fin. Notez les points suivants :
  2. Transférer le trafic vers la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster et que vous utilisez la modernisation gérée par Google, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à la fin. Notez les points suivants :
    • Les pods gérés par le déploiement Kubernetes qui comportent des proxys Cloud Service Mesh sont redémarrés afin qu'ils se reconnectent au nouveau plan de contrôle.
    • Les pods sont redémarrés par vagues de plus en plus importantes, avec un temps de stabilisation après chaque vague pour la surveillance.
  3. Un délai de stabilisation d'au moins six jours ouvrables est nécessaire avant que la modernisation d'un cluster ne soit marquée comme finalisée.

Utilisez la commande Google Cloud CLI suivante pour vérifier l'état de la modernisation active :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Une condition semblable à l'une des suivantes s'affiche dans le champ membershipStates par cluster :

...
membershipStates:
  projects/FLEET_PROJ/locations/us-central1/memberships/MEMBERSHIP:
    servicemesh:
      conditions:
      - code: MODERNIZATION_IN_PROGRESS
        details: ...
        documentationLink: ...
        severity: INFO
...
      # If you see this, see instructions provided in the details and documentationLink fields.
      - code: MODERNIZATION_ACTION_REQUIRED
        details: [details about required actions]
        documentationLink: [link to documentation for required actions]
        severity: WARNING
...
      - code: MODERNIZATION_COMPLETED
        details: ...
        documentationLink: ...
        severity: INFO

Modernisation gérée par le client

Vous pouvez choisir de contrôler vous-même le moment exact de la modernisation au niveau du parc. Pour ce faire, appliquez un libellé au projet hôte du parc à l'aide de la commande suivante :

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-mode=manual"

Notez que si votre Google Cloud organisation possède plusieurs parcs, tout parc non étiqueté sera planifié pour la modernisation gérée par Google.

Une fois votre parc éligible à la modernisation, vous recevrez une notification dans l'état des fonctionnalités au niveau du parc. Vous devez déclencher la modernisation dans les trois mois suivant la réception de cette notification.

Consultez les bonnes pratiques de configuration requises suivantes pour préparer votre cluster à la modernisation. Abonnez-vous au flux des notes de version de Cloud Service Mesh pour recevoir des notifications.