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. Pour évaluer automatiquement votre parc par rapport aux fonctionnalités compatibles et identifier les éventuels problèmes bloquants avant la modernisation, consultez le guide Comprendre la compatibilité de Cloud Service Mesh.

  3. 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.

  4. 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.

  5. Pour la modernisation gérée par le client : vous pouvez utiliser le guide Comprendre la compatibilité de Cloud Service Mesh pour déterminer la compatibilité avec l'implémentation du TRAFFIC_DIRECTOR plan de contrôle. Vous pouvez ensuite choisir quand déclencher la modernisation du parc.

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

  7. 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 seront prêts à ê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 savoir comment définir 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ées 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

Vous serez d'abord 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 de 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 (MODERNIZATION_WILL_BE_SCHEDULED). Pour en savoir plus sur la vérification des conditions, consultez Vérifier l'état de la modernisation.

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.

Cette notification est disponible dans les conditions d'état des fonctionnalités au niveau du cluster (MODERNIZATION_SCHEDULED). Pour en savoir plus sur la vérification des conditions, consultez Vérifier l'état de la modernisation.

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 seront 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 de n'importe quel cluster de ce parc.
  5. Finaliser la modernisation de ce parc, en supprimant éventuellement les composants basés sur Istiod.

Pour surveiller l'état de modernisation active de vos parcs, consultez Vérifier l'état de la modernisation.

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 d'attente d'au moins six jours ouvrables de temps de stabilisation est nécessaire avant que la modernisation d'un cluster ne soit marquée comme finalisée.

Pour surveiller l'état de modernisation active de vos clusters, consultez Vérifier l'état de la modernisation.

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.

Vérifier l'état de la modernisation

Vous pouvez surveiller l'état de modernisation de vos parcs et clusters en vérifiant les conditions d'état des fonctionnalités. Utilisez la commande Google Cloud CLI suivante :

gcloud alpha container fleet mesh describe --project FLEET_PROJECT_ID

Conditions au niveau du parc

Lorsque vous vérifiez l'état de votre parc, les conditions suivantes peuvent s'afficher sous state.servicemesh.conditions :

  • MODERNIZATION_WILL_BE_SCHEDULED: nous allons bientôt planifier la modernisation des clusters de ce parc pour utiliser l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.
  • MODERNIZATION_MODERNIZING: la modernisation est en cours pour un ou plusieurs clusters du parc.
  • MODERNIZATION_MODERNIZED: tous les clusters du parc ont été modernisés. Le parc est désormais en période d'attente pendant laquelle les rollbacks sont encore possibles.
  • MODERNIZATION_FINALIZED : la modernisation est terminée et finalisée. Le rollback n'est plus possible. Les clusters cessent de signaler MODERNIZATION_COMPLETED une fois cet état de parc atteint. Cet état sera signalé pendant au moins 30 jours après la fin de la migration.
  • MODERNIZATION_ROLLING_BACK_FLEET : un rollback au niveau du parc est en cours.

Conditions au niveau du cluster

Lorsque vous vérifiez l'état des clusters individuels du parc, les conditions suivantes peuvent s'afficher sous membershipStates.servicemesh.conditions :

  • MODERNIZATION_SCHEDULED: la modernisation de ce cluster a été planifiée à la date spécifiée dans les détails de la condition ou après.
  • MODERNIZATION_IN_PROGRESS: la modernisation de ce cluster est en cours.
  • MODERNIZATION_COMPLETED : la modernisation de ce cluster est terminée.
  • MODERNIZATION_ROLLING_BACK_CLUSTER: un rollback est en cours pour ce cluster.
  • MODERNIZATION_ABORTED: le cluster a été restauré avec succès sur le plan de contrôle hérité. Cet état est signalé pendant 24 heures après la fin du rollback.