This article is more than one year old. Older articles may contain outdated content. Check that the information in the page has not become incorrect since its publication.

Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim

Esta é uma atualização do artigo original FAQ sobre a depreciação do Dockershim, publicado no final de 2020.

Este documento aborda algumas perguntas frequentes sobre a descontinuação e remoção do dockershim, que foi anunciado como parte do lançamento do Kubernetes v1.20. Para obter mais detalhes sobre o que isso significa, confira a postagem do blog Não entre em pânico: Kubernetes e Docker.

Além disso, você pode ler verifique se a remoção do dockershim afeta você para determinar qual impacto a remoção do dockershim teria para você ou para sua organização.

Como o lançamento do Kubernetes 1.24 se tornou iminente, estamos trabalhando bastante para tentar fazer uma transição suave.

Por que o dockershim está sendo removido do Kubernetes?

As primeiras versões do Kubernetes funcionavam apenas com um ambiente de execução de contêiner específico: Docker Engine. Mais tarde, o Kubernetes adicionou suporte para trabalhar com outros agentes de execução de contêiner. O padrão CRI (Container Runtime Interface ou Interface de Agente de Execução de Containers) foi criado para habilitar a interoperabilidade entre orquestradores (como Kubernetes) e diferentes agentes de execução de contêiner. O Docker Engine não implementa essa interface (CRI), então o projeto Kubernetes criou um código especial para ajudar na transição, e tornou esse código dockershim parte do projeto Kubernetes.

O código dockershim sempre foi destinado a ser uma solução temporária (daí o nome: shim). Você pode ler mais sobre a discussão e o planejamento da comunidade na Proposta de remoção do Dockershim para aprimoramento do Kubernetes. Na verdade, manter o dockershim se tornou um fardo pesado para os mantenedores do Kubernetes.

Além disso, recursos que são amplamente incompatíveis com o dockershim, como cgroups v2 e namespaces de usuário estão sendo implementados nos agentes de execução de CRI mais recentes. A remoção do suporte para o dockershim permitirá um maior desenvolvimento nessas áreas.

Ainda posso usar o Docker Engine no Kubernetes 1.23?

Sim, a única coisa que mudou na versão 1.20 é a presença de um aviso no log de inicialização do kubelet se estiver usando o Docker Engine como agente de execução de contêiner. Você verá este aviso em todas as versões até 1.23. A remoção do dockershim ocorre no Kubernetes 1.24.

Quando o dockershim será removido?

Dado o impacto dessa mudança, estamos definindo um cronograma de depreciação mais longo. A remoção do dockershim está agendada para o Kubernetes v1.24, consulte a Proposta de remoção do Dockershim para aprimoramento do Kubernetes. O projeto Kubernetes trabalhará em estreita colaboração com fornecedores e outros ecossistemas para garantir uma transição suave e avaliará os acontecimentos à medida que a situação for evoluindo.

Ainda posso usar o Docker Engine como meu agente de execução do contêiner?

Primeiro, se você usa o Docker em seu próprio PC para desenvolver ou testar contêineres: nada muda. Você ainda pode usar o Docker localmente, independentemente dos agentes de execução de contêiner que você usa em seus Clusters Kubernetes. Os contêineres tornam esse tipo de interoperabilidade possível.

Mirantis e Docker comprometeram-se a manter um adaptador substituto para o Docker Engine, e a manter este adaptador mesmo após o dockershim ser removido do Kubernetes. O adaptador substituto é chamado cri-dockerd.

Minhas imagens de contêiner existentes ainda funcionarão?

Sim, as imagens produzidas a partir do docker build funcionarão com todas as implementações do CRI. Todas as suas imagens existentes ainda funcionarão exatamente da mesma forma.

E as imagens privadas?

Sim. Todos os agentes de execução de CRI são compatíveis com as mesmas configurações de segredos usadas no Kubernetes, seja por meio do PodSpec ou ServiceAccount.

Docker e contêineres são a mesma coisa?

Docker popularizou o padrão de contêineres Linux e tem sido fundamental no desenvolvimento desta tecnologia. No entanto, os contêineres já existiam no Linux há muito tempo. O ecossistema de contêineres cresceu para ser muito mais abrangente do que apenas Docker. Padrões como o OCI e o CRI ajudaram muitas ferramentas a crescer e prosperar no nosso ecossistema, alguns substituindo aspectos do Docker, enquanto outros aprimoram funcionalidades já existentes.

Existem exemplos de pessoas que usam outros agentes de execução de contêineres em produção hoje?

