Modernisation du plan de contrôle géré

Vous pouvez moderniser vos flottes Cloud Service Mesh en passant de l'implémentation du plan de contrôle ISTIOD à l'implémentation TRAFFIC_DIRECTOR selon votre propre calendrier, ou laisser Google le planifier automatiquement.

Il existe deux façons de moderniser votre application. Vous pouvez également les combiner :

  • Modernisation déclenchée par le client (en libre-service) : vous initiez et contrôlez vous-même le calendrier exact de la modernisation du parc à l'aide de la Google Cloud CLI, indépendamment des plannings définis par Google.
  • Modernisation gérée par Google (par défaut) : Google évalue la compatibilité du parc et planifie automatiquement la modernisation dans votre organisation en fonction des périodes de maintenance et des notifications anticipées. Google attend que tous les parcs de votre organisation soient compatibles. Par conséquent, un seul parc incompatible bloquera votre modernisation.

Quel que soit le chemin que vous choisissez, vous devez effectuer les étapes de base suivantes pour moderniser votre plan de contrôle :

  1. Vérifier la compatibilité : activez les vérifications de compatibilité et comprenez la compatibilité de vos flottes avec la modernisation.
  2. Planifier et configurer votre modernisation : choisissez votre parcours, configurez l'ordre de déploiement du cluster et du parc, ou reportez le déploiement de certains parcs.
  3. Combler les lacunes de compatibilité : assurez-vous que vos flottes répondent à toutes les exigences de compatibilité avant de lancer la modernisation.
  4. Lancer la modernisation : déclenchez la modernisation à la demande du client selon votre calendrier ou attendez la planification par Google.
  5. Modernisation active du cluster : pendant les intervalles de maintenance configurés, les doubles plans de contrôle s'exécutent côte à côte, et les déploiements (charges de travail et passerelles) passent automatiquement au nouveau plan de contrôle. Vous devrez redémarrer manuellement les charges de travail StatefulSet et DaemonSet.
  6. Surveiller l'état, la période de stabilisation et la finalisation : surveillez la progression de l'état, résolvez les éventuels blocages, observez les charges de travail pendant la période de stabilisation (au moins six jours ouvrés), avec une assistance complète pour la restauration avant la finalisation au niveau du parc.

Vérifier la compatibilité de la flotte et combler les lacunes

Avant qu'un parc puisse être modernisé (que la modernisation soit déclenchée par le client ou par Google), il doit être vérifié comme étant compatible. Vous devez activer les rapports de compatibilité pour examiner les conditions de blocage potentielles et combler les lacunes de configuration. Pour en savoir plus, consultez Comprendre la compatibilité de Cloud Service Mesh.

  • Pour la modernisation pilotée par Google : Google ne planifiera la migration que pour les organisations dont tous les parcs non différés sont compatibles.
  • Pour la modernisation déclenchée par le client : vous devez vérifier que vos rapports sur le parc cible MODERNIZATION_COMPATIBLE avant de lancer la modernisation.

Les vérifications de compatibilité évaluent les configurations Istio CRD de votre parc, les annotations de pod, les dépendances d'infrastructure (telles que Workload Identity) et les paramètres d'échelle.

Planifier et configurer votre modernisation

Élaborez un plan de modernisation de votre ou vos parcs. Si vous ne le faites pas, la modernisation pilotée par Google sera appliquée par défaut. Vous devez prendre des mesures pour vous assurer que vos parcs non destinés à la production sont modernisés en premier et que vos parcs critiques sont modernisés en dernier. De plus, la modernisation pilotée par Google ne planifiera la modernisation de votre organisation que lorsque 100% des parcs non différés de l'ensemble de votre organisation seront compatibles. Votre modernisation pourrait donc être bloquée par des incompatibilités locales.

Avant de lancer la modernisation, examinez vos options et configurez vos paramètres de déploiement pour les parcs et clusters de votre organisation.

