Sobre a descontinuação de imagens de nó do Docker

Padrão

Nesta página, você verá informações sobre o ambiente de execução de contêiner do containerd, suporte para o Docker no Google Kubernetes Engine (GKE) e uma visão geral do motivo para migrar para imagens de nó que usam containerd. Para instruções sobre como migrar para uma imagem de nó do containerd, consulte Migrar imagens de nó do Docker para o containerd.

Visão geral

Os nós do Kubernetes usam o ambiente de execução do contêiner para iniciar, gerenciar e interromper contêineres em execução nos pods. O projeto do Kubernetes está removendo o suporte integrado para o ambiente de execução do Docker na versão 1.24 e posteriores do Kubernetes. Para isso, o Kubernetes está removendo um componente chamado dockershim, que permite a comunicação do Docker com componentes do Kubernetes, como o kubelet.

O containerd, o novo ambiente de execução padrão, é um ambiente de execução de contêiner padrão do setor compatível com o Kubernetes e usado por muitos outros projetos. O ambiente de execução containerd fornece a abstração de camadas que permite a implementação de um conjunto avançado de recursos, como o gVisor e o streaming de imagens, para ampliar a funcionalidade do GKE. O ambiente de execução também é considerado mais eficiente e seguro do que o ambiente de execução do Docker.

Devido a essa alteração, o GKE não é compatível com imagens de nó que usam o Docker como o ambiente de execução no GKE versão 1.24 e posterior. Um cluster será afetado se qualquer um dos pools de nós usar imagens de nó baseadas no Docker ou usar provisionamento automático de nós com um tipo de imagem de nó padrão baseado no Docker.

Antes de 31 de julho de 2023, a data do fim da vida útil do GKE versão 1.23, o GKE pausa upgrades automáticos e impede atualizações manuais para a versão 1.24. Para fazer upgrade do plano de controle do cluster para o GKE versão 1.24 e posterior antes dessa data, atualize a configuração de provisionamento automático de nós e todos os nós para o ambiente de execução containerd. Para fazer upgrade de um pool de nós, migre para uma imagem de nó que usa o ambiente de execução containerd.

Após o fim da vida útil da versão 1.23, o GKE desbloqueia os upgrades manuais do plano de controle para a versão 1.24 nos clusters que ainda não concluíram a migração e começa a fazer upgrade de clusters gradualmente para fins segurança e compatibilidade. Para saber mais sobre como o GKE faz upgrade dos clusters para a versão 1.24 e o que recomendamos que você faça para migrar os clusters a partir de imagens de nós do Docker, consulte Migração automática quando a versão 1.23 chegar ao fim da vida útil.

Imagens do Docker e de nós containerd

O containerd é o ambiente de execução padrão para todos os novos nós do GKE desde a versão 1.19 no Linux e 1.21 no Windows. No entanto, os clusters do GKE Standard também continuaram sendo compatíveis com imagens de nó que usavam o Docker como ambiente de execução. A tabela a seguir descreve imagens de nós baseadas no Docker que não serão compatíveis com a versão 1.24 do GKE e posteriores, bem como os equivalentes do containerd:

Tempo de execução do Docker	ambiente de execução do containerd
SO Container-Optimized com Docker (`cos`)	Container-Optimized OS com o containerd (`cos_containerd`)
Ubuntu com Docker (`ubuntu`)	Ubuntu com o containerd (`ubuntu_containerd`)
Windows Server LTSC com Docker (`windows_ltsc`)	Windows Server LTSC com containerd (`windows_ltsc_containerd`)
Windows Server SAC com Docker (`windows_sac`)	Windows Server SAC com containerd (`windows_sac_containerd`)

Cronograma e marcos

Na versão 1.23 do GKE, não é mais possível fazer o seguinte:

Criar novos clusters que usem imagens de nó baseadas no Docker.
Adicionar novos pools de nós com imagens de nó baseadas no Docker a um cluster atual.
Ativar o provisionamento automático de nós com a sinalização --autoprovisioning-image-type definida para imagens de nó baseadas no Docker.

Se você estiver fazendo upgrade para o GKE versão 1.23, será possível continuar usando o seguinte:

Pools de nós atuais com imagens de nó baseadas no Docker criadas antes do upgrade.
Escalonador automático de cluster em pools de nós com imagens de nó do Docker.
Provisionamento automático de nós com a sinalização --autoprovisioning-image-type definida para imagens de nó baseadas no Docker, se ativadas antes do upgrade.

