O que é containerd e como ele se relaciona com o Docker e o Kubernetes?

Os contêineres ainda significam “ Docker ” para muitas pessoas. Docker popularizou o uso moderno de contêineres no desenvolvimento e implantação de software. Hoje em dia, outras tecnologias também estão por aí. Veja como Containerd, Docker e Kubernetes se relacionam.

O começo

Em seu lançamento em 2013, o Docker era um projeto independente com tudo que você precisava para construir e executar contêineres. O que faltava era uma maneira fácil de orquestrar implantações de contêiner na nuvem.

No final de 2013, um grupo de Googlers já tratava disso com um protótipo do que se tornaria o Kubernetes. O Kubernetes visa simplificar a operação de cargas de trabalho em contêineres em grandes frotas de máquinas.

Naquela época, o Kubernetes estava inextricavelmente ligado ao Docker. Ele usava o Docker diretamente para interagir com os contêineres, embora precisasse apenas de um subconjunto de funcionalidades – as partes responsáveis ​​por realmente operar os contêineres.

A IU centrada no desenvolvedor do Docker atrapalhou o Kubernetes. Ele teve que contornar os aspectos humanos do projeto usando uma ferramenta dedicada, Dockershim. Os problemas foram agravados pelas direções diferentes que o Docker e o Kubernetes estavam tomando. O Docker lançou o Swarm, sua própria alternativa ao Kubernetes, oferecendo orquestração como um “ modo ” integrado do Docker.

A ascensão do Containerd

Conforme o Kubernetes cresceu e mais ferramentas de terceiros surgiram em torno do Docker, as limitações de sua arquitetura tornaram-se claras. Ao mesmo tempo, a Open Container Initiative (OCI) começou a padronizar formatos de contêiner e tempos de execução. Isso resultou em uma especificação OCI definindo um contêiner que poderia ser usado por vários tempos de execução, do qual Docker é um exemplo.

O Docker então extraiu o tempo de execução do contêiner em um novo projeto, containerd. Isso inclui a funcionalidade do Docker para executar contêineres, lidar com armazenamento de baixo nível e gerenciar transferências de imagens. O Containerd foi doado à Cloud Native Computing Foundation (CNCF) para fornecer à comunidade de contêineres uma base para a criação de novas soluções de contêineres.

O surgimento do containerd torna mais fácil para projetos como o Kubernetes acessar o “ Docker ” de baixo nível; elementos de que precisam. Em vez de realmente usar o Docker, eles agora têm uma interface mais acessível para o tempo de execução do contêiner. A padronização OCI de tecnologias de contêiner significa que outros tempos de execução também podem ser usados.

Compreendendo a função do Containerd

Para compreender totalmente o container, é necessário observar a natureza dos containers. Os contêineres são realmente uma abstração de vários recursos do kernel do Linux. Para executar um contêiner, você precisa usar syscalls para configurar o ambiente em contêiner. As etapas variam de acordo com a plataforma e distribuição.

A Containerd aparece para abstrair essa fiação de baixo nível. Pretende-se que seja uma “ camada do cliente ” que o software do contêiner então é construído sobre. Pode ser um software orientado para o desenvolvedor, como o Docker, ou ferramentas de desenvolvimento orientadas para a nuvem, como o Kubernetes.

Anteriormente, o desenvolvimento do Kubernetes tinha duas opções ruins: continuar escrevendo correções na interface robusta do Docker ou começar a interagir com os recursos do kernel do Linux diretamente. Ao quebrar o containerd do Docker, uma terceira alternativa se tornou disponível: use o containerd como uma camada de abstração do sistema, sem envolver o Docker.

Aqui está um resumo de como as três tecnologias se combinam:

• Docker – Um software voltado para o desenvolvedor com uma interface de alto nível que permite criar e executar contêineres facilmente a partir de seu terminal. Agora ele usa containerd como seu tempo de execução do contêiner.
• Containerd – Uma abstração dos recursos do kernel que fornece uma interface de contêiner de nível relativamente alto. Outros projetos de software podem usar isso para executar contêineres e gerenciar imagens de contêiner.
• Kubernetes – Um orquestrador de contêineres que funciona com vários tempos de execução de contêiner, incluindo containerd. O Kubernetes se concentra na implantação de contêineres agregados em um ou mais nós “ físicos. ” Historicamente, o Kubernetes estava vinculado ao Docker.

O containerd é apenas um back-end do contêiner. Outros contêineres que implementam a especificação Open Containers Runtime incluem runC e CRI-O. Esses tempos de execução também podem ser usados ​​com Docker e Kubernetes; cada um tem suas próprias distinções.

O OCI

O OCI é o órgão responsável pela definição dos padrões de contêineres. Seu trabalho tem sido fundamental para facilitar a interoperabilidade entre diferentes tecnologias de componentes.

A especificação de imagem da OCI define a aparência de um contêiner. A especificação de tempo de execução define uma interface para a execução de contêineres. Em seguida, projetos como o containerd implementam essas especificações.

É importante ressaltar que uma das prioridades da OCI é oferecer suporte à experiência de uso de contêiner popularizada pelo Docker. Suas imagens devem ser executáveis ​​na plataforma de destino sem nenhum argumento definido pelo usuário (por exemplo, docker run hello-world: latest). As imagens OCI devem, portanto, conter metadados suficientes para permitir essa configuração automática.

Você também pode ver referências à Container Runtime Interface (CRI). Esta é uma abstração específica do Kubernetes sobre a especificação OCI. O CRI se baseia nas especificações OCI para permitir o suporte para tempos de execução de contêiner intercambiáveis ​​dentro do Kubernetes.

E as minhas imagens do Docker?

As imagens que você cria com o Docker não são realmente “ imagens do Docker ” de forma alguma. Como o Docker agora usa o tempo de execução containerd, suas imagens são construídas no formato padronizado Open Container Initiative (OCI).

Você não deve se preocupar com incompatibilidades entre suas imagens do Docker e o ambiente em que elas são usadas. As imagens que você cria com o Docker ainda podem ser implantadas usando o Kubernetes. Isso ocorre porque o Kubernetes também oferece suporte a imagens OCI, por meio do uso de containerd (e outros tempos de execução em conformidade com os padrões). Cabe ao tempo de execução lidar com a extração e execução de imagens, não a interface de alto nível que ferramentas como Docker e Kubernetes fornecem.

Kubernetes e Docker

O Kubernetes suspendeu o uso do Docker Runtime no final de 2020. Ele será removido em uma versão futura, atualmente agendada para o final de 2021. Depois disso, o Kubernetes não oferecerá mais suporte ao Docker Runtime. Em vez disso, será necessário usar um tempo de execução alternativo compatível com as especificações OCI, como containerd.

Este anúncio gerou preocupação sobre as implicações para os desenvolvedores. A alteração não deve afetar a maioria dos fluxos de trabalho existentes. Como já vimos, o Docker produz imagens compatíveis com OCI que podem ser executadas em tempos de execução compatíveis. Todas as imagens que você criar com a compilação do docker ainda funcionarão no Kubernetes, mesmo depois que o tempo de execução do Docker for removido.

Duas tecnologias diferentes estão sendo consideradas – a interface de linha de comando do Docker usada para criar e executar contêineres e o tempo de execução do Docker que a interface de linha de comando envolve.

É muito confuso!

Em poucos anos, os contêineres transformaram o número de desenvolvedores que trabalham. A expansão no ecossistema circundante foi um subproduto natural dessa mudança. Os contêineres === A mentalidade do Docker provou ser muito sufocante, pois impedia que ferramentas como o Kubernetes mostrassem todo o seu potencial.

O movimento em direção à padronização resultou em uma infinidade de novos termos, ferramentas e tecnologias. No entanto, nada mudou realmente para os desenvolvedores, quer você esteja interagindo com a CLI do Docker em sua máquina ou com um cluster Kubernetes na nuvem.

Cada interface de alto nível voltada para o usuário (como Docker e Kubernetes) agora se beneficia de uma escolha de tempos de execução de contêiner de baixo nível intercambiáveis ​​(como containerd e runC). Isso permite um maior grau de flexibilidade e permite que novas tecnologias baseadas em contêineres se estabeleçam de maneira alinhada aos padrões.