Prepare-se para o encerramento do agente de arranque do contentor

O agente de arranque do contentor que implementa contentores em instâncias do Compute Engine durante a criação de VMs foi descontinuado.

Este documento descreve como planear a migração de contentores que criou durante a criação de VMs para outros Google Cloud serviços.

Informações gerais

O que é um agente de arranque de contentor no Compute Engine?
O agente de arranque do contentor permite-lhe implementar e configurar contentores em instâncias do Compute Engine ou em instâncias num grupo de instâncias geridas (GIG) durante a criação de VMs e inicia um contentor Docker.
Por que motivo o agente de arranque do contentor foi descontinuado?

Com base no feedback dos clientes, Google Cloud melhora as opções de implementação de contentores. Descontinuámos o agente de arranque do contentor para lhe podermos oferecer opções mais flexíveis para a implementação dos seus contentores.

Para mais informações sobre as opções descontinuadas, consulte o artigo Opções descontinuadas para configurar contentores em VMs.

Quais são os marcos importantes desta descontinuação e o que acontece se não tomar medidas até ao prazo?

A partir de 31 de julho de 2026, todos os fluxos de trabalho que dependam do agente de arranque do contentor ou dos metadados da instância gce-container-declaration vão deixar de funcionar.

A partir de 31 de julho de 2027, a Google vai descontinuar o apoio técnico para o agente de arranque do contentor e não vão ser disponibilizadas mais atualizações para nenhuma VM em execução que use os metadados gce-container-declaration. Vai executar as cargas de trabalho por sua conta e risco, e isso pode afetar o seu fluxo de trabalho.

Recomendamos que migre os contentores para soluções alternativas bem antes destas datas para garantir uma transição sem problemas.

Quando é que deixo de poder criar novas VMs ou MIGs com contentores implementados diretamente através dos metadados gce-container-declaration?

12 meses a partir da notificação de descontinuação inicial, ou seja, 31 de julho de 2026.

Quando vou deixar de poder executar implementações de contentores em VMs ou MIGs que usam os metadados gce-container-declaration?

Vamos deixar de suportar todas as cargas de trabalho implementadas através do agente de arranque de contentores 24 meses após a notificação de descontinuação inicial, ou seja, a 31 de julho de 2027.

Como é que esta descontinuação afeta a minha configuração do Terraform?

Se usar o Terraform ou uma automatização semelhante para criar ou atualizar VMs ou GIGs definindo explicitamente a chave de metadados gce-container-declaration, o fluxo de trabalho vai deixar de funcionar a 31 de julho de 2026. Para evitar interrupções, atualize a configuração do Terraform para usar um script de arranque para a implementação de contentores e remova a dependência da chave de metadados gce-container-declaration. Para ver instruções detalhadas, consulte o guia de migração.

Esta descontinuação significa que as imagens do SO otimizado para contentores vão ser descontinuadas?

Não, as imagens do SO otimizado para contentores não vão ser descontinuadas. A alteração diz respeito à forma como os contentores são implementados em VMs que usam o SO otimizado para contentores. As versões mais recentes do SO otimizado para contentores vão deixar de suportar o konlet, o agente de arranque que usa a chave de metadados gce-container-declaration para implementar contentores. As imagens do SO otimizado para contentores continuam a estar disponíveis e a ser suportadas. No entanto, tem de atualizar a configuração da VM para usar um script de arranque ou cloud-init implementar contentores em vez de depender da chave de metadados gce-container-declaration.

Uso o cloud-init para executar contentores em VMs. Am I impacted by this change?

Não. Esta descontinuação não afeta as VMs configuradas através do cloud-init. Pode continuar a usar o cloud-init para configurar instâncias. Para mais informações, consulte o artigo Usar o cloud-init com a configuração na nuvem.

Como posso saber se esta alteração me afeta?

Se estiver a implementar um contentor numa VM durante a criação da VM através do agente de arranque do contentor ou especificando o gce-container-declaration, é afetado por esta descontinuação. Para validar se existem instâncias afetadas no seu projeto,execute o seguinte comando da CLI gcloud:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Este comando fornece uma lista de todas as instâncias de VMs no seu projeto que contêm a chave de metadados gce-container-declaration. A chave de metadados identifica de forma exclusiva as VMs que estão no âmbito da descontinuação. Se estiver a usar vários projetos, execute o comando em todos os projetos ativos.

Para mais informações sobre a visualização dos metadados do projeto, consulte a documentação de metadados.

