A partir da v1.20, o Kubernetes está descartando o Docker como um ambiente deexecução decontêiner.
Mas não entre em pânico. Nem tudo é tão ruim quanto parece à primeira vista.
TL; DR. O Kubernetes está substituindo o Docker em favor dos tempos de execução da Container Runtime Interface (CRI) projetados especificamente para o Kubernetes. As imagens do Docker continuarão funcionando normalmente em todos os tempos de execução.
Para usuários finais do Kubernetes, pouca coisa mudará. Tudo isso não significa que o Docker "morrerá" ou que deva / não deva mais ser usado para desenvolvimento. O Docker continuará a ser uma ótima ferramenta para a construção de contêineres, e as imagens criadas com ele
docker build
continuarão sendo executadas no cluster K8s.
Se você estiver usando serviços Kubernetes gerenciados, como GKE ou EKS, certifique-se de que seus workers estejam usando uma versão compatível do tempo de execução antes que o suporte do Docker seja removido em uma versão futura do K8s. Se os seus nós tiverem configurações específicas, você provavelmente precisará fazer upgrade para atender aos requisitos de ambiente e tempo de execução apropriados. Recomendamos que você entre em contato com seu provedor de serviços e discuta todos os problemas de teste e planejamento de atualização.
Se você mesmo implantar os clusters, também terá que fazer as alterações apropriadas para evitar problemas. Ao atualizar para a v1.20, você receberá um aviso de suspensão de uso do Docker. Os desenvolvedores planejam abandonar completamente o Docker na versão 1.23, cujo lançamento está agendado para o final de 2021. Com seu lançamento, você terá que mudar para um dos ambientes executáveis compatíveis - por exemplo, containerd ou CRI-O. Apenas certifique-se de que o ambiente escolhido oferece suporte às configurações daemon do Docker que você está usando (por exemplo, registro)
Sobre o que é toda essa confusão e por que todos estão tão preocupados?
Na verdade, estamos falando de dois ambientes completamente diferentes, e isso cria confusão. Dentro do cluster Kubernetes, há um chamado tempo de execução do contêiner , que é responsável por carregar e executar as imagens do contêiner. E o Docker é bastante popular como uma ferramenta para organizar este ambiente (containerd e CRI-O também são amplamente conhecidos). No entanto, o Docker não foi projetado para ser incorporado ao Kubernetes e isso apresenta vários problemas.
"Docker" não é uma ferramenta separada, mas uma pilha de tecnologia inteira, e um de seus componentes é chamado de "containerd" (escrevemos sobre isso em mais detalhes aqui - aprox. Transl.)e atua como um tempo de execução de alto nível para contêineres. Docker é popular e conveniente devido ao grande número de add-ons para usuários que simplificam muito o processo de interação com esta ferramenta durante o desenvolvimento. No entanto, todos esses aprimoramentos de UX são desnecessários para o Kubernetes, porque ele não é humano.
Por causa desse nível de abstração amigável, o cluster Kubernetes é forçado a usar outra ferramenta, Dockershim, para "alcançar" o que realmente precisa: containerd. E isso é ruim, uma vez que essa camada adicional precisa ser reparada e também pode "quebrar". Na realidade, acontece o seguinte: no Kubernetes v1.23, o Dockershim será removido do Kubelet - portanto, o Docker perderá o suporte como um tempo de execução do contêiner. Surge a pergunta: se o containerd já está incluído na pilha do Docker, por que o Kubernetes precisa do Dockershim?
A questão é que o Docker não é compatível com a Container Runtime Interface.(CRI). Se fosse compatível, não precisaríamos de uma camada extra e tudo estaria ótimo. No entanto, este não é o fim do mundo e não é um motivo para pânico. Basta substituir o tempo de execução do Docker por um que seja compatível.
Observe que se você estiver usando o soquete do Docker (
/var/run/docker.sock
) como parte de um fluxo de trabalho normal, depois de alternar para outro ambiente, não será mais possível trabalhar com ele. Esse padrão é frequentemente referido como "Docker no Docker". Existem muitas ferramentas diferentes para contornar este problema, incluindo kaniko , img e buildah .
Como essa mudança afetará os desenvolvedores? Ainda vamos escrever Dockerfiles? Devemos construir imagens usando Docker?
Essa mudança tão comentada é sobre um ambiente completamente diferente daquele que a maioria das pessoas usa para interagir com o Docker. A instalação do Docker para desenvolvimento não tem nada a ver com o tempo de execução dentro do cluster Kubernetes. Sim, isso é confuso, eu sei ...
Mesmo depois da inovação, o Docker permanecerá a mesma ferramenta útil para desenvolvedores. As imagens geradas pelo Docker podem funcionar com mais do que apenas o Docker. Estas são imagens OCI completas. Qualquer imagem compatível com OCI terá a mesma aparência no Kubernetes, independentemente da ferramenta com a qual foi criada. O containerd e o CRI-O são ótimos para buscar essas imagens e executá-las. É por isso que o padrão de contêiner foi criado.
Então, as mudanças estão chegando. É claro que algumas pessoas terão certos problemas. Mas não há nada para se lamentar ou se preocupar, porque o progresso é uma coisa legal. Dependendo de como você usa o Kubernetes, isso pode significar total inação ou um mínimo de esforço para você. No longo prazo, essa inovação só tornará as coisas mais fáceis.
Se as próximas mudanças ainda estão confundindo você, você está bem. Existem muitas peças móveis no Kubernetes, e ninguém é 100% especialista nisso. Fique à vontade para fazer qualquer pergunta, independentemente do nível de experiência ou dificuldade! Nosso objetivo é preparar a todos, tanto quanto possível, para as próximas mudanças. <3 Esperamos que esta postagem tenha respondido à maioria de suas perguntas e dissipado todas as preocupações e preocupações!
Precisa de mais respostas? Confira as perguntas frequentes sobre suspensão de uso do Dockershim .
PS do tradutor
Você também pode encontrar uma resposta detalhada de Tim Hockin , um dos desenvolvedores do Kubernetes, na discussão deste tópico no Reddit .
Leia também em nosso blog:
- "Um tempo de execução maduro para contêineres: o containerd se tornou um " graduado "do CNCF ;
- « Of Red Hat substitui Docker em Podman »;
- "A integração do containerd com o Kubernetes, substituindo o Docker, está pronta para produção ";
- « CRI-O - Alternativa Docker para rodar em containers Kubernetes ».