Migrar de dockershim para containerd - Amazon EKS
Teste a migração do Amazon Linux 2 de Docker para containerd

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Escolha o link Editar esta página no GitHub, disponível no painel direito de cada página. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Migrar de dockershim para containerd

O Kubernetes não oferece mais suporte a dockershim. A equipe do Kubernetes removeu o runtime do Kubernetes versão 1.24. Para obter mais informações, consulte O Kubernetes está saindo do Dockershim: compromissos e próximos passos no blog Kubernetes.

O Amazon EKS também deixou de ser compatível com o dockershim a partir do Kubernetes versão 1.24. O único runtime das AMIs do Amazon EKS oficialmente publicadas a partir da versão 1.24 é o containerd. Esse tópico aborda alguns detalhes, mas há mais informações disponíveis em Tudo o que você precisa saber sobre a mudança para o containerd no Amazon EKS.

Existe um plug-in kubectl que você pode usar para ver quais workloads do Kubernetes montam o volume de soquete do Docker. Para obter mais informações, consulte Detector para Docker Socket (DDS) em GitHub. As AMIs do Amazon EKS que executam versões do Kubernetes anteriores à 1.24 usam o Docker como runtime padrão. Porém, essas AMIS do Amazon EKS têm uma opção de sinalizador de bootstrap que você pode usar para testar as workloads em qualquer cluster compatível que use o containerd. Para ter mais informações, consulte Teste a migração do Amazon Linux 2 de Docker para containerd.

Continuaremos a publicar AMIs para as versões do Kubernetes até o final de sua data de suporte. Para ter mais informações, consulte Calendário de lançamento do Amazon EKS Kubernetes. Se você precisar de mais tempo para testar as workloads no containerd, use uma versão compatível anterior à 1.24. Porém, quando quiser atualizar as AMIs oficiais do Amazon EKS para a versão 1.24 ou posteriores, certifique-se de validar que as workloads podem ser executadas no containerd.

O runtime containerd oferece performance e segurança mais confiáveis. O containerd é o runtime que está sendo padronizado em todo o Amazon EKS. O Fargate e o Bottlerocket já usam apenas o containerd. O containerd ajuda a minimizar o número de versões de AMI do Amazon EKS necessárias para resolver as vulnerabilidades e exposições comuns (CVEs) do dockershim. Como o dockershim já usa o containerd internamente, talvez não seja necessário fazer nenhuma alteração. No entanto, há algumas situações em que pode ser necessário fazer alterações:

  • É necessário fazer alterações nas aplicações que montam o soquete Docker. Por exemplo, imagens de contêiner que são criadas com um contêiner são afetadas. Muitas ferramentas de monitoramento também montam o soquete do Docker. Pode ser necessário aguardar atualizações ou reimplantar workloads para monitoramento de runtime.

  • Também pode ser necessário fazer alterações nas aplicações que dependem de configurações específicas do Docker. Por exemplo, o protocolo HTTPS_PROXY não é mais compatível. Será necessário atualizar as aplicações que usam esse protocolo. Para obter mais informações, consulte dockerd na Documentação do Docker.

  • Se você usar o auxiliar de credenciais do Amazon ECR para extrair imagens, será necessário alternar para o provedor de credenciais de imagem do kubelet. Para obter mais informações, consulte Configurar um provedor de credenciais de imagens do kubelet na documentação do Kubernetes.

  • Como o Amazon EKS 1.24 não é mais compatível com o Docker, alguns sinalizadores que o script de bootstrap do Amazon EKS aceitava anteriormente não são mais compatíveis. Antes de mudar para o Amazon EKS 1.24 ou posterior, você deve remover qualquer referência aos sinalizadores que não são mais compatíveis:

    • --container-runtime dockerd (O único valor compatível é containerd)

    • --enable-docker-bridge

    • --docker-config-json

  • Se você já Fluentd configurou para Container Insights, deve migrar Fluentd para Fluent Bit antes de mudar para containerd. Os analisadores Fluentd são configurados para analisar apenas mensagens de log no formato JSON. Ao contrário de dockerd, o runtime do containerd contêiner tem mensagens de log que não estão no formato JSON. Se você não migrar para Fluent Bit, alguns dos Fluentd’s analisadores configurados gerarão muitos erros dentro do Fluentd contêiner. Para obter mais informações sobre migração, consulte Configurar o Fluent Bit como um DaemonSet para enviar logs para o CloudWatch Logs.

  • Se você usa uma AMI personalizada e está fazendo o upgrade para o Amazon EKS 1.24, deve garantir que o encaminhamento de IP esteja habilitado para seus nós de processamento. Essa configuração não era necessária com o Docker, mas é necessária para o containerd. Ela é necessária para solucionar problemas de conectividade de rede Pod para Pod, Pod para externa ou Pod para apiserver.

    Para verificar essa configuração em um nó de processamento, execute um dos seguintes comandos:

    • sysctl net.ipv4.ip_forward

    • cat /proc/sys/net/ipv4/ip_forward

    Se a saída for 0, execute um dos seguintes comandos para ativar a variável net.ipv4.ip_forward do kernel:

    +

    • sysctl -w net.ipv4.ip_forward=1

    • echo 1 > /proc/sys/net/ipv4/ip_forward

Para a ativação da configuração nas AMIs do Amazon EKS para o Amazon Linux 2 no runtime containerd, consulte install-worker.sh no GitHub.

Teste a migração do Amazon Linux 2 de Docker para containerd

Para a versão 1.23 do Kubernetes, é possível usar um sinalizador de inicialização opcional para habilitar o runtime do containerd para AMIs do AL2 otimizadas para o Amazon EKS. Esse recurso fornece um caminho claro de migração para o containerd ao atualizar para a versão 1.24 ou posterior. O Amazon EKS deixou de ser compatível com o Docker a partir da versão 1.24 do Kubernetes. O runtime do containerd tem sido amplamente adotado na comunidade do Kubernetes e é um projeto graduado com a CNCF. Você pode testá-lo adicionando um grupo de nós a um cluster novo ou existente.

Você pode habilitar o sinalizador de boostrap criando um dos tipos de grupos de nós a seguir.

Autogerenciado

Crie o grupo de nós usando as instruções em Criar nós autogerenciados do Amazon Linux. Especifique uma AMI otimizada para o Amazon EKS e o texto a seguir para o parâmetro BootstrapArguments.

--container-runtime containerd
Gerenciados

Se você usar o eksctl, crie um arquivo denominado my-nodegroup.yaml com o conteúdo a seguir. Substitua cada valor de exemplo por seus próprios valores. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres. Para recuperar um ID de AMI otimizada para ami-1234567890abcdef0 , consulte Recuperar IDs de AMI do Amazon Linux recomendadas.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
nota

Se você iniciar muitos nós ao mesmo tempo, também poderá especificar valores para os argumentos de bootstrap --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip para evitar erros. Para ter mais informações, consulte Especificar uma AMI.

Execute os comandos a seguir para criar um grupo de nós.

eksctl create nodegroup -f my-nodegroup.yaml

Se preferir usar uma ferramenta diferente para criar o grupo de nós gerenciados, é necessário implantar o grupo de nós usando um modelo de execução. No seu modelo de execução, especifique um ID de AMI otimizada para Amazon EKS e implante o grupo de nós usando um modelo de execução e forneça os seguintes dados de usuário. Esses dados do usuário transmitem argumentos para o arquivo bootstrap.sh. Para obter mais informações sobre o arquivo de bootstrap, consulte bootstrap.sh no GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd