Preparar para o desligamento do agente de inicialização do contêiner

O agente de inicialização de contêiner (konlet) que implanta contêineres em instâncias do Compute Engine durante a criação de VMs foi descontinuado.

Este documento descreve como planejar a migração de contêineres criados durante a criação de VMs para outros Cloud de Confiance by S3NS serviços.

Informações gerais

O que é um agente de inicialização de contêiner no Compute Engine?

O agente de inicialização de contêiner permite implantar e configurar contêineres em instâncias do Compute Engine ou em instâncias em um grupo gerenciado de instâncias (MIG) durante a criação de VMs e inicia um contêiner do Docker.

Por que o agente de inicialização de contêiner foi descontinuado?

Com base no feedback dos clientes, Cloud de Confiance by S3NS melhora as opções de implantação de contêineres. Descontinuamos o agente de inicialização de contêiner para oferecer opções mais flexíveis para a implantação de contêineres.

Para mais informações sobre as opções descontinuadas, consulte Opções descontinuadas para configurar contêineres em VMs.

Quais são os principais marcos dessa descontinuação e o que acontece se eu não tomar medidas até o prazo?

A partir de 31 de julho de 2026, todos os fluxos de trabalho que dependem do agente de inicialização de contêiner ou dos metadados de instância gce-container-declaration não funcionarão mais.

A partir de 31 de julho de 2027, o Google vai descontinuar o suporte ao agente de inicialização de contêiner, e nenhuma outra atualização será fornecida para VMs em execução que usam os gce-container-declaration metadados. Você vai executar as cargas de trabalho por sua conta e risco, e isso pode afetar seu fluxo de trabalho.

Recomendamos que você migre os contêineres para soluções alternativas bem antes dessas datas para garantir uma transição tranquila.

Quando não será mais possível criar novas VMs ou MIGs com contêineres implantados diretamente usando os metadados gce-container-declaration?

12 meses após a notificação inicial de descontinuação, que é 31 de julho de 2026.

Quando não será mais possível executar implantações de contêineres em VMs ou MIGs que usam os metadados gce-container-declaration?

Vamos interromper o suporte a cargas de trabalho implantadas usando o agente de inicialização de contêiner 24 meses após a notificação inicial de descontinuação, que é 31 de julho de 2027.

Como essa descontinuação afeta minha configuração do Terraform?

Se você usa o Terraform ou automação semelhante para criar ou atualizar VMs ou MIGs definindo explicitamente a chave de metadados gce-container-declaration, seu fluxo de trabalho vai parar de funcionar em 31 de julho de 2026. Para evitar interrupções, atualize a configuração do Terraform para usar um script de inicialização para implantação de contêineres e remova a dependência da chave de metadados gce-container-declaration. Para instruções detalhadas, consulte o guia de migração.

Essa descontinuação significa que as imagens do Container-Optimized OS também serão descontinuadas?

Não, as imagens do Container-Optimized OS não serão descontinuadas. A mudança é sobre como os contêineres são implantados em VMs que usam o Container-Optimized OS. As versões mais recentes do Container-Optimized OS não vão mais oferecer suporte ao konlet, o agente de inicialização de contêiner que usa a chave de metadados gce-container-declaration para implantar contêineres. As imagens do Container-Optimized OS continuam disponíveis e com suporte. No entanto, é necessário atualizar a configuração da VM para usar um script de inicialização ou cloud-init para implantar contêineres em vez de depender da chave de metadados gce-container-declaration.

Eu uso cloud-init para executar contêineres em VMs. Sou afetado por essa mudança?

Não. Essa descontinuação não afeta as VMs configuradas usando cloud-init. Você pode continuar usando cloud-init para configurar instâncias. Para mais informações, consulte Como usar o cloud-init com a configuração do Cloud.

Como posso saber se a mudança me afetará?

Se você estiver implantando um contêiner em uma VM durante a criação dela usando o agente de inicialização de contêiner ou especificando gce-container-declaration, será afetado por essa descontinuação. Para validar se há instâncias afetadas no seu projeto,execute o seguinte comando da CLI gcloud:

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

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

Para mais informações sobre como visualizar os metadados do projeto, consulte a documentação de metadados.

Se você 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. Esse comando fornece todas as informações de uma determinada instância, incluindo os metadados. Se você encontrar a chave de metadados gce-container-declaration na resposta ao comando, sua VM será afetada por essa mudança.