No GKE versão 1.24, não é mais possível realizar as seguintes ações:

Se o plano de controle executar a versão 1.24, não será possível usar o provisionamento automático de nós com a flag --autoprovisioning-image-type definida para imagens de nó baseadas no Docker.
Se o pool de nós executar a versão 1.24, os nós não poderão usar imagens de nó baseadas no Docker.

A tabela a seguir fornece um resumo das alterações esperadas quando você interage com as próximas versões do GKE:

Ação	Versão 1.23 do GKE	Versão 1.24 do GKE
Criar novos clusters com o Docker	Não	Não
Criar novos pools de nós com o Docker	Não	Não
Ativar o provisionamento automático de nós com o Docker	Não	Não
Fazer upgrade da versão anterior com a configuração de provisionamento automático de nós do Docker	Sim	Não
Usar imagens de nó baseadas no Docker	Sim	Não

Migração automática quando a versão 1.23 chegar ao fim da vida útil

Se você não fizer upgrade para a versão 1.24 e migrar para as imagens de nó do containerd antes que a versão 1.23 chegue ao fim da vida útil em 31 de julho de 2023, o GKE vai fazer o seguinte:

Se o cluster tiver provisionamento automático de nós com um tipo de imagem de nó padrão baseado no Docker, o GKE atualizará a configuração para usar a função imagem de nó equivalente que usa o ambiente de execução containerd. Não é possível bloquear essa operação com uma exclusão de manutenção. Para verificar se não há efeito adverso nas cargas de trabalho, recomendamos que você atualize manualmente o tipo de imagem padrão do provisionamento automático de nós para uma imagem baseada em containerd antes que o GKE atualize a configuração automaticamente.
O GKE faz upgrade do plano de controle do cluster para a versão 1.24.
O GKE migra todos os pools de nós que ainda usam o Docker para imagens de nó em contêineres a partir de 1º de setembro de 2023. Recomendamos que você migre manualmente suas imagens de nó antes dessa data. Outra possibilidade é solicitar que o GKE inicie uma operação para migrar o cluster ao uso de imagens do containerd. Para fazer essa solicitação, entre em contato com o Cloud Customer Care.

Para bloquear temporariamente a migração automática, faça upgrade do cluster para a versão 1.24 ou posterior e configure uma exclusão de manutenção. Para mais informações sobre essa exclusão de manutenção, consulte Atrasar temporariamente a migração automática para imagens de nó de containerd.
Assim como é feito com qualquer versão não compatível, o GKE faz upgrade dos pools de nós na versão 1.23 para a versão 1.24 para garantir o alinhamento da integridade do cluster com a política de desvio da versão de código aberto. Para saber mais, consulte o Ciclo de vida da versão secundária do GKE. É possível bloquear temporariamente esse upgrade com uma exclusão de manutenção.

Atrasar temporariamente a migração automática para imagens de nó de containerd

Depois que o plano de controle do cluster tiver sido atualizado para 1.24 ou posterior, será possível configurar uma exclusão de manutenção para impedir temporariamente que os nós sejam migrados até 29 de fevereiro de 2024, quando a versão 1.25 chegará ao fim da vida útil. Para se qualificar para essa exclusão de manutenção, o cluster precisa estar inscrito em um canal de lançamento. Configure a exclusão de manutenção com o escopo "Sem upgrades menores ou de nós" e defina a flag --add-maintenance-exclusion-end como 2024-02-29T00:00:00Z ou anterior. Recomendamos desbloquear a migração o mais rápido possível e permitir que os nós sejam atualizados para a versão 1.24. As versões secundárias que atingiram o fim da vida útil não receberão mais patches de segurança e correções de bugs.

Migrar do Docker para imagens de nó containerd

Consulte Migrar imagens de nó do Docker para o containerd para identificar clusters e pools de nós usando imagens de nó baseadas no Docker e migrar esses pools para imagens de nó do containerd.

Como parte do Modelo de responsabilidade compartilhada do GKE, é de responsabilidade do cliente manter a integridade das cargas de trabalho e é de responsabilidade do Google garantir que o cluster permaneça funcional, o que inclui a execução de uma versão compatível. É altamente recomendável que você teste as cargas de trabalho e migre o cluster antes de o GKE fazer isso automaticamente.

