Esta página fornece informações sobre o tempo de execução do contentor containerd, o suporte para o Docker no Google Kubernetes Engine (GKE) e uma vista geral do motivo pelo qual tem de migrar para imagens de nós que usam o containerd. Para obter instruções sobre como migrar para uma imagem de nó do containerd, consulte o artigo Migre do Docker para imagens de nós do containerd.
Vista geral
Os nós do Kubernetes usam o tempo de execução do contentor para iniciar, gerir e parar contentores em execução em Pods. O projeto Kubernetes vai remover o suporte incorporado para o tempo de execução do Docker na versão 1.24 e posteriores do Kubernetes. Para o conseguir, o Kubernetes vai remover um componente denominado dockershim, que permite ao Docker comunicar com componentes do Kubernetes, como o kubelet.
O Containerd, o novo tempo de execução predefinido, é um tempo de execução de contentores da norma da indústria suportado pelo Kubernetes e usado por muitos outros projetos. O tempo de execução do containerd fornece a abstração de camadas que permite a implementação de um conjunto avançado de funcionalidades, como o gVisor e o streaming de imagens, para expandir a funcionalidade do GKE. O tempo de execução também é considerado mais eficiente em termos de recursos e seguro do que o tempo de execução do Docker.
Devido a esta alteração, o GKE não suporta imagens de nós que usem o Docker como tempo de execução na versão 1.24 e posteriores do GKE. Um cluster é afetado se algum dos respetivos conjuntos de nós usar imagens de nós baseadas no Docker ou usar o aprovisionamento automático de nós com um tipo de imagem de nó predefinido baseado no Docker.
Antes de 31 de julho de 2023, a data de fim de vida da versão 1.23 do GKE, o GKE pausa as atualizações automáticas e impede as atualizações manuais para a versão 1.24. Para atualizar o plano de controlo do cluster para a versão 1.24 ou posterior do GKE antes desta data, tem de atualizar a configuração de aprovisionamento automático de nós e todos os nós para o tempo de execução do containerd. Para atualizar um conjunto de nós, tem de migrar para uma imagem do nó que use o tempo de execução do containerd.
Após a versão 1.23 atingir o fim de vida, o GKE desbloqueia as atualizações manuais do plano de controlo para a versão 1.24 para clusters que ainda não tenham concluído a migração e começa a atualizar os clusters gradualmente para fins de segurança e compatibilidade. Para saber mais sobre como o GKE atualiza os seus clusters para a versão 1.24 e o que recomendamos que faça para migrar os seus clusters de imagens de nós do Docker, consulte o artigo Migração automática quando a versão 1.23 atinge o fim do ciclo de vida.
Imagens de nós do Docker e do containerd
O Containerd é o tempo de execução predefinido 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 GKE Standard também continuaram a suportar imagens de nós que usavam o Docker como tempo de execução. A tabela seguinte descreve as imagens de nós baseadas no Docker que não vão ser suportadas na versão 1.24 e posteriores do GKE, e os equivalentes do containerd:
| Tempo de execução do Docker | Tempo de execução do containerd |
|---|---|
SO otimizado para contentores com Docker (cos) |
SO otimizado para contentores 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 o containerd (windows_ltsc_containerd) |
Windows Server SAC com Docker ( |
Windows Server SAC com o containerd ( |
Linha cronológica e marcos
Na versão 1.23 do GKE, já não pode fazer o seguinte:
- Crie novos clusters que usem imagens de nós baseadas no Docker.
- Adicione novos node pools com imagens de nós baseadas no Docker a um cluster existente.
- Ative o aprovisionamento automático de nós com a flag
--autoprovisioning-image-typedefinida para imagens de nós baseadas no Docker.
Se estiver a atualizar para a versão 1.23 do GKE, pode continuar a usar o seguinte:
- Node pools existentes com imagens de nós baseadas no Docker criadas antes da atualização.
- Redimensionador automático de cluster em node pools com imagens de nós do Docker.
- Aprovisionamento automático de nós com a flag
--autoprovisioning-image-typedefinida para imagens de nós baseadas no Docker, se estiver ativado antes da atualização.
Na versão 1.24 do GKE, já não pode fazer o seguinte:
- Se o plano de controlo executar a versão 1.24, não pode usar o aprovisionamento automático de nós com a flag
--autoprovisioning-image-typedefinida para imagens de nós baseadas no Docker. - Se o conjunto de nós executar a versão 1.24, os nós não podem usar imagens de nós baseadas no Docker.
A tabela seguinte apresenta um resumo das alterações que pode esperar quando interagir com as próximas versões do GKE:
| Ação | GKE versão 1.23 | GKE versão 1.24 |
|---|---|---|
| Crie novos clusters com o Docker | Não | Não |
| Crie novos node pools com o Docker | Não | Não |
| Ative o aprovisionamento automático de nós com o Docker | Não | Não |
| Atualize a versão anterior com a configuração de aprovisionamento automático do nó do Docker existente | Sim | Não |
| Use imagens de nós baseadas no Docker | Sim | Não |
Migração automática quando a versão 1.23 atinge o fim do ciclo de vida
Se não atualizar para a versão 1.24 e migrar para imagens de nós do containerd antes de a versão 1.23 atingir o fim do ciclo de vida a 31 de julho de 2023, o GKE faz o seguinte ao longo do tempo:
Se o seu cluster tiver o aprovisionamento automático de nós com um tipo de imagem de nó predefinido baseado no Docker, o GKE atualiza a configuração para usar a imagem de nó equivalente que usa o tempo de execução do containerd. Não pode bloquear esta operação com uma exclusão de manutenção. Para verificar que não existe nenhum efeito adverso nas suas cargas de trabalho, recomendamos que atualize manualmente o tipo de imagem predefinido da administração de contas automática de nós para uma imagem baseada em containerd antes de o GKE atualizar automaticamente a configuração.
O GKE atualiza o painel de controlo do cluster para a versão 1.24.
O GKE migra todos os conjuntos de nós que ainda usam o Docker para imagens de nós do containerd a partir de 1 de setembro de 2023. Recomendamos que migre manualmente as imagens dos nós antes desta data. Em alternativa, pode pedir que o GKE inicie uma operação para migrar o seu cluster para usar imagens do containerd. Para fazer este pedido, contacte o apoio ao cliente do Google Cloud.
Para bloquear temporariamente a migração automática, atualize o cluster para a versão 1.24 ou posterior e configure uma exclusão de manutenção. Para mais informações sobre esta exclusão de manutenção, consulte o artigo Atrasar temporariamente a migração automática para imagens de nós do containerd.
O GKE atualiza os node pools na versão 1.23 para a 1.24, tal como acontece com qualquer versão não suportada, para garantir o alinhamento do estado do cluster com a política de variação da versão de código aberto. Para saber mais, consulte o ciclo de vida da versão secundária do GKE. Pode bloquear temporariamente esta atualização com uma exclusão de manutenção.
Atrasar temporariamente a migração automática para imagens de nós do containerd
Depois de o painel de controlo do cluster ter sido atualizado para a versão 1.24 ou posterior, pode
configurar uma exclusão de manutenção
para impedir temporariamente a migração dos nós até 29 de fevereiro de 2024,
quando a versão 1.25 atingir o
fim do apoio técnico.
Para ser elegível para esta exclusão de manutenção, o cluster tem de estar inscrito num
canal de
lançamento.
Configure a exclusão de manutenção com o âmbito"Nenhuma atualização secundária ou de nós" e defina a flag --add-maintenance-exclusion-end para 2024-02-29T00:00:00Z ou anterior. Recomendamos que desbloqueie a migração assim que possível e
permita que os nós sejam atualizados para a versão 1.24. As versões secundárias que atingiram o fim do suporte técnico vão deixar de receber patches de segurança e correções de erros.
Migre do Docker para imagens de nós do containerd
Consulte o artigo Migre de imagens de nós do Docker para imagens de nós do containerd para identificar clusters e pools de nós que usam imagens de nós baseadas no Docker e migrar esses pools de nós para imagens de nós do containerd.
Como parte do modelo de responsabilidade partilhada do GKE, é da responsabilidade do cliente manter o bom funcionamento das cargas de trabalho, e é da responsabilidade da Google garantir que o cluster permanece funcional, o que inclui a execução de uma versão suportada. Recomendamos vivamente que teste as suas cargas de trabalho e migre o cluster antes de o GKE o fazer automaticamente.
Antes de a versão 1.23 atingir o fim do apoio técnico, o GKE impede atualizações automáticas ou manuais para a versão 1.24 para clusters que tenham pools de nós que usam imagens de nós do Docker. Depois de migrar o cluster para usar apenas imagens do containerd, as atualizações automáticas podem ser retomadas no prazo de um dia, de acordo com o cronograma de lançamentos do GKE, ou pode atualizar manualmente o cluster.
Após o fim do apoio técnico da versão 1.23, o GKE desbloqueia as atualizações automáticas ou manuais para a versão 1.24 e segue o processo de migração automática.
Impacto da migração
A principal alteração quando migra para imagens de nós do containerd é que o Docker deixa de gerir o ciclo de vida dos seus contentores (como iniciá-los e pará-los). Por conseguinte, não pode usar comandos do Docker nem a API Docker para ver ou interagir com contentores do GKE executados em nós que usam imagens do containerd.
A maioria das cargas de trabalho dos utilizadores não tem uma dependência do tempo de execução do contentor. O tempo de execução do Docker também implementa o containerd, pelo que as suas cargas de trabalho têm um comportamento semelhante nas imagens de nós do containerd.
Pode ser afetado se as seguintes situações se aplicarem:
- Executa pods privilegiados que executam comandos Docker.
- Executa scripts em nós a partir do exterior da infraestrutura do Kubernetes (por exemplo, para usar o SSH para resolver problemas).
- Executa ferramentas de terceiros que realizam operações com privilégios semelhantes.
- Algumas das suas ferramentas respondem a registos específicos do Docker no seu sistema de monitorização.
- Implementa ferramentas de registo, monitorização, segurança ou integração contínua fornecidas por fornecedores externos no seu cluster do GKE. Contacte estes fornecedores para confirmar o impacto.
Não é afetado nas seguintes situações:
- Tem um pipeline de compilação fora do cluster do GKE que usa o Docker para compilar e enviar imagens de contentores.
- Usar comandos
docker buildedocker pushno cluster do GKE. As imagens de nós Linux com o containerd incluem o binário do Docker e suportam estes comandos.
Usar pods privilegiados para aceder ao Docker
Se os seus utilizadores acederem ao Docker Engine num nó através de um pod privilegiado, deve atualizar essas cargas de trabalho para que não haja uma dependência direta do Docker. Por exemplo, considere migrar o processo de extração de registos e monitorização do Docker Engine para suplementos do sistema GKE.
Criar imagens de contentores com o containerd
Não pode usar o containerd para criar imagens de contentores. As imagens Linux com o containerd incluem o binário do Docker para que possa usar o Docker para criar e enviar imagens. No entanto, não recomendamos a utilização de contentores individuais e nós locais para executar comandos de criação de imagens.
O Kubernetes não tem conhecimento dos recursos do sistema usados por processos locais fora do âmbito do Kubernetes, e o painel de controlo do Kubernetes não pode ter em conta esses processos ao atribuir recursos. Isto pode privar as cargas de trabalho do GKE de recursos ou causar instabilidade no nó.
Considere realizar estas tarefas através de outros serviços fora do âmbito do contentor individual, como o Cloud Build, ou use uma ferramenta como o kaniko para criar imagens como uma carga de trabalho do Kubernetes.
Se nenhuma destas sugestões funcionar para si e compreender os riscos, pode continuar a usar o Docker no nó local para criar imagens. Tem de enviar as imagens para um registo antes de as poder usar num cluster do GKE. O Kubernetes com o containerd não tem conhecimento das imagens criadas localmente com o Docker.
Depurar contentores em nós do containerd
Para depurar ou resolver problemas em nós Linux, pode interagir com o
containerd através da ferramenta de linha de comandos portátil criada para os tempos de execução
de contentores do Kubernetes: crictl. O crictl suporta funcionalidades comuns para ver contentores e imagens, ler registos e executar comandos nos contentores. Consulte o
manual do utilizador do crictl
para ver o conjunto completo de funcionalidades suportadas e informações de utilização.
Para nós do Windows Server, o daemon containerd é executado como um serviço do Windows com o nome containerd.
Os registos estão disponíveis da seguinte forma:
- Windows:
C:\etc\kubernetes\logs\containerd.log - Linux: execute
journalctl -u containerd
Também pode ver os registos dos nós do Windows e Linux no Explorador de registos
em LOG NAME: "container-runtime".
Resolução de problemas
Para a resolução de problemas, aceda a Resolva problemas com o tempo de execução do containerd.
O que se segue?
- Leia sobre a descontinuação do dockershim.
- Verifique se a descontinuação afeta a sua conta.
- Migre do Docker para imagens de nós do containerd.