Há uma maneira de impedir a criação de VMs que usam o agente de inicialização de contêiner?

Sim. Os administradores da organização podem aplicar a restrição de política da organização compute.managed.disableVmsWithContainerStartupAgent para desativar a criação de recursos que usam o agente de inicialização de contêiner e a chave de metadados gce-container-declaration. Também é possível aplicar essa política no modo de simulação para monitorar o uso antes de bloquear a criação de recursos. Para mais informações, consulte Impedir a criação de VMs que usam os metadados de contêiner descontinuados.

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

Não. A segurança e a privacidade são fundamentais para tudo o que fazemos no Google. Ao usar nossos scripts ou soluções gerenciadas, você tem a flexibilidade de configurar configurações específicas de segurança e privacidade para atender aos seus requisitos. Para mais informações, consulte o guia de migração.

Soluções alternativas

Quais são as soluções alternativas recomendadas para contêineres no Compute Engine e como escolher a certa para meus requisitos?

Você pode escolher uma das seguintes opções para migrar o contêiner:

• Se você quiser continuar implantando contêineres em VMs ou MIGs, executar contêineres para testes e desenvolvimento ou executar uma carga de trabalho que consiste em uma única VM, use scripts de inicialização ou cloud-init.
• Se você tiver aplicativos de contêiner sem estado e jobs pequenos a médios, considere o Cloud Run. Também é possível usar scripts de inicialização.
• Se o contêiner for um job em lote que tem um estado final definido e exige mais recursos de computação, considere o Batch. Também é possível usar scripts de inicialização.
• Se você precisar de controle e escalonabilidade avançados ou não conseguir atender aos seus requisitos com as outras opções, considere GKE.

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

Por que devo considerar a migração para um serviço gerenciado, como o Cloud Run, o GKE ou o Batch, em vez de usar um script de inicialização?

Recomendamos que você considere a migração para soluções de contêineres, como o Google Kubernetes Engine, o Cloud Run e o Batch. Esses serviços gerenciados oferecem vantagens significativas em relação às implantações convencionais baseadas em VM, incluindo escalonabilidade, flexibilidade e recursos de gerenciamento avançados.

Os principais benefícios incluem o seguinte:

• Reduza a sobrecarga de gerenciamento: como serviços totalmente gerenciados,Cloud de Confiance cuida da infraestrutura subjacente (VMs, aplicação de patches, escalonamento). Essa abordagem libera tempo valioso da equipe e reduz a carga operacional.
• Escalone automaticamente e garanta a elasticidade: esses serviços ajustam automaticamente os recursos com base na demanda. Isso leva a uma melhor utilização de recursos e possível economia de custos em comparação com o provisionamento excessivo de VMs.
• Alcance a eficiência de custos para cargas inativas: ao contrário das VMs, que incorrem em custos mesmo quando inativas, os serviços gerenciados podem ser mais econômicos para aplicativos com tráfego flutuante ou baixo.
• Utilize a disponibilidade da camada sem custo financeiro: o GKE, o Cloud Run e o Batch oferecem uma camada sem custo financeiro, permitindo que você execute cargas de trabalho menores ou realize testes sem custo.

Para 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 elas se comparam à configuração atual?

Scripts de inicialização de implantação de contêineres ou cloud-init: o uso de scripts de inicialização ou cloud-init como substituto direto não altera inerentemente os custos do Compute Engine. Você ainda paga pelos recursos de VM subjacentes.

Serviços gerenciados: a migração para serviços como o Cloud Run ou o Batch pode oferecer economia de custos, especialmente para aplicativos com uso variável. Ao contrário das VMs que cobram mesmo quando inativas, esses serviços gerenciados podem ser mais eficientes. Além disso, as camadas sem custo financeiro podem reduzir ainda mais os custos de cargas de trabalho temporárias menores.

Para mais informações, consulte Comparar as opções de implantação de contêineres. Os preços variam de acordo com o serviço escolhido e a configuração específica. Use a calculadora de preços para uma estimativa precisa.

Essa descontinuação significa que as imagens do Container-Optimized OS serão descontinuadas e, portanto, se quisermos executar o Docker em VMs do Compute Engine, precisaremos configurar nosso próprio modelo de VM?

