Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

L'agent de démarrage de conteneur (konlet) 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 VM vers d'autres Cloud de Confiance by S3NS services.

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 VM et de lancer un conteneur Docker.

Pourquoi l'agent de démarrage de conteneur est-il obsolète ?

Suite aux commentaires de nos clients, Cloud de Confiance by S3NS nous avons amélioré les options de déploiement de conteneurs. Nous avons rendu l'agent de démarrage de conteneur obsolète pour vous offrir 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 la configuration de conteneurs sur des VM.

Quelles sont les étapes clés de cet abandon et que se passe-t-il si je ne prends pas de mesures avant la date limite ?

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

À partir du 31 juillet 2027, Google cessera de prendre en charge l'agent de démarrage de conteneur et aucune autre mise à jour ne sera fournie pour les VM en cours d'exécution qui utilisent les gce-container-declaration métadonnées. 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 en douceur.

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 après 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 ni 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 notification initiale d'abandon, soit le 31 juillet 2027.

Quel est l'impact de cet abandon sur ma configuration Terraform ?

Si vous utilisez Terraform ou une automatisation similaire pour créer ou mettre à jour des VM ou des MIG 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, mettez à jour votre configuration Terraform afin d'utiliser un script de démarrage pour le déploiement de conteneurs et supprimez la dépendance à la clé de métadonnées gce-container-declaration. Pour obtenir des instructions détaillées, consultez le guide de migration.

Cet abandon signifie-t-il que les images Container-Optimized OS seront abandonnées ?

Non, les images Container-Optimized OS ne sont pas abandonnées. La modification concerne la façon dont les conteneurs sont déployés sur les VM qui utilisent Container-Optimized OS. Les versions plus récentes de Container-Optimized OS ne prendront plus en charge konlet, l'agent de démarrage de conteneur qui utilise la clé de métadonnées gce-container-declaration pour déployer des conteneurs. Les images Container-Optimized OS restent disponibles et prises en charge. Toutefois, vous devez mettre à jour la configuration de votre VM pour utiliser un script de démarrage ou cloud-init afin de déployer des conteneurs au lieu de vous appuyer sur la clé de métadonnées gce-container-declaration.

J'utilise cloud-init pour exécuter des conteneurs sur des VM. Cette modification a-t-elle un impact sur moi ?

Non. Cet abandon n'a pas d'impact 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 Cloud config.

Comment savoir si cette modification a un impact sur moi ?

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, cet abandon a un impact sur vous. 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 qui sont concernées par l'abandon. 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, votre VM est concernée par cette modification.

Existe-t-il un moyen d'empêcher la création de VM qui utilisent l'agent de démarrage de conteneur ?

Oui. Les administrateurs d'organisation peuvent appliquer la contrainte de règle d'administration compute.managed.disableVmsWithContainerStartupAgent pour désactiver la création de ressources qui utilisent l'agent de démarrage de conteneur et la clé de métadonnées gce-container-declaration. Vous pouvez également appliquer cette règle en mode de simulation pour surveiller l'utilisation avant de bloquer la création de ressources. Pour en savoir plus, consultez Empêcher la création de VM qui utilisent les métadonnées de conteneur obsolètes.

La sécurité ou la confidentialité du projet sont-elles menacées pendant la migration ?

Non. La sécurité et la confidentialité sont des principes fondamentaux 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 pour les 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, exécuter des conteneurs à des fins de test et de 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 disposez d'applications de conteneur sans état et de tâches de petite à 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 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 les autres options ne répondent pas à vos besoins, 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 conteneur 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 les principaux avantages :

Réduction des frais de gestion : en tant que services entièrement gérés,Cloud de Confiance ils gèrent l'infrastructure sous-jacente (VM, application de correctifs, scaling). Cette approche libère du temps précieux pour le personnel et réduit votre charge opérationnelle.
Scaling 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.
Rentabilité pour les charges inactives : contrairement aux VM, qui entraînent 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 fluctuant ou faible.
Utilisation du niveau sans frais : GKE, Cloud Run et Batch proposent un niveau sans frais, ce qui vous permet d'exécuter des charges de travail plus petites ou d'effectuer des tests sans frais.

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 pour le déploiement de conteneurs ou cloud-init : 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 pour les ressources de VM sous-jacentes.

Services gérés : le passage à des services tels que Cloud Run ou Batch peut vous 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 sans frais 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 prix varient en fonction du service choisi et de votre configuration spécifique. Utilisez le simulateur de coût pour obtenir une estimation précise.

Cet abandon signifie-t-il que les images Container-Optimized OS seront abandonnées 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. La modification concerne la façon dont les conteneurs démarrent sur les VM qui utilisent Container-Optimized OS. Les versions plus récentes de Container-Optimized OS ne prendront plus en charge konlet, l'agent de démarrage de conteneur qui démarre 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 prises en charge. Toutefois, vous devez mettre à jour votre VM pour utiliser 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 des conteneurs vers les solutions alternatives ?

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

Comprendre vos options : consultez le guide de migration pour découvrir d'autres façons d'exécuter vos conteneurs.
Planifier 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éparer les nouvelles charges de travail : assurez-vous que vos nouvelles charges de travail de conteneur 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 finale : assurez-vous que toutes vos charges de travail de conteneur 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 supprimée.

Dois-je migrer vers l'une des solutions recommandées ou existe-t-il d'autres solutions que je peux utiliser ?

Nous vous offrons la possibilité d'adopter n'importe quelle solution qui correspond à 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.

La sauvegarde ou l'exportation de données est-elle requise dans le cadre du processus de migration ?

Bien que la sauvegarde ou l'exportation de données soit toujours une bonne pratique essentielle pour la sécurité des données et la continuité de l'activité, il ne s'agit pas d'une étape nécessaire pour ce processus de migration.

Combien de temps me faudra-t-il pour migrer vers l'une des alternatives, et existe-t-il des facteurs qui pourraient affecter mon engagement en termes de temps ?

Script de démarrage pour le déploiement de conteneurs: la configuration et les tests initiaux à l'aide de scripts de démarrage devraient prendre environ 1 à 2 heures. Les déploiements suivants ne devraient prendre que quelques minutes chacun.

Services gérés : opter pour Cloud de Confiance by S3NS des solutions 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 termes de temps et d'efforts. Cela est dû au changement fondamental d'une approche centrée sur les VM (IaaS) où vous gérez l'infrastructure, vers 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 vous assurer qu'elle est sans état, mais les avantages à long terme peuvent inclure des gains considérables 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 implique-t-il des interruptions ou des temps d'arrêt pour les Cloud de Confiance by S3NS projets, les VM, les services et les applications ?

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

Pour la migration de conteneurs de longue durée sur des VM Compute Engine, afin d'éviter les interruptions, 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.

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 à la clé de métadonnées gce-container-declaration. Pour obtenir des instructions détaillées sur la mise en œuvre de cette modification, consultez Migrer des 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 sont les ressources 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.