Todos os artefatos produzidos pelo projeto Kubernetes (binários Kubernetes) são validados a cada lançamento de versão.

Além disso, o projeto kind vem usando containerd há algum tempo e tem visto uma melhoria na estabilidade para seu caso de uso. Kind e containerd são executados várias vezes todos os dias para validar quaisquer alterações na base de código do Kubernetes. Outros projetos relacionados seguem um padrão semelhante, demonstrando a estabilidade e usabilidade de outros agentes de execução de contêiner. Como exemplo, o OpenShift 4.x utiliza o agente de execução CRI-O em produção desde junho de 2019.

Para outros exemplos e referências, dê uma olhada em projetos adeptos do containerd e CRI-O, dois agentes de execução de contêineres sob o controle da Cloud Native Computing Foundation (CNCF).

As pessoas continuam referenciando OCI, o que é isso?

OCI significa Open Container Initiative (ou Iniciativa Open Source de Contêineres), que padronizou muitas das interfaces entre ferramentas e tecnologias de contêiner. Eles mantêm uma especificação padrão para imagens de contêiner (OCI image-spec) e para contêineres em execução (OCI runtime-spec). Eles também mantêm uma implementação real da especificação do agente de execução na forma de runc, que é o agente de execução padrão para ambos containerd e CRI-O. O CRI baseia-se nessas especificações de baixo nível para fornecer um padrão de ponta a ponta para gerenciar contêineres.

Qual implementação de CRI devo usar?

Essa é uma pergunta complexa e depende de muitos fatores. Se você estiver trabalhando com Docker, mudar para containerd deve ser uma troca relativamente fácil e terá um desempenho estritamente melhor e menos sobrecarga. No entanto, nós encorajamos você a explorar todas as opções do cenário CNCF, pois outro agente de execução de contêiner pode funcionar ainda melhor para o seu ambiente.

O que devo ficar atento ao mudar a minha implementação de CRI utilizada?

Embora o código de conteinerização base seja o mesmo entre o Docker e a maioria dos CRIs (incluindo containerd), existem algumas poucas diferenças. Alguns pontos a se considerar ao migrar são:

  • Configuração de log
  • Limitações de recursos de agentes de execução
  • Scripts de provisionamento que chamam o docker ou usam o docker por meio de seu soquete de controle
  • Plugins kubectl que exigem CLI do docker ou o soquete de controle
  • Ferramentas do projeto Kubernetes que requerem acesso direto ao Docker Engine (por exemplo: a ferramenta depreciada kube-imagepuller)
  • Configuração de funcionalidades como registry-mirrors e registries inseguros
  • Outros scripts de suporte ou daemons que esperam que o Docker Engine esteja disponível e seja executado fora do Kubernetes (por exemplo, agentes de monitoramento ou segurança)
  • GPUs ou hardware especial e como eles se integram ao seu agente de execução e ao Kubernetes

Se você usa solicitações ou limites de recursos do Kubernetes ou usa DaemonSets para coleta de logs em arquivos, eles continuarão a funcionar da mesma forma. Mas se você personalizou sua configuração dockerd, você precisará adaptá-la para seu novo agente de execução de contêiner assim que possível.

Outro aspecto a ser observado é que ferramentas para manutenção do sistema ou execuções dentro de um contêiner no momento da criação de imagens podem não funcionar mais. Para o primeiro, a ferramenta crictl pode ser utilizada como um substituto natural (veja migrando do docker cli para o crictl) e para o último, você pode usar novas opções de construções de contêiner, como img, buildah, kaniko, ou buildkit-cli-for-kubectl que não requerem Docker.

Para containerd, você pode começar com sua documentação para ver quais opções de configuração estão disponíveis à medida que você vá realizando a migração.

Para obter instruções sobre como usar containerd e CRI-O com Kubernetes, consulte o documentação do Kubernetes em Agentes de execução de contêineres

E se eu tiver mais perguntas?

Se você usa uma distribuição do Kubernetes com suporte do fornecedor, pode perguntar a eles sobre planos de atualização para seus produtos. Para perguntas de usuário final, poste-as no nosso fórum da comunidade de usuários: https://discuss.kubernetes.io/.

Você também pode conferir a excelente postagem do blog Espere, o Docker está depreciado no Kubernetes agora?, uma discussão técnica mais aprofundada sobre as mudanças.

Posso ganhar um abraço?

Sim, ainda estamos dando abraços se solicitado. 🤗🤗🤗