Se tiver uma instância específica que quer verificar, execute o seguinte comando da CLI gcloud:

gcloud compute instances describe VM_NAME

Substitua VM_NAME pelo nome da instância de VM. Este comando fornece todas as informações de uma determinada instância, incluindo os metadados. Se vir a chave de metadados gce-container-declaration no resultado do comando, a sua VM é afetada por esta alteração.

Existe algum risco para a segurança ou a privacidade do projeto durante a migração?

Não. A segurança e a privacidade são fundamentais para tudo o que fazemos na Google. Quando usa os nossos scripts ou soluções geridas, tem a flexibilidade de configurar definições de segurança e privacidade específicas para cumprir os seus requisitos. Para mais informações, consulte o guia de migração.

Soluções alternativas

Quais são as soluções alternativas recomendadas aos contentores no Compute Engine e como escolho a solução certa para os meus requisitos?

Pode escolher uma das seguintes opções para migrar o seu contentor:

  • Se quiser continuar a implementar contentores em VMs ou MIGs, ou executar contentores para testes e desenvolvimento, ou executar uma carga de trabalho que consista numa única VM, use scripts de arranque ou cloud-init.
  • Se tiver aplicações de contentores sem estado e tarefas pequenas a médias, considere o Cloud Run. Também pode usar scripts de inicialização.
  • Se o seu contentor for uma tarefa em lote com um estado final definido e que requer recursos de computação adicionais, considere usar o Batch. Também pode usar scripts de arranque.
  • Se precisar de controlo e escalabilidade avançados ou não conseguir cumprir os seus requisitos com as outras opções, considere usar o GKE.

Para obter orientações detalhadas e recomendações sobre as opções de migração, leia o guia de migração.

Por que motivo devo considerar migrar para um serviço gerido, como o Cloud Run, o GKE ou o Batch, em vez de usar um script de arranque?

Recomendamos que considere migrar para soluções de contentores, como o Google Kubernetes Engine, o Cloud Run e o Batch. Estes serviços geridos oferecem vantagens significativas em relação às implementações convencionais baseadas em VMs, incluindo escalabilidade, flexibilidade e capacidades de gestão avançadas melhoradas.

As principais vantagens incluem o seguinte:

  • Reduza as despesas gerais de gestão: como serviços totalmente geridos,oGoogle Cloud trata da infraestrutura subjacente (MV, aplicação de patches, escalabilidade). Esta abordagem liberta tempo valioso dos funcionários e reduz o seu esforço operacional.
  • Aumente a escala automaticamente e garanta a elasticidade: estes serviços ajustam automaticamente os recursos com base na procura. Isto leva a uma melhor utilização dos recursos e a potenciais poupanças de custos em comparação com o aprovisionamento excessivo de VMs.
  • Alcance a eficiência de custos para cargas inativas: ao contrário das VMs, que incorrem em custos mesmo quando estão inativas, os serviços geridos podem ser mais rentáveis para aplicações com tráfego flutuante ou baixo.
  • Use a disponibilidade do nível gratuito: o GKE, o Cloud Run e o Batch oferecem um nível gratuito, o que lhe permite executar cargas de trabalho mais pequenas ou realizar testes sem custos.

Para obter orientações detalhadas sobre a migração, consulte o guia de migração.

Quais são as considerações de custo para cada solução alternativa e como se comparam com a configuração atual?

Scripts de arranque de implementação de contentores ou cloud-init: a utilização de scripts de arranque ou do cloud-init como substituição direta não altera inerentemente os custos do Compute Engine. Continua a pagar pelos recursos de VM subjacentes.

Serviços geridos: a mudança para serviços como o Cloud Run ou o Batch pode oferecer poupanças de custos, especialmente para aplicações com utilização variável. Ao contrário das VMs que cobram mesmo quando estão inativas, estes serviços geridos podem ser mais eficientes. Além disso, os níveis gratuitos podem reduzir ainda mais os custos para cargas de trabalho temporárias mais pequenas.

Para mais informações, consulte o artigo Compare as opções de implementação de contentores. O preço varia consoante o serviço escolhido e a sua configuração específica. Use a calculadora de preços para obter uma estimativa precisa.

Esta descontinuação significa que as imagens do SO otimizado para contentores vão ser descontinuadas e, por isso, se quisermos executar o Docker em VMs do Compute Engine, temos de configurar o nosso próprio modelo de VM?

