Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Esegui la migrazione e il deployment delle applicazioni nei cluster GKE Autopilot
Per eseguire il deployment dei carichi di lavoro dei container di cui è stata eseguita la migrazione nei cluster GKE Autopilot,
utilizza la stessa procedura per la migrazione dei carichi di lavoro utilizzata per l'architettura esistente.
Le uniche modifiche sono:
Devi impostare v2kServiceManager su true nel piano di migrazione
prima di generare gli artefatti del contenitore.
Devi esaminare il nuovo file services-config.yaml e apportare eventuali modifiche ai servizi di inizializzazione. Consulta Utilizzo di services-config.yaml.
Scarica il piano di migrazione. Il piano di migrazione è rappresentato da
AppXGenerateArtifactsFlow.
Ad esempio, per una migrazione denominata "my-migration":
migctl migration get my-migration
Apri il piano di migrazione scaricato, my-migration.yaml, in un editor di testo.
Verifica il gestore dei servizi Linux avanzato. Per impostazione predefinita, il flag v2kServiceManager è impostato su true. Tuttavia, se Migrate to Containers rileva un servizio di sistema non supportato dal gestore dei servizi, riceverai un avviso e il flag v2kServiceManager verrà impostato su false.
Quando il flag è false, la migrazione utilizzerà un runtime precedente che supporta il tuo servizio.
Accanto al servizio non supportato viene fornito il seguente avviso:
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.
Quando viene rilevato un servizio non supportato, puoi anche scegliere di impostare manualmente il flag su true.
In questo caso, puoi scegliere di mantenere il servizio non supportato nell'immagine generata, dove potrebbe non essere eseguito, oppure puoi escluderlo rimuovendolo dal piano di migrazione.
Per attivare il nuovo gestore dei servizi, reimposta il flag su true:
Modifica il nuovo file services-config.yaml per configurare le proprietà di inizializzazione del contenitore. Salva il file e ricostruisci l'immagine del contenitore per applicare le modifiche.
Esempio: deployment del contenitore Quickstart su un cluster Autopilot
Utilizza la guida Guida rapida attuale per eseguire la migrazione di un contenitore contenente un semplice server web e poi esegui il deployment su un cluster Autopilot. Le uniche modifiche
che devi apportare alla procedura di Avvio rapido sono:
Nel passaggio 3 della migrazione della VM, in cui esamini il piano di migrazione, imposta v2kServiceManager su true nel piano di migrazione e poi salvalo:
Se utilizzi file CRD per controllare la migrazione, modifica il file CRD AppXGenerateArtifactsFlow per impostare v2kServiceManager su true. Per saperne di più sull'utilizzo dei file CRD per controllare la migrazione, consulta Personalizzare un piano di migrazione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]