Parcours disponibles

Méthode Description Application idéale Champ d'application Prérequis Avis préalable Capacité de rollback
Modernisation déclenchée par le client Vous pouvez moderniser votre parc d'appareils flotte par flotte, selon votre propre calendrier. Contrôle précis du calendrier de modernisation du parc (vous décidez quand lancer et quand effectuer un rollback au niveau du parc). Utilisez votre système de surveillance des applications existant pour recevoir des alertes si un rollback est nécessaire. Flotte par flotte (FLEET_PROJECT_ID) La flotte cible doit être compatible avec la modernisation. N/A. Restauration immédiate en libre-service à l'aide de Google Cloud CLI.
Modernisation pilotée par Google (par défaut) Google planifie automatiquement la modernisation dans l'ensemble de votre organisation. Modernisation automatisée une fois que tous les parcs de votre organisation sont compatibles. Toute l'organisation Google Cloud (tous les parcs non différés). Tous les parcs non différés de l'organisation doivent être compatibles avec la modernisation. Notification de parc 14 jours ou plus et notification de cluster 24 heures ou plus avant le début. Google effectuera un rollback si la surveillance standardisée détecte une erreur. Vous devez contacter Cloud Customer Care si la surveillance de votre application affiche une erreur.

Gérer plusieurs parcs dans une organisation

Si votre organisation Google Cloud gère plusieurs flottes, vous n'avez pas besoin de choisir une seule approche pour toutes. Vous pouvez combiner des stratégies, par exemple :

  • Différer les flottes complexes ou critiques : épinglez des flottes spécifiques à l'ancienne implémentation à l'aide de --modernization-strategy deferred afin de les exclure de la planification gérée par Google pendant que vous corrigez les dépendances ou planifiez l'exécution déclenchée par le client.
  • Commencez par la modernisation déclenchée par le client sur certaines flottes : modernisez d'abord les flottes de test, de développement ou d'évaluation pour valider le comportement selon votre propre calendrier.
  • Autoriser Google à moderniser les flottes restantes : toutes les flottes compatibles et non différées restent activées pour la planification gérée par Google.

Différer la modernisation du parc (désactivation)

Pour exclure un parc individuel de la modernisation pilotée par Google (par exemple, pour effectuer une modernisation déclenchée par le client ultérieurement ou pour corriger des dépendances complexes), définissez sa stratégie sur DEFERRED :

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

Notez que l'ancien libellé de projet mesh-modernization-mode=manual reste respecté, mais --modernization-strategy deferred est recommandé. Les autres parcs non différés de votre organisation restent éligibles à la planification gérée par Google une fois qu'ils sont tous compatibles.

Configurer l'ordre de déploiement

Vous pouvez contrôler l'ordre de déploiement séquentiel dans vos clusters et vos flottes à l'aide du libellé mesh-modernization-order (early, default ou late).