Não. As próprias imagens do SO otimizado para contentores não vão ser descontinuadas. A alteração diz respeito à forma como os contentores são iniciados em VMs que usam o SO otimizado para contentores. As versões mais recentes do SO otimizado para contentores vão deixar de suportar o konlet, que é o agente de arranque que inicia os contentores através da chave de metadados gce-container-declaration. Isto significa que as imagens do SO otimizado para contentores vão continuar a estar disponíveis e a ser suportadas. No entanto, tem de atualizar a sua VM para usar um script de arranque ou uma cloud-init configuração para implementar contentores em vez de usar a chave de metadados gce-container-declaration.

Processo de migração

Qual é a abordagem recomendada para migrar contentores para as soluções alternativas?

Recomendamos que siga os seguintes passos para a migração:

  • Compreenda as suas opções: reveja o guia de migração para explorar formas alternativas de executar os seus contentores.
  • Planeie a migração com antecedência: para garantir uma transição sem problemas, comece a planear a migração das implementações de contentores atuais bem antes de 31 de julho de 2026.
  • Prepare-se para novas cargas de trabalho: certifique-se de que as novas cargas de trabalho de contentores estão prontas para serem executadas em soluções alternativas até 31 de julho de 2026, uma vez que a implementação direta de contentores em VMs ou MIGs vai deixar de ser possível.
  • Prazo final da migração: certifique-se de que todas as cargas de trabalho de contentores existentes são migradas para soluções alternativas até 31 de julho de 2027, quando o método de implementação direta for totalmente descontinuado.
Tenho de migrar para uma das soluções recomendadas ou existem alternativas que posso usar?

Apoiamos a sua flexibilidade para adotar qualquer solução que se alinhe com as suas necessidades empresariais e que seja ativamente suportada. Estão disponíveis recursos, como o guia de migração, para ajudar a escolher a opção mais adequada.

É necessária uma cópia de segurança ou uma exportação de dados como parte do processo de migração?

Embora a realização de uma cópia de segurança ou uma exportação de dados seja sempre uma prática recomendada fundamental para a segurança dos dados e a continuidade da empresa, não é um passo necessário para este processo de migração.

Quanto tempo vou demorar a migrar para uma das alternativas e existem fatores que podem afetar o meu compromisso de tempo?

Script de arranque da implementação do contentor: A configuração inicial e os testes com scripts de arranque devem demorar cerca de 1 a 2 horas. As implementações subsequentes devem demorar apenas alguns minutos cada.

Serviços geridos: optar por Google Cloud soluções como o Cloud Run, o Batch ou o GKE, que são ofertas de PaaS sem servidor e totalmente geridas, pode envolver um maior investimento inicial de tempo e esforço. Isto deve-se à alteração fundamental de uma abordagem centrada na VM (IaaS), em que gere a infraestrutura, para um modelo PaaS em que a plataforma processa grande parte desta gestão. Esta adaptação pode exigir alterações à sua aplicação, como garantir que não tem estado, mas as vantagens a longo prazo podem incluir ganhos substanciais na eficiência operacional, escalabilidade e rentabilidade.

Para orientações sobre esta transição, consulte o guia de migração.

Se optar por migrar para uma alternativa, existem interrupções ou tempo de inatividade para os Google Cloud projetos, as VMs, os serviços e as apps?

Geralmente, a transição para a solução alternativa recomendada foi concebida para ser um processo sem tempo de inatividade.

Para a migração de contentores de execução prolongada em VMs do Compute Engine, para evitar interrupções, recomendamos que configure novas VMs com a configuração alternativa e que mude o tráfego assim que forem testadas.

Como é que esta migração afeta a minha configuração do Terraform?

Se estiver a usar o Terraform ou uma automatização semelhante para criar ou atualizar VMs ou MIGs com contentores definindo explicitamente a chave de metadados, o seu fluxo de trabalho vai deixar de funcionar a 31 de julho de 2026.gce-container-declaration Para evitar interrupções, tem de atualizar a configuração para incluir um script de início para a implementação do contentor e remover a dependência da chave de metadados gce-container-declaration. Para obter instruções detalhadas sobre como implementar esta alteração, consulte o artigo Migre contentores implementados em VMs durante a criação de VMs.

Receber apoio técnico

Quem devo contactar no Compute Engine se tiver dúvidas sobre o processo de migração?
Se tiver dúvidas ou precisar de assistência, contacte o apoio técnico do Google Cloud.
Que recursos estão disponíveis para me ajudar com a migração e fornecer orientações técnicas?
Estas Perguntas frequentes, um guia de migração e o apoio técnico do Google Cloud estão disponíveis para ajudar no processo de migração.