Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Migrer et déployer des applications sur des clusters GKE Autopilot
Pour déployer vos charges de travail de conteneurs migrés vers des clusters GKE Autopilot, vous devez suivre la même procédure que pour l'architecture existante.
Les seules modifications sont les suivantes :
Vous devez définir v2kServiceManager sur true dans le plan de migration avant de générer les artefacts de conteneur.
Vous devez examiner le nouveau fichier services-config.yaml et apporter des modifications aux services d'initialisation. Consultez la page Utiliser services-config.yaml.
Pour effectuer une migration, procédez comme suit :
Téléchargez le plan de migration. Le plan de migration est représenté par un objet AppXGenerateArtifactsFlow.
Par exemple, pour une migration nommée "my-migration" :
migctl migration get my-migration
Ouvrez le plan de migration téléchargé, my-migration.yaml, dans un éditeur de texte.
Vérifier le gestionnaire de services Linux amélioré L'option v2kServiceManager est définie sur true par défaut. Cependant, si Migrate to Containers détecte un service système non compatible avec le gestionnaire de services, vous êtes averti et l'option v2kServiceManager est définie sur false.
Lorsque l'option est false, la migration utilise un ancien environnement d'exécution compatible avec votre service.
L'alerte suivante est fournie avec le service non compatible :
Service is not supported by v2k service manager, therefore legacy runtime
will be used instead of v2k service manager, and migrated workload would
not fit running on Autopilot clusters of Cloudrun.
Lorsqu'un service non compatible est détecté, vous pouvez également définir manuellement l'option sur true.
Dans cette instance, vous pouvez choisir de conserver le service non compatible sur l'image générée où il ne s'exécutera pas, ou d'exclure le service en le supprimant du plan de migration.
Pour activer le nouveau gestionnaire de services, définissez l'option sur true :
v2kServiceManager:true
Effectuez toutes les autres personnalisations nécessaires à votre migration, comme décrit dans la section Personnaliser le plan de migration.
Une fois les modifications terminées, enregistrez le fichier modifié.
Modifiez le nouveau fichier services-config.yaml pour configurer les propriétés d'initialisation du conteneur. Enregistrez le fichier et recréez votre image de conteneur pour appliquer les modifications.
Exemple : Déploiement du conteneur de démarrage rapide sur un cluster Autopilot
Migrez un conteneur contenant un serveur Web simple à l'aide du guide de démarrage rapide actuel, puis déployez-le sur un cluster Autopilot. Les seules modifications que vous devez apporter au processus de démarrage rapide sont les suivantes :
À l'étape 3 de la migration de la VM, où vous examinez le plan de migration, définissez l'annotation v2kServiceManager sur true dans le plan de migration, puis enregistrez le plan :
v2kServiceManager:true
Dans la section Déployer la charge de travail migrée, créez un cluster GKE Autopilot, puis connectez-vous au cluster avant de déployer le conteneur :
Modifications apportées à l'objet CRD AppXGenerateArtifactsFlow
Si vous utilisez des fichiers CRD pour contrôler votre migration, modifiez le fichier CRD AppXGenerateArtifactsFlow pour définir v2kServiceManager sur true. Pour en savoir plus sur l'utilisation de fichiers CRD pour contrôler la migration, consultez la section Personnaliser un plan de migration.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Migrate and deploy applications to GKE Autopilot clusters\n=========================================================\n\nTo deploy your migrated container workloads to GKE Autopilot clusters,\nyou use the same procedure to migrate your workloads as you use for the existing architecture.\nThe only changes are that:\n\n- You have to set `v2kServiceManager` to `true` in the migration plan\n before you generate the container artifacts.\n\n- You have to review the new `services-config.yaml` file and make any edits to the\n initialization services. See [Using services-config.yaml](/migrate/containers/docs/services-config).\n\nTo perform a migration:\n\n1. [Install Migrate to Containers version 1.15.0](/migrate/containers/docs/install-overview).\n\n2. [Add a migration source](/migrate/containers/docs/adding-a-migration-source) and [create a migration](/migrate/containers/docs/creating-a-migration)\n as you do today with the existing runtime.\n\n3. [Customize your migration plan](/migrate/containers/docs/customizing-a-migration-plan) as necessary.\n\n | **Note:** Prior to Migrate to Containers 1.10, use of the enhanced Linux service manager was disabled by default. If you are using Migrate to Containers 1.9 or older, you should have `v2kServiceManager` set to `true` in your migration plan (`my-migration.yaml`). If the enhanced Linux service manager is disabled for you, check your `services.yaml` file for comments about services that may not work with your new runtime. If you would like to include any of the disabled services, contact your support channel.\n 1. Download the migration plan. The migration plan is represented by\n [AppXGenerateArtifactsFlow](https://github.com/GoogleCloudPlatform/migrate-to-containers/blob/main/references/crds/m2c-crds.md#appxgenerateartifactsflow).\n\n For example, for a migration named \"my-migration\": \n\n ```\n migctl migration get my-migration\n ```\n 2. Open the downloaded migration plan, `my-migration.yaml`, in a text editor.\n\n 3. Verify the enhanced Linux service manager. The `v2kServiceManager` flag is\n set to `true` by default. However, if Migrate to Containers\n detects a system service that is not supported by the service\n manager, you will be alerted and the `v2kServiceManager` flag will be set to `false`.\n When the flag is `false` the migration will use a legacy runtime which supports your\n service.\n\n The following alert is provided alongside the unsupported service: \n\n ```\n Service is not supported by v2k service manager, therefore legacy runtime\n will be used instead of v2k service manager, and migrated workload would\n not fit running on Autopilot clusters of Cloudrun.\n ```\n\n When an unsupported service is found, you can also choose to manually set the flag to `true`.\n In this instance, you can either choose to keep the unsupported service on the generated image\n where it may not run or you can exclude the service by removing it from the migration plan.\n\n To enable the new service manager, reset the flag to `true`: \n\n ```yaml\n v2kServiceManager: true\n ```\n 4. Perform any other customizations necessary for your migration as described\n in [Customize the migration plan](/migrate/containers/docs/customizing-a-migration-plan).\n\n 5. When your edits are complete, save the edited file.\n\n 6. Upload the edited migration plan:\n\n ```\n migctl migration update my-migration --main-config my-migration.yaml\n ```\n4. [Generate](/migrate/containers/docs/executing-a-migration) and [review the migration artifacts](/migrate/containers/docs/review-deployment-files)\n as you do today with the existing runtime.\n\n5. Edit the new `services-config.yaml` file to configure the initialization properties\n of the container. Save the file and rebuild your container image to apply the changes.\n\n See [Using services-config.yaml](/migrate/containers/docs/services-config) for more.\n6. [Deploy the container to a GKE Autopilot cluster](/migrate/containers/docs/deploying-to-target-cluster)\n using `kubectl`:\n\n ```\n kubectl apply -f deployment_spec.yaml\n ```\n\n### Example: Deploying the Quickstart container on an Autopilot cluster\n\nUse the current [Quickstart](/migrate/containers/docs/quickstart) guide to migrate a container containing\na simple web server and then deploy it on an Autopilot cluster. The only changes\nthat you have to make to the Quickstart process are:\n\n1. In Step 3 of [Migrating the VM](/migrate/containers/docs/quickstart#migrating_the_vm), where you review\n the migration plan, set `v2kServiceManager` to `true` in the migration plan\n and then save the plan:\n\n ```yaml\n \n v2kServiceManager: true\n ```\n2. In the [Deploying the migrated workload](/migrate/containers/docs/quickstart#deploying_the_migrated_workload) section,\n create and connect to a GKE Autopilot cluster before you deploy the container:\n\n 1. Create a GKE Autopilot cluster:\n\n ```\n gcloud container clusters create-auto \"CLUSTER_NAME\"\n --project \"PROJECT_NAME\" --region \"REGION\" --release-channel \"regular\"\n --subnetwork \"projects/PROJECT_NAME/regions/us-central1/subnetworks/default\"\n ```\n 2. Connect to the cluster:\n\n ```\n gcloud container clusters get-credentials CLUSTER_NAME \n --zone REGION --project PROJECT_NAME \n ```\n 3. Deploy the container as described in the\n [Deploying the migrated workload](/migrate/containers/docs/quickstart#deploying_the_migrated_workload) section.\n\n### Changes to the AppXGenerateArtifactsFlow CRD\n\nIf you are using CRD files to control your migration, edit the [AppXGenerateArtifactsFlow](https://github.com/GoogleCloudPlatform/migrate-to-containers/blob/main/references/crds/m2c-crds.md#appxgenerateartifactsflow) CRD\nto set `v2kServiceManager` to `true`. See [Customizing a migration plan](/migrate/containers/docs/customizing-a-migration-plan#crd)\nfor more on using CRD files to control migration.\n\nWhat's next\n-----------\n\n- Learn how to [deploy containers to Cloud Run](/migrate/containers/docs/deploy-run)."]]