Se préparer à l'arrêt de l'agent de démarrage

L'agent de démarrage de conteneur qui déploie des conteneurs sur des instances Compute Engine lors de la création de VM est obsolète.

Ce document explique comment planifier la migration des conteneurs que vous avez créés lors de la création de la VM vers d'autres services Trusted Cloud by S3NS .

Informations générales

Qu'est-ce qu'un agent de démarrage de conteneur dans Compute Engine ?
L'agent de démarrage de conteneur vous permet de déployer et de configurer des conteneurs sur des instances Compute Engine ou sur des instances d'un groupe d'instances géré (MIG) lors de la création de la VM, et lance un conteneur Docker.
Pourquoi l'agent de démarrage du conteneur est-il obsolète ?

Grâce aux commentaires des clients, Trusted Cloud by S3NS améliore les options de déploiement des conteneurs. Nous avons abandonné l'agent de démarrage des conteneurs pour pouvoir vous proposer des options plus flexibles pour le déploiement de vos conteneurs.

Pour en savoir plus sur les options obsolètes, consultez Options obsolètes pour configurer des conteneurs sur des VM.

Quels sont les principaux jalons de cette obsolescence et que se passera-t-il si je ne prends pas de mesures d'ici la date limite ?

À partir du 31 juillet 2026, tous les workflows qui s'appuient sur l'agent de démarrage du conteneur ou les métadonnées d'instance gce-container-declaration cesseront de fonctionner.

À partir du 31 juillet 2027, Google cessera d'assurer la compatibilité avec l'agent de démarrage du conteneur. Aucune autre mise à jour ne sera fournie pour les VM en cours d'exécution qui utilisent les métadonnées gce-container-declaration. Vous exécuterez les charges de travail à vos propres risques, ce qui peut affecter votre workflow.

Nous vous recommandons de migrer les conteneurs vers d'autres solutions bien avant ces dates pour assurer une transition fluide.

Quand ne pourrai-je plus créer de VM ni de MIG avec des conteneurs déployés directement à l'aide des métadonnées gce-container-declaration ?

12 mois à compter de la notification initiale d'abandon, soit le 31 juillet 2026.

Quand ne pourrai-je plus exécuter de déploiements de conteneurs sur des VM ou des MIG qui utilisent les métadonnées gce-container-declaration ?

Nous cesserons de prendre en charge les charges de travail déployées à l'aide de l'agent de démarrage de conteneur 24 mois après la première notification d'arrêt, soit le 31 juillet 2027.

J'utilise cloud-init pour exécuter des conteneurs sur des VM. Suis-je concerné par ce changement ?

Non. Cet abandon n'a pas d'incidence sur les VM configurées à l'aide de cloud-init. Vous pouvez continuer à utiliser cloud-init pour configurer des instances. Pour en savoir plus, consultez Utiliser cloud-init avec la configuration Cloud.

Comment savoir si je suis concerné par ce changement ?

Si vous déployez un conteneur sur une VM lors de la création de la VM à l'aide de l'agent de démarrage de conteneur ou en spécifiant gce-container-declaration, vous êtes concerné par cet abandon. Pour vérifier si des instances sont concernées dans votre projet,exécutez la commande gcloud CLI suivante :

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Cette commande fournit la liste de toutes les instances de VM de votre projet qui contiennent la clé de métadonnées gce-container-declaration. La clé de métadonnées identifie de manière unique les VM concernées par l'arrêt. Si vous utilisez plusieurs projets, exécutez la commande sur tous les projets actifs.

Pour en savoir plus sur l'affichage des métadonnées de projet, consultez la documentation sur les métadonnées.

Si vous souhaitez vérifier une instance spécifique, exécutez la commande gcloud CLI suivante :

gcloud compute instances describe VM_NAME

Remplacez VM_NAME par le nom de l'instance de VM. Cette commande fournit toutes les informations d'une instance donnée, y compris les métadonnées. Si la clé de métadonnées gce-container-declaration s'affiche dans le résultat de la commande, cela signifie que votre VM est concernée par cette modification.

Existe-t-il un risque pour la sécurité ou la confidentialité du projet lors de la migration ?

Non. La sécurité et la confidentialité sont au cœur de tout ce que nous faisons chez Google. Lorsque vous utilisez nos scripts ou nos solutions gérées, vous pouvez configurer des paramètres de sécurité et de confidentialité spécifiques pour répondre à vos besoins. Pour en savoir plus, consultez le guide de migration.

Il existe