Antes do fim da vida útil da versão 1.23, o GKE impede upgrades automáticos ou manuais para a versão 1.24 nos clusters com pools de nós que usam imagens de nó do Docker. Depois de migrar o cluster para usar apenas imagens do containerd, será possível retomar os upgrades automáticos em até um dia, de acordo com a programação de lançamentos do GKE, ou fazer upgrades manuais do cluster.

Após o fim da vida útil da versão 1.23, o GKE desbloqueia upgrades automáticos ou manuais para a versão 1.24 e segue o processo de migração automática.

Impacto da migração

A principal mudança na migração para imagens de nó do containerd é que o Docker não gerencia mais o ciclo de vida dos contêineres (como iniciar e interromper eles). Portanto, não é possível usar comandos do Docker ou a API Docker para visualizar ou interagir com contêineres do GKE em execução em nós que usam imagens do containerd.

A maioria das cargas de trabalho do usuário não tem uma dependência no ambiente de execução do contêiner. O ambiente de execução do Docker também implementa o containerd, portanto, as cargas de trabalho se comportam de maneira semelhante nas imagens de nó do containerd.

Você poderá ser afetado pelas seguintes situações:

Você executa pods privilegiados que executam comandos do Docker.
Você executa scripts em nós de fora da infraestrutura do Kubernetes, por exemplo, para usar SSH para solucionar problemas.
Você executa ferramentas de terceiros que realizam operações com privilégios semelhantes.
Algumas das suas ferramentas respondem a registros específicos do Docker em seu sistema de monitoramento.
Você implanta no cluster do GKE ferramentas de geração de registros, monitoramento, segurança ou integração contínua fornecidas por terceiros. Entre em contato com esses fornecedores para confirmar o impacto.

Você não será afetado nas seguintes situações:

Você tem um pipeline de criação fora do cluster do GKE que usa o Docker para criar e enviar imagens de contêiner.
Usa os comandos docker build e docker push no cluster do GKE. As imagens de nó do Linux com containerd incluem o binário do Docker e são compatíveis com esses comandos.

Como usar pods com privilégios para acessar o Docker

Se os usuários acessarem o Docker Engine em um nó com um pod privilegiado, atualize essas cargas de trabalho para que não haja dependência direta no Docker. Por exemplo, considere migrar o processo de extração de geração de registros e monitoramento do Docker Engine para complementos do sistema do GKE.

Como criar imagens de contêiner com o containerd

Não é possível usar o containerd para criar imagens de contêiner. As imagens do Linux com o containerd incluem o binário do Docker para que você possa usar o Docker para criar e enviar imagens por push. No entanto, não recomendamos o uso de contêineres individuais e nós locais para executar comandos para criar imagens.

O Kubernetes não tem conhecimento dos recursos de sistema usados pelos processos locais fora do escopo dele, e o plano de controle do Kubernetes não pode contabilizar esses processos ao alocar recursos. Isso pode prejudicar suas cargas de trabalho de recursos do GKE ou causar instabilidade no nó.

Considere realizar essas tarefas usando outros serviços fora do escopo do contêiner individual, como o Cloud Build, ou use uma ferramenta como o kaniko para criar imagens como uma carga de trabalho do Kubernetes.

Se nenhuma dessas sugestões funcionar para você e você entender os riscos, poderá continuar usando o Docker no nó local para criar imagens. É necessário enviar as imagens para um registro antes de usá-las em um Cluster do GKE. O Kubernetes com containerd não está ciente das imagens criadas localmente usando o Docker.

Como depurar contêineres em nós containerd

Para depurar o nó ou solucionar problemas dele no Linux, use o containerd na ferramenta de linha de comando portátil crictl, criada para os ambientes de execução de contêiner do Kubernetes. O crictl é compatível com funcionalidades comuns para visualizar contêineres e imagens, ler registros e executar comandos nos contêineres. Consulte o guia do usuário básico para um conjunto completo de recursos compatíveis e informações de uso.

Para os nós do Windows Server, o daemon do containerd é executado como um serviço do Windows chamado containerd.

Os registros estão disponíveis da seguinte forma:

Windows: C:\etc\kubernetes\logs\containerd.log
Linux: execute journalctl -u containerd

Também é possível ver os registros dos nós do Windows e do Linux no Explorador de registros em LOG NAME: "container-runtime".

Solução de problemas

Para solucionar problemas, acesse Resolver problemas no ambiente de execução do containerd.