Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Meine Arbeitslast startet nicht
Beim Versuch, eine Migration zu starten, kann ein Fehler auftreten, der das korrekte Starten Ihrer Arbeitslast verhindert.
In diesem Fall sollten Sie die in diesem Dokument beschriebenen Schritte zur Fehlerbehebung ausführen, bevor Sie sich an den Support wenden.
Berechtigungen zum Abrufen von Images aus Google Container Registry hinzufügen
Damit Ihre Arbeitslast gestartet werden kann, muss der Cluster das Arbeitslast-Image aus Google Container Registry (GCR) abrufen. Dies kann aufgrund fehlender Berechtigungen manchmal fehlschlagen.
So finden Sie heraus, wo das Problem liegt:
Rufen Sie in der Google Cloud Console die Seite Objektbrowser auf.
Wählen Sie in der Liste Objektarten die Option Pod aus.
Suchen Sie in der angezeigten Liste der Pods denjenigen, der Ihrer Arbeitslast entspricht, und klicken Sie auf den Namen des Pods, um dessen Details zu öffnen.
Wenn auf der Seite Pod-Details ein Banner mit den Fehlern failed to pull and unpack image und 403 forbidden angezeigt wird, fehlen die Berechtigungen zum Abrufen des Arbeitslast-Images.
So beheben Sie das Problem:
Fügen Sie die RolleStorage Object Viewer zum Compute Engine-Standarddienstkonto in Ihrem Projekt hinzu.
Der gelöschte Pod wird automatisch durch einen neuen ersetzt.
Die migrierte Arbeitslast sollte jetzt zugänglich sein.
GKE Autopilot-Cluster deaktivieren
In Migrate to Containers ist die Verwendung von GKE Autopilot-Clustern standardmäßig aktiviert. Daher werden bei allen neuen Migrationen, die für Migrate to Containers erstellt wurden, GKE Autopilot-Cluster verwendet, sofern nicht anders angegeben.
Deaktivieren Sie GKE Autopilot-Cluster und versuchen Sie noch einmal, die Migrationsarbeitslast zu starten.
Zum Deaktivieren von GKE Autopilot-Clustern müssen Sie diese Schritte ausführen, um v2kServiceManager auf false zu setzen:
[[["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-08-31 (UTC)."],[],[],null,["# My workload does not start\n==========================\n\nWhen attempting to start a migration, you may encounter an error that\nprevents your workload from starting correctly.\n\nIf you experience an error that prevents your workload from starting correctly,\ntry the troubleshooting steps described in this document before contacting\nsupport.\n\nAdd permissions required to pull images from Google Container Registry\n----------------------------------------------------------------------\n\nFor your workload to start, the cluster needs to pull the workload image from\n[Google Container Registry (GCR)](/container-registry), which might sometimes\nfail due to missing permissions.\n\nTo identify this issue, perform these steps:\n\n1. In the Google Cloud console, go to the **Object browser** page.\n\n [Go to Object browser](https://console.cloud.google.com/kubernetes/object/browser)\n\n \u003cbr /\u003e\n\n2. Select your cluster.\n\n3. From the **Object Kinds** list, select **Pod**.\n\n4. From the list of pods that is displayed, locate the pod corresponding to your\n workload, and then to open pod details, click the pod name.\n\n5. On the **Pod details** page, if a banner appears that displays the\n `failed to pull and unpack image` and `403 forbidden` errors,\n then the permissions required to pull the workload image are missing.\n\nTo resolve this issue, perform these steps:\n\n1. [Add a role](/iam/docs/manage-access-service-accounts#grant-single-role)\n called **Storage Object Viewer** to the **Default Compute Engine service account**\n in your project.\n\n2. Then, [delete](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete)\n the pod from your cluster.\n\n A new pod is automatically created which replaces the deleted pod.\n\nYour migrated workload should now be accessible.\n\nDisable GKE Autopilot clusters\n------------------------------\n\nAs of Migrate to Containers, use of GKE Autopilot clusters is\nenabled by default. As a result, any new migrations created for\nMigrate to Containers will use GKE Autopilot clusters unless specified\notherwise.\n\nTry disabling GKE Autopilot clusters and attempt to start\nyour migration workload again.\n\nTo disable GKE Autopilot clusters, perform these steps to set\n`v2kServiceManager` to `false`:\n\n1. [Edit your migration plan](/migrate/containers/docs/customizing-a-migration-plan#edit_the_migration_plan).\n\n 1. In the \u003cvar translate=\"no\"\u003eMIGRATION_NAME\u003c/var\u003e`.yaml` file, locate\n `v2kServiceManager` and set it to `false`.\n\n Change: \n\n v2kServiceManager: true\n\n to: \n\n v2kServiceManager: false\n\n 2. Save your file.\n\n2. [Reinitiate your migration](/migrate/anthos/docs/executing-a-migration) using Migrate to Containers.\n\nIf your workload still does not start correctly after disabling GKE Autopilot clusters,\nthen contact your support channel."]]