Quelles sont les solutions alternatives recommandées aux conteneurs sur Compute Engine, et comment choisir celle qui répond le mieux à mes besoins ?

Vous pouvez choisir l'une des options suivantes pour migrer votre conteneur :

  • Si vous souhaitez continuer à déployer des conteneurs sur des VM ou des MIG, ou exécuter des conteneurs pour les tests et le développement, ou exécuter une charge de travail composée d'une seule VM, utilisez des scripts de démarrage ou cloud-init.
  • Si vous avez des applications de conteneurs sans état et des jobs de petite ou moyenne taille, envisagez d'utiliser Cloud Run. Vous pouvez également utiliser des scripts de démarrage.
  • Si votre conteneur est un job par lot qui a un état final défini et qui nécessite des ressources de calcul supplémentaires, envisagez d'utiliser Batch. Vous pouvez également utiliser des scripts de démarrage.
  • Si vous avez besoin d'un contrôle et d'une évolutivité avancés, ou si vous ne pouvez pas répondre à vos exigences avec les autres options, envisagez d'utiliser GKE.

Pour obtenir des conseils et des recommandations détaillés sur les options de migration, consultez le guide de migration.

Pourquoi devrais-je envisager de migrer vers un service géré tel que Cloud Run, GKE ou Batch plutôt que d'utiliser un script de démarrage ?

Nous vous recommandons d'envisager de migrer vers des solutions de conteneurs telles que Google Kubernetes Engine, Cloud Run et Batch. Ces services gérés offrent des avantages considérables par rapport aux déploiements classiques basés sur des VM, y compris une évolutivité et une flexibilité améliorées, ainsi que des fonctionnalités de gestion avancées.

Voici quelques-uns des principaux avantages :

  • Réduisez la surcharge de gestion : en tant que services entièrement gérés,Trusted Cloudgère l'infrastructure sous-jacente (VM, correctifs, scaling). Cette approche permet de libérer du temps précieux pour le personnel et de réduire votre charge opérationnelle.
  • Mise à l'échelle automatique et élasticité : ces services ajustent automatiquement les ressources en fonction de la demande. Cela permet une meilleure utilisation des ressources et des économies potentielles par rapport au surprovisionnement des VM.
  • Réalisez des économies pour les charges inactives : contrairement aux VM, qui génèrent des coûts même lorsqu'elles sont inactives, les services gérés peuvent être plus rentables pour les applications dont le trafic est faible ou fluctuant.
  • Profitez de la disponibilité du niveau gratuit : GKE, Cloud Run et Batch proposent un niveau gratuit qui vous permet d'exécuter des charges de travail plus petites ou d'effectuer des tests sans frais potentiels.

Pour obtenir des conseils détaillés sur la migration, consultez le guide de migration.

Quels sont les coûts à prendre en compte pour chaque solution alternative et comment se comparent-ils à la configuration actuelle ?

Scripts de démarrage ou cloud-init pour le déploiement de conteneurs : l'utilisation de scripts de démarrage ou de cloud-init en remplacement direct ne modifie pas intrinsèquement vos coûts Compute Engine. Vous payez toujours les ressources de VM sous-jacentes.

Services gérés : le passage à des services tels que Cloud Run ou Batch peut permettre de réaliser des économies, en particulier pour les applications dont l'utilisation est variable. Contrairement aux VM qui sont facturées même lorsqu'elles sont inactives, ces services gérés peuvent être plus efficaces. De plus, les niveaux gratuits peuvent réduire davantage les coûts pour les charges de travail plus petites et temporaires.

Pour en savoir plus, consultez Comparer les options de déploiement de conteneurs. Les tarifs varient en fonction du service choisi et de votre configuration spécifique. Utilisez le simulateur de coût pour obtenir une estimation précise.

Cette obsolescence signifie-t-elle que les images Container-Optimized OS seront obsolètes et que, si nous voulons exécuter des conteneurs Docker sur des VM Compute Engine, nous devrons configurer notre propre modèle de VM ?

Non,les images Container-Optimized OS elles-mêmes ne sont pas abandonnées. Cette modification concerne le démarrage des conteneurs sur les VM utilisant Container-Optimized OS. Les versions plus récentes de Container-Optimized OS ne seront plus compatibles avec konlet, qui est l'agent de démarrage qui lance les conteneurs à l'aide de la clé de métadonnées gce-container-declaration. Cela signifie que les images Container-Optimized OS resteront disponibles et compatibles. Toutefois, vous devez mettre à jour votre VM pour qu'elle utilise un script de démarrage ou une configuration cloud-init afin de déployer des conteneurs au lieu d'utiliser la clé de métadonnées gce-container-declaration.

