O Kubernetes 1.24 remove o componente Dockershim e deixa de oferecer suporte ao Docker como runtime de contêiner integrado. Por isso, o Container Service for Kubernetes (ACK) interrompe o suporte ao runtime Docker a partir da versão 1.24. Os nós do cluster precisam executar o containerd antes de atualizar o ACK para a versão 1.24 ou posterior.
containerd é um runtime de contêiner padrão do mercado com suporte do Kubernetes. Em comparação com o runtime Docker, o containerd inicia mais rápido, consome menos recursos e é mais seguro.
Métodos de atualização para migrar do Docker para o containerd
Antes da atualização, certifique-se de que suas cargas de trabalho não dependam do Docker nos nós para criar imagens. Na maioria dos casos, as cargas de trabalho não dependem do runtime de contêiner, e o próprio backend do Docker chama o containerd. Em teoria, suas cargas de trabalho não são afetadas após a conclusão da migração.
Migre primeiro o ambiente de teste e, em seguida, migre o ambiente de produção durante os horários de baixa demanda.
Existem dois métodos para migrar o runtime de contêiner do nó de Docker para containerd.
Método 1: Atualizar o pool de nós existente (recomendado)
Na página Node Pools, use o recurso Kubelet Update para migrar do Docker para o containerd. Esse método substitui automaticamente o disco do sistema do nó. Não armazene dados importantes no disco do sistema. Se houver dados importantes armazenados nele, faça backup dos dados antes da atualização. Os discos de dados não são afetados durante a atualização.
Acesse o ACK console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em .
Na coluna Actions do pool de nós de destino, escolha
> Kubelet Update.-
Confirme as informações de atualização do runtime e clique em Precheck. Após a aprovação da pré-verificação, siga as instruções na tela para concluir a atualização do runtime.
Para mais informações sobre as precauções e itens de configuração, consulte Upgrade a node pool .
Método 2: Criar um pool de nós containerd e migrar cargas de trabalho em revezamento (opcional)
Crie um pool de nós, escolha containerd como o runtime e adicione nós. Migre gradualmente todos os aplicativos para o novo pool de nós. Defina o pool de nós antigo como Unschedulable ou atualize suas cargas de trabalho para que sejam agendadas em um pool de nós específico (por exemplo, por meio de rótulos). Em seguida, remova o pool de nós antigo.
A remoção do pool de nós antigo é irreversível. O disco do sistema e os discos de dados de um nó compartilham o mesmo ciclo de vida. Quando um nó no pool de nós é liberado, seus discos cloud também são liberados e todos os dados neles contidos são perdidos permanentemente. As regras de liberação variam de acordo com o método de faturamento. Antes de remover o pool de nós antigo, certifique-se de que todas as cargas de trabalho estejam em execução no novo pool de nós containerd.
Para mais informações sobre como criar um pool de nós, consulte Create and manage node pools. Para mais informações sobre como definir um nó como Unschedulable, consulte Set node scheduling status.
Considerações pós-migração
Após a migração, a sintaxe principal do Dockerfile permanece inalterada. No entanto, preste atenção às configurações relacionadas ao ambiente de execução, como compatibilidade de imagem base, configurações de variáveis de ambiente e definições de comandos de runtime, para garantir que as imagens sejam executadas corretamente no ambiente containerd.
Como o containerd não oferece recursos de criação de imagens, não é mais possível usar o Docker Build para criar imagens nos nós do cluster após a conclusão da atualização. O pull de imagens não é afetado.
Após a migração do runtime de contêiner para o containerd, o Docker deixa de gerenciar o ciclo de vida do contêiner. Portanto, após a conclusão da migração, não será mais possível usar comandos do Docker ou a API do Docker nos nós para verificar o status do contêiner ou interagir com os contêineres. No entanto, você ainda pode usar comandos do containerd em vez dos comandos do Docker. Para o mapeamento entre comandos do containerd e comandos do Docker, consulte Comparison of containerd, sandboxed container, and Docker runtimes.
Como funcionam as atualizações com substituição de disco
O ACK executa a atualização com substituição de disco automaticamente na seguinte sequência para concluir a migração do Docker para o containerd:
O sistema drena o nó e o define como Unschedulable.
O sistema desliga a instância do Elastic Compute Service (ECS) e para o nó.
O sistema substitui o disco do sistema. O ID do disco do sistema muda, mas o tipo de disco cloud, o endereço IP da instância e o endereço MAC da interface de rede elástica (ENI) permanecem inalterados.
O sistema reinicializa o nó e instala o runtime containerd.
O nó reinicia, fica pronto e é definido como Schedulable.
Perguntas frequentes
Quanto tempo leva cada lote de atualização?
A migração do Docker para o containerd na página de atualização do pool de nós utiliza o método de atualização com substituição de disco. Se não houver snapshot envolvido, a atualização leva geralmente menos de 8 minutos. Caso selecione um snapshot durante a atualização, a atualização ocorre após a conclusão do snapshot, e a duração depende do tempo de criação do snapshot. O processo permite até 40 minutos para a criação do snapshot. Se o snapshot não for concluído em 40 minutos, o nó é marcado como expirado e a operação falha. Nesse momento, o nó com falha ainda não iniciou a atualização. Se não houver dados de negócios armazenados no disco do sistema, deixe a opção de snapshot desmarcada para evitar uma atualização demorada.
O número de nós atualizados em cada lote é 1, 2, 4, 8 e assim por diante, até atingir a concorrência máxima. Depois disso, cada lote atualiza o número máximo de nós permitido pela concorrência. Por exemplo, se a concorrência máxima for 4, o primeiro lote atualiza 1 nó, o segundo lote atualiza 2 nós, o terceiro lote atualiza 4 nós e cada lote subsequente atualiza 4 nós.
Meus serviços são afetados durante a atualização?
A migração do Docker para o containerd na página de atualização do pool de nós utiliza o método de atualização com substituição de disco. Uma atualização com substituição de disco drena o nó. Seus serviços não são afetados se seus pods implementarem a lógica de desligamento graceful (Graceful shutdown and zero downtime deployments in Kubernetes) e se várias réplicas estiverem implantadas em vários nós. Para evitar que várias réplicas do mesmo aplicativo sejam atualizadas no mesmo lote, defina manualmente a concorrência máxima com um valor menor que o número de réplicas de pods.
Há suporte para rollback após a migração do Docker para o containerd?
Não há suporte para rollback.
Os dados do nó são perdidos durante a migração do Docker para o containerd?
A migração do Docker para o containerd na página de atualização do pool de nós utiliza o método de atualização com substituição de disco. Como a atualização do runtime substitui o disco do sistema do nó, não armazene dados importantes no disco do sistema. Se houver dados importantes armazenados nele, faça backup dos dados antes da atualização. Os discos de dados não são afetados durante a atualização.
Após a substituição do disco do sistema do nó, o endereço IP do nó muda?
Durante a substituição do disco do sistema, o ID do disco do sistema muda, mas o tipo de disco cloud, o endereço IP da instância e o endereço MAC da ENI permanecem inalterados. Para mais informações, consulte Replace system disk (OS).
Qual é o nível de compatibilidade do containerd com o Docker?
Na maioria dos casos, suas cargas de trabalho não dependem do runtime de contêiner. O próprio backend do Docker também chama o containerd, então, em teoria, suas cargas de trabalho não são afetadas após a migração.
O próprio containerd não oferece recursos para a criação de imagens. Após a conclusão da atualização, o Docker Build deixa de estar disponível para criar imagens nos nós do cluster, embora você ainda possa fazer o pull de imagens.
Após a migração do runtime de contêiner para o containerd, o Docker deixa de gerenciar o ciclo de vida do contêiner. Como resultado, não é mais possível usar comandos do Docker ou a API do Docker nos nós para verificar o status do contêiner ou interagir com os contêineres. Portanto, gerencie o ciclo de vida usando o containerd.
O que fazer se eu criei imagens anteriormente com o Docker nos nós do cluster e o runtime foi atualizado para o containerd?
Crie imagens com o Alibaba Cloud Container Registry (ACR) ou crie imagens manualmente.
Criar imagens com o ACR (recomendado): A criação de imagens no ACR é baseada no BuildKit, a ferramenta oficial de criação de imagens do Docker. Crie uma instância do ACR para acionar automaticamente a criação de imagens com base nas regras de compilação em um Dockerfile. Execute o Dockerfile para fazer a compilação, e a imagem é enviada automaticamente para o repositório de imagens de contêiner após a conclusão da compilação. Para mais informações, consulte Build images on a Container Registry Enterprise Edition instance.
Criar imagens manualmente: Para garantir o melhor desempenho do nó, crie uma instância ECS adicional, instale o Docker manualmente nela e, em seguida, use comandos do Docker para criar imagens. Para mais informações, consulte Install and use Docker and Docker Compose.
O que fazer se o diretório do Docker não for limpo e ocupar espaço em disco após a alteração do runtime do nó de Docker para containerd?
Além dos arquivos que o cluster Kubernetes pode gerenciar, como contêineres, imagens e logs, o diretório do Docker também contém caminhos de arquivos criados por você. Caso não precise mais do diretório do Docker, exclua manualmente o diretório após a mudança do runtime.