Ordre de déploiement des clusters (s'applique aux deux parcours)

Si un parc contient plusieurs clusters, vous pouvez contrôler l'ordre dans lequel les clusters sont modernisés en appliquant le libellé mesh-modernization-order à chaque cluster. Lorsque vous ou Google déclenchez la modernisation d'un parc, chaque groupe de clusters est modernisé séquentiellement. Les étapes de modernisation automatisées doivent être effectuées sur le groupe actuel avant de passer au suivant :

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

Remplacez CLUSTER_NAME par le nom du cluster, LOCATION par son emplacement et VALUE par l'une des valeurs suivantes :

  • early : le cluster est modernisé lors de la première vague de modernisation.
  • default : le cluster est modernisé lors de la deuxième vague de modernisation.
  • late : le cluster est modernisé lors de la troisième et dernière vague de modernisation.

Ordre de déploiement du parc (uniquement géré par Google)

Dans les organisations comportant plusieurs parcs en cours de modernisation par Google, vous pouvez contrôler l'ordre dans lequel Google modernise vos parcs en définissant le libellé au niveau du projet sur le projet hôte du parc :

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

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte du parc et VALUE par l'une des valeurs suivantes :

  • early : la flotte est modernisée lors de la première vague de modernisation.
  • default : la flotte est modernisée lors de la deuxième vague de modernisation.
  • late : le parc est modernisé lors de la troisième et dernière vague de modernisation.

Google termine la modernisation de chaque niveau de parc avant de passer au suivant : d'abord le niveau précoce, puis le niveau par défaut (et sans libellé), puis le niveau tardif. Les flottes marquées comme différées ne sont pas incluses dans cet ordre.

Par exemple, vous pouvez définir vos parcs non destinés à la production sur early, un parc particulièrement critique sur late et laisser les autres sur la valeur par défaut.

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

Modernisation déclenchée par le client (libre-service)

La modernisation déclenchée par le client vous permet de contrôler directement le moment où la modernisation commence pour une flotte individuelle.

Déclencher la modernisation du parc

Une fois que votre parc cible génère des rapports MODERNIZATION_COMPATIBLE, déclenchez la modernisation à l'aide de la commande suivante :

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

  • Intervalles de maintenance : Google respecte les intervalles et les exclusions de maintenance configurés pour les clusters. La modernisation du cluster commence lors du prochain intervalle de maintenance ouvert du cluster.
  • Ordre des clusters : si vous avez configuré des libellés mesh-modernization-order sur vos clusters, Google respecte cet ordre.

Suivre la progression

Suivez les instructions de la section Vérifier l'état de la modernisation pour surveiller la progression de la modernisation du parc et des clusters.

Restaurer une modernisation déclenchée par un client

Si vous détectez des problèmes lors de la modernisation active du cluster ou pendant la période de stabilisation du parc (avant la finalisation au niveau du parc), vous pouvez déclencher un rollback immédiat :

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

Votre parc restera dans l'état différé, c'est-à-dire qu'il ne sera pas pris en compte pour la modernisation pilotée par Google. Lorsque vous êtes prêt à réessayer la modernisation, réexécutez la commande pour déclencher la modernisation du parc.

Modernisation pilotée par Google (par défaut automatique)

Si vous n'initiez pas la modernisation déclenchée par le client, Google gère automatiquement la modernisation dans votre organisation.

Planification à l'échelle de l'organisation

Google surveille en permanence vos parcs. Une fois que tous les parcs compatibles avec le maillage de votre organisation (à l'exception des parcs différés) sont compatibles avec la modernisation, Google planifie la modernisation de votre organisation.

Notifications anticipées et programmation

Google fournit deux niveaux de notification préalable avant de commencer la modernisation :

Notification au niveau du parc

Vous serez d'abord averti lorsque vos flottes auront été identifiées comme compatibles avec la modernisation et sélectionnées pour une modernisation pilotée par Google à l'avenir.

  • La modernisation de votre cluster peut commencer au plus tôt 14 jours après le premier jour ouvrable du mois suivant votre notification. Par exemple, si Google détermine que votre organisation est prête le 10 janvier 2027, nous vous informerons d'ici le 31 janvier 2027 que la date de début de la modernisation la plus proche est le 15 février 2027.

  • Vous recevrez une notification simultanément pour chacun des parcs de votre organisation (à l'exception de ceux que vous avez différés). Cette notification est disponible dans les conditions d'état des fonctionnalités au niveau du parc (MODERNIZATION_WILL_BE_SCHEDULED).

Notification au niveau du cluster

Vous serez informé, au niveau du cluster, de la date de début estimée de la modernisation du cluster par Google, au moins un jour (24 heures) avant le début de la modernisation.

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

Demander une restauration pour la modernisation pilotée par Google

Si des problèmes surviennent lors de la modernisation ou de la période de stabilisation sur un parc de modernisation géré par Google, contactez Cloud Customer Care pour demander une restauration.

Ce qui se passe pendant la modernisation active

Cette section décrit ce qui se passe lors de la modernisation active des parcs et des clusters.

Moderniser les parcs

Pour chaque parc en cours de modernisation (qu'elle soit initiée par Google ou par le client), nous activons la nouvelle implémentation du plan de contrôle pour tous les clusters en fonction de l'ordre (early → default → late).

Une fois le plan de contrôle activé pour tous les clusters, nous transférons le trafic vers la nouvelle implémentation du plan de contrôle pour tous les clusters en fonction de l'ordre (early → default → late).

Consultez Vérifier l'état de la modernisation du parc pour connaître l'état actuel.

Période de stabilisation du parc

Une fois le trafic transféré pour tous les clusters, le parc entre dans une période de stabilisation. Le parc reste en période de stabilisation (MODERNIZATION_MODERNIZED) pendant au moins six jours ouvrés après la modernisation de tous les clusters, avant de passer à MODERNIZATION_FINALIZED. La capacité de rollback complet est conservée tout au long de la période de stabilisation. Une fois la modernisation terminée, il n'est plus possible d'annuler l'opération, et les composants ISTIOD peuvent être supprimés.

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. Les tâches suivantes sont traitées de manière sécurisée et contrôlée :

  1. Activez la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à ce qu'elle soit terminée. Tenez compte des remarques suivantes :
  2. Transférez le trafic vers la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à la fin. Tenez compte des remarques suivantes :
    • Les pods gérés par le déploiement Kubernetes et qui comportent des proxys Cloud Service Mesh sont redémarrés pour 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. Redémarrages manuels de charges de travail pour les non-déploiements (action du client requise).

    • Google redémarre automatiquement les charges de travail gérées par les déploiements Kubernetes. Les charges de travail gérées par d'autres types de ressources Kubernetes, telles que les StatefulSets et les DaemonSets, doivent être redémarrées manuellement.
    • Redémarrez ces charges de travail une fois que l'état du cluster indique MODERNIZATION_COMPLETED (c'est-à-dire lorsque le cluster est en période de stabilisation).
    • Vous devez redémarrer ces charges de travail avant la finalisation de la modernisation du parc. Sinon, ces proxys resteront connectés à l'ancien plan de contrôle Istiod, dont la suppression est prévue.
    • Redémarrez les charges de travail à l'aide d'approches Kubernetes standards, telles que kubectl rollout restart ....

  4. Une fois que toutes les charges de travail d'un cluster ont été migrées, le cluster attend la période de stabilisation du parc.

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

Vérifier l'état de la modernisation et prendre des mesures

Vous pouvez surveiller la progression de la modernisation de vos flottes et clusters à l'aide de la Google Cloud CLI :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

Le résultat est semblable à :

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

L'état de la modernisation est indiqué dans les champs state.servicemesh.conditions (au niveau du parc) et membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (au niveau du cluster) :

État d'une modernisation réussie du parc

Lors d'une modernisation réussie du parc, l'état du parc commence par MODERNIZATION_MODERNIZING.

Chaque cluster passerait ensuite par les états suivants :

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • MODERNIZATION_COMPLETED

Une fois que tous les clusters du parc ont terminé leur modernisation, le parc passe par les états suivants :

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

Rollbacks

La modernisation pilotée par Google surveille l'état et la préparation de votre déploiement tout au long du processus de modernisation. Nous déclencherons automatiquement un rollback si nous détectons des problèmes. Si vous détectez un problème, contactez le Cloud Customer Care pour demander une restauration.

Pour la modernisation déclenchée par le client, vous pouvez déclencher une restauration à tout moment.

Lors d'une restauration, le parc affiche l'état MODERNIZATION_ROLLING_BACK_FLEET et le cluster affiche l'état MODERNIZATION_ROLLING_BACK_CLUSTER.

Une fois la restauration d'un cluster terminée, l'état MODERNIZATION_ABORTED s'affiche temporairement.

Gérer les erreurs et les blocages (déclenchés par le client uniquement)

Lors de la modernisation déclenchée par le client, si un cluster rencontre un problème qui l'empêche de progresser, son état passe à MODERNIZATION_STALLED. Google ne déclenchera pas de rétablissement pour la modernisation déclenchée par le client. Vous devez trier le problème et décider de le corriger ou de déclencher une restauration.

Lorsqu'un cluster signale MODERNIZATION_STALLED, examinez les détails de la condition pour obtenir un lien direct vers la section d'erreur concernée :

Erreurs nécessitant une action de l'utilisateur

Si nous détectons une configuration de maillage ou de cluster incompatible, nous interromprons la modernisation. Assurez-vous que les rapports de compatibilité sont activés et examinez les conditions au niveau du parc et du cluster pour identifier les éventuelles lacunes, comme décrit dans Comprendre la compatibilité de Cloud Service Mesh.

  • Nouvelle tentative immédiate : dès que le blocage est résolu, nous détectons le changement et reprenons immédiatement la modernisation, sans attendre le prochain intervalle de maintenance.

Erreurs internes

Les problèmes liés aux services Google internes sont examinés par les ingénieurs Google, qui reprendront votre modernisation si possible. Notez que la modernisation peut reprendre en dehors d'un intervalle de maintenance, tout comme pour les erreurs pouvant être résolues par l'utilisateur. Pour éviter cela, vous pouvez déclencher une restauration.

Si votre modernisation est bloquée depuis plus de 24 heures et qu'aucune incompatibilité n'est présente, contactez l'assistance Cloud Customer Care pour en savoir plus ou déclenchez une restauration si les charges de travail de production sont concernées.

Documentation de référence sur les conditions au niveau du parc

Condition Description
MODERNIZATION_COMPATIBLE Le parc est compatible avec la nouvelle implémentation du plan de contrôle.
MODERNIZATION_WILL_BE_SCHEDULED Modernisation pilotée par Google : tous les parcs non différés de l'organisation sont compatibles et ont été mis en file d'attente pour la planification.
MODERNIZATION_MODERNIZING La modernisation est en cours pour un ou plusieurs clusters du parc.
MODERNIZATION_MODERNIZED La modernisation active est terminée pour tous les clusters. Le parc est en période de test.
MODERNIZATION_FINALIZED La modernisation est terminée et finalisée. Les anciens composants Istiod seront supprimés. Le rollback n'est plus possible.
MODERNIZATION_ROLLING_BACK_FLEET Une restauration au niveau de la flotte est en cours.

Documentation de référence sur les conditions au niveau du cluster

Condition Description
MODERNIZATION_SCHEDULED La modernisation du cluster est prévue à la date spécifiée dans la condition ou après. Si des intervalles/exclusions de maintenance sont configurés pour votre cluster, la date indiquera l'intervalle de maintenance cible.
MODERNIZATION_PREPARING Activer la nouvelle implémentation du plan de contrôle.
MODERNIZATION_PREPARED La nouvelle implémentation du plan de contrôle est activée. La migration de la charge de travail n'a pas encore commencé.
MODERNIZATION_MIGRATING_WORKLOADS Le cluster migre activement les charges de travail vers la nouvelle implémentation du plan de contrôle.
MODERNIZATION_COMPLETED La modernisation du cluster est terminée et il est en période de stabilisation.
MODERNIZATION_STALLED La modernisation est bloquée en raison d'une erreur (déclenchée par le client uniquement). Consultez les détails de la condition pour trouver une solution.
MODERNIZATION_ROLLING_BACK_CLUSTER Le cluster est en cours de rétablissement.
MODERNIZATION_ABORTED Le cluster a été rétabli sur l'ancien plan de contrôle. Signalé pendant une courte période.