Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Anwendungen migrieren und in GKE Autopilot-Clustern bereitstellen
Zum Bereitstellen der migrierten Containerarbeitslasten in GKE Autopilot-Clustern verwenden Sie dasselbe Verfahren zum Migrieren Ihrer Arbeitslasten wie für die vorhandene Architektur.
Die einzigen Änderungen sind:
Sie müssen im Migrationsplan v2kServiceManager auf true setzen, bevor Sie die Containerartefakte generieren.
Sie müssen die neue Datei services-config.yaml prüfen und die Initialisierungsdienste bearbeiten. Siehe services-config.yaml verwenden.
Laden Sie den Migrationsplan herunter. Der Migrationsplan wird durch AppXGenerateArtifactsFlow dargestellt:
Beispiel: Bei einer Migration mit dem Namen „my-migration“:
migctl migration get my-migration
Bearbeiten Sie den heruntergeladenen Migrationsplan my-migration.yaml in einem Texteditor.
Prüfen Sie den erweiterten Linux-Dienstmanager. Das Flag v2kServiceManager ist standardmäßig auf true gesetzt. Wenn Migrate to Containers jedoch einen Systemdienst erkennt, der nicht vom Dienstmanager unterstützt wird, werden Sie benachrichtigt und das Flag v2kServiceManager wird auf false gesetzt.
Wenn das Flag false lautet, verwendet die Migration eine Legacy-Laufzeit, die Ihren Dienst unterstützt.
Die folgende Benachrichtigung wird neben dem nicht unterstützten Dienst bereitgestellt:
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.
Wenn ein nicht unterstützter Dienst gefunden wird, können Sie das Flag auch manuell auf true setzen.
In diesem Fall können Sie entweder den nicht unterstützten Dienst für das generierte Image beibehalten, wo er möglicherweise nicht ausgeführt wird, oder den Dienst durch Entfernen aus dem Migrationsplan ausschließen.
Setzen Sie das Flag auf true zurück, um den neuen Dienstmanager zu aktivieren:
v2kServiceManager:true
Nehmen Sie gegebenenfalls weitere Anpassungen vor, die für die Migration erforderlich sind, wie unter Migrationsplan anpassen beschrieben.
Wenn die Änderungen abgeschlossen sind, speichern Sie die Datei.
Bearbeiten Sie die neue Datei services-config.yaml, um die Initialisierungsattribute des Containers zu konfigurieren. Speichern Sie die Datei und erstellen Sie das Container-Image neu, um die Änderungen zu übernehmen.
Beispiel: Kurzanleitungs-Container auf einem Autopilot-Cluster bereitstellen
Migrieren Sie mithilfe des aktuellen Schnellstarts einen Container mit einem einfachen Webserver und stellen Sie ihn dann in einem Autopilot-Cluster bereit. Die einzigen Änderungen, die Sie am Schnellstart vornehmen müssen, sind:
In Schritt 3 der VM-Migration, bei der Sie den Migrationsplan prüfen, setzen Sie v2kServiceManager im Migrationsplan auf true und speichern dann den Plan:
v2kServiceManager:true
Erstellen Sie im Bereich Migrierte Arbeitslast bereitstellen einen GKE Autopilot-Cluster und stellen Sie eine Verbindung zu diesem her, bevor Sie den Container bereitstellen:
Wenn Sie CRD-Dateien zur Steuerung der Migration verwenden, bearbeiten Sie die AppXGenerateArtifactsFlow, um v2kServiceManager auf true festzulegen. Weitere Informationen zum Steuern von Migrationen mithilfe von CRD-Dateien finden Sie unter Migrationsplan anpassen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