Processus de migration

Quelle est l'approche recommandée pour migrer les conteneurs vers les solutions alternatives ?

Nous vous recommandons de suivre les étapes suivantes pour votre migration :

  • Découvrez vos options : consultez le guide de migration pour découvrir d'autres façons d'exécuter vos conteneurs.
  • Planifiez votre migration à l'avance : pour assurer une transition en douceur, commencez à planifier la migration de vos déploiements de conteneurs actuels bien avant le 31 juillet 2026.
  • Préparez-vous pour les nouvelles charges de travail : assurez-vous que vos nouvelles charges de travail de conteneurs sont prêtes à s'exécuter sur des solutions alternatives d'ici le 31 juillet 2026, car le déploiement direct de conteneurs sur des VM ou des MIG ne sera plus possible.
  • Date limite de migration : assurez-vous que toutes vos charges de travail de conteneurs existantes sont migrées vers des solutions alternatives d'ici le 31 juillet 2027, date à laquelle la méthode de déploiement direct sera entièrement abandonnée.
Dois-je migrer vers l'une des solutions recommandées ou existe-t-il d'autres options ?

Nous vous permettons d'adopter la solution qui correspond le mieux à vos besoins commerciaux et qui est activement prise en charge. Des ressources telles que le guide de migration sont disponibles pour vous aider à choisir l'option la plus adaptée.

Dois-je sauvegarder ou exporter mes données dans le cadre du processus de migration ?

Bien que la sauvegarde ou l'exportation des données soient toujours des bonnes pratiques essentielles pour la sécurité des données et la continuité des activités, elles ne sont pas nécessaires pour ce processus de migration.

Combien de temps me faudra-t-il pour migrer vers l'une des alternatives ? Y a-t-il des facteurs qui pourraient affecter le temps que je devrai y consacrer ?

Script de démarrage du déploiement de conteneur : la configuration initiale et les tests à l'aide de scripts de démarrage devraient prendre environ une à deux heures. Les déploiements suivants ne devraient prendre que quelques minutes chacun.

Services gérés : opter pour des solutionsTrusted Cloud by S3NS telles que Cloud Run, Batch ou GKE, qui sont des offres PaaS sans serveur et entièrement gérées, peut nécessiter un investissement initial plus important en temps et en efforts. Cela est dû au changement fondamental qui s'opère entre une approche axée sur les VM (IaaS), où vous gérez l'infrastructure, et un modèle PaaS, où la plate-forme gère une grande partie de cette infrastructure. Cette adaptation peut nécessiter des modifications de votre application, par exemple pour s'assurer qu'elle est sans état. Toutefois, les avantages à long terme peuvent inclure des gains importants en termes d'efficacité opérationnelle, d'évolutivité et de rentabilité.

Pour obtenir des conseils sur cette transition, consultez le guide de migration.

Si je choisis de migrer vers une alternative, cela entraînera-t-il des interruptions ou des temps d'arrêt pour les projets, les VM, les services et les applications Trusted Cloud by S3NS  ?

En général, la transition vers la solution alternative recommandée est conçue pour être un processus sans temps d'arrêt.

Pour migrer des conteneurs de longue durée sur des VM Compute Engine, nous vous recommandons de configurer de nouvelles VM avec la configuration alternative et de basculer le trafic une fois qu'elles ont été testées, afin d'éviter toute interruption.

Quel est l'impact de cette migration sur ma configuration Terraform ?

Si vous utilisez Terraform ou une automatisation similaire pour créer ou mettre à jour des VM ou des MIG avec des conteneurs en définissant explicitement la clé de métadonnées gce-container-declaration, votre workflow cessera de fonctionner le 31 juillet 2026. Pour éviter toute interruption, vous devez mettre à jour votre configuration afin d'inclure un script de démarrage pour le déploiement de conteneurs et supprimer la dépendance de la clé de métadonnées gce-container-declaration. Pour obtenir des instructions détaillées sur la façon d'implémenter ce changement, consultez Migrer les conteneurs déployés sur des VM lors de la création de VM.

Assistance

Qui dois-je contacter dans Compute Engine si j'ai des questions sur le processus de migration ?
 Pour toute question ou si vous avez besoin d'aide, contactez l'assistance Google Cloud.
Quelles ressources sont disponibles pour m'aider à effectuer la migration et me fournir des conseils techniques ?
Cette FAQ, un guide de migration et l'assistance Google Cloud sont disponibles pour vous aider dans le processus de migration.