Não,as imagens do Container-Optimized OS não serão descontinuadas. A mudança é sobre como os contêineres são iniciados em VMs usando o Container-Optimized OS. As versões mais recentes do Container-Optimized OS não vão mais oferecer suporte ao konlet, que é o agente de inicialização de contêiner que inicia contêineres usando a chave de metadados gce-container-declaration. Isso significa que as imagens do Container-Optimized OS ainda estarão disponíveis e com suporte. No entanto, é necessário atualizar a VM para usar um script de inicialização ou uma configuração cloud-init para implantar contêineres em vez de usar a chave de metadados gce-container-declaration.

Processo de migração

Qual é a abordagem recomendada para migrar contêineres para as soluções alternativas?

Recomendamos que você siga estas etapas para a migração:

• Entenda suas opções: consulte o guia de migração para conferir outras maneiras de executar seus contêineres.
• Planeje a migração com antecedência: para garantir uma transição tranquila, comece a planejar a migração das implantações de contêineres atuais bem antes de 31 de julho de 2026.
• Prepare-se para novas cargas de trabalho: garanta que as novas cargas de trabalho de contêiner estejam prontas para serem executadas em soluções alternativas até 31 de julho de 2026, já que a implantação direta de contêineres em VMs ou MIGs não será mais possível.
• Prazo final da migração: garanta que todas as cargas de trabalho de contêiner atuais sejam migradas para soluções alternativas até 31 de julho de 2027, quando o método de implantação direta será totalmente desativado.

Preciso migrar para uma das soluções recomendadas ou há alternativas que posso usar?

Oferecemos flexibilidade para adotar qualquer solução que esteja alinhada às suas necessidades de negócios e que tenha suporte ativo. Recursos como o guia de migração estão disponíveis para ajudar você a escolher a opção mais adequada.

O backup ou a exportação de dados são necessários como parte do processo de migração?

Embora a realização de um backup ou exportação de dados seja sempre uma prática recomendada essencial para a segurança de dados e a continuidade dos negócios, ela não é uma etapa necessária para esse processo de migração.

Quanto tempo leva para migrar para uma das alternativas e há fatores que podem afetar meu tempo de dedicação?

Script de inicialização de implantação de contêineres: a configuração e os testes iniciais usando scripts de inicialização levam cerca de 1 a 2 horas. As implantações subsequentes levam apenas alguns minutos cada.

Serviços gerenciados: a opção por Cloud de Confiance by S3NS soluções como o Cloud Run, o Batch ou o GKE, que são ofertas de PaaS sem servidor e totalmente gerenciadas, pode envolver um maior investimento inicial de tempo e esforço. Isso ocorre devido à mudança fundamental de uma abordagem centrada em VM (IaaS), em que você gerencia a infraestrutura, para um modelo de PaaS em que a plataforma lida com grande parte disso. Essa adaptação pode exigir mudanças no aplicativo, como garantir que ele seja sem estado, mas os benefícios de longo prazo podem incluir ganhos substanciais em eficiência operacional, escalonabilidade e custo-benefício.

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

Se eu optar por migrar para uma alternativa, isso envolverá interrupções ou inatividade para Cloud de Confiance by S3NS projetos, VMs, serviços e apps?

Em geral, a transição para a solução alternativa recomendada é projetada para ser um processo de tempo de inatividade zero.

Para a migração de contêineres de longa duração em VMs do Compute Engine, para evitar interrupções, recomendamos configurar novas VMs com a configuração alternativa e alternar o tráfego depois que elas forem testadas.

Como essa migração afeta minha configuração do Terraform?

Se você estiver usando o Terraform ou automação semelhante para criar ou atualizar VMs ou MIGs com contêineres definindo explicitamente a chave de metadados gce-container-declaration, seu fluxo de trabalho vai parar de funcionar em 31 de julho de 2026. Para evitar interrupções, é necessário atualizar a configuração para incluir um script de inicialização para implantação de contêineres e remover a dependência da chave de metadados gce-container-declaration. Para instruções detalhadas sobre como implementar essa mudança, consulte Migrar contêineres implantados em VMs durante a criação delas.

Como receber suporte

Com quem devo entrar em contato no Compute Engine se tiver dúvidas sobre o processo de migração?

Se tiver dúvidas ou precisar de ajuda, entre em contato com o suporte do Google Cloud.

Quais recursos estão disponíveis para me ajudar na migração e fornecer orientações técnicas?

Este FAQ, um guia de migração e o suporte do Google Cloud estão disponíveis para ajudar você no processo de migração.