Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Minha carga de trabalho não inicia
Ao tentar iniciar uma migração, talvez você encontre um erro que impeça que a carga de trabalho seja iniciada corretamente.
Se ocorrer um erro que impeça o início correto da carga de trabalho, tente seguir as etapas de solução de problemas descritas neste documento antes de entrar em contato com o suporte.
Adicionar as permissões necessárias para extrair imagens do Google Container Registry
Para que a carga de trabalho seja iniciada, o cluster precisa extrair a imagem dela do Google Container Registry (GCR), o que pode falhar às vezes devido à falta de permissões.
Para identificar esse problema, siga estas etapas:
No console do Google Cloud , acesse a página Navegador de objetos.
Na lista de pods exibida, localize o pod correspondente à carga de trabalho e clique no nome dele para abrir os detalhes.
Na página Detalhes do pod, se um banner exibir os erros failed to pull and unpack image e 403 forbidden, as permissões necessárias para extrair a imagem da carga de trabalho estão faltando.
Para resolver esse problema, siga estas etapas:
Adicione um papel chamado Leitor de objetos do Storage à conta de serviço padrão do Compute Engine do projeto.
Um novo pod é criado automaticamente para substituir o pod excluído.
Agora a carga de trabalho migrada está acessível.
Desativar clusters do Autopilot do GKE
No Migrate to Containers, o uso de clusters do Autopilot do GKE é ativado por padrão. Como resultado, as novas migrações criadas para o Migrate to Containers vão usar clusters do Autopilot do GKE, a menos que especificado de outra forma.
Desative os clusters do Autopilot do GKE e tente iniciar a carga de trabalho de migração novamente.
Para desativar os clusters do Autopilot do GKE, siga estas etapas para definir v2kServiceManager como false:
Se a carga de trabalho ainda não for iniciada corretamente após a desativação dos clusters do Autopilot do GKE, entre em contato com o canal de suporte.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 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."]]