O passado, presente e futuro do Docker e outros tempos de execução de contêineres em Kubernetes

Nota perev. : Já escrevemos mais de uma publicação (consulte os links no final do artigo) sobre tempos de execução do contêiner (tempos de execução do contêiner) - como regra geral, eles são discutidos no contexto do Kubernetes. No entanto, muitas vezes esses materiais suscitaram perguntas dos leitores, indicando uma falta de entendimento de onde o próximo projeto veio, como ele está conectado com outros e o que está acontecendo em todo esse “zoológico” de contêineres.



Um artigo recente de Phil Estes, diretor técnico de arquitetura de contêineres e arquitetura Linux da IBM Watson & Cloud Platform, fornece uma excelente retrospectiva sobre como navegar e obter uma compreensão mais ampla de quem perdeu (ou nunca capturou) o encadeamento de eventos. Sendo um dos mantenedores dos projetos Moby e container, um membro dos comitês técnicos da Open Container Initiative (OCI) e da Moby, e também com o status de Docker Captain, o autor escreve sobre o passado, presente e futuro do novo mundo maravilhoso dos tempos de execução de contêineres. E para os mais preguiçosos, o material começa com um TL; DR compacto sobre o assunto ...

Principais conclusões

• Com o tempo, a escolha entre tempos de execução de contêineres aumentou, oferecendo mais opções do que o popular mecanismo Docker.
• A Open Container Initiative (OCI) padronizou com sucesso o conceito de imagem de contêiner e contêiner para garantir a interoperabilidade (“interoperabilidade” - aprox. Transl.) Entre ambientes de tempo de execução.
• O Kubernetes adicionou a Interface de Tempo de Execução do Contêiner (CRI), que permite que os contêineres se conectem aos ambientes de tempo de execução com a camada de orquestração subjacente no K8s.
• As inovações nessa área permitem que os contêineres aproveitem a virtualização leve e outras técnicas exclusivas de isolamento para aumentar os requisitos de segurança.
• Com o OCI e o CRI, a interoperabilidade e a escolha se tornaram realidade no ecossistema de ambientes de contêiner e orquestração de tempo de execução.

A tecnologia de conteinerização existe há algum tempo no mundo dos sistemas operacionais Linux - as primeiras idéias sobre espaços para nome separados para sistemas e processos de arquivos surgiram há mais de uma década. E em um passado relativamente recente, o LXC apareceu e se tornou a maneira padrão para os usuários do Linux interagirem com a poderosa tecnologia de isolamento escondida no kernel do Linux.

No entanto, apesar das tentativas do LXC de ocultar a complexidade de combinar vários "interiores" tecnológicos do que hoje chamamos de contêiner atualmente, os contêineres continuaram sendo uma espécie de mágica e se tornaram mais fortes apenas no mundo daqueles com conhecimento especial e não obtiveram ampla distribuição entre as massas.

Tudo mudou em 2014 com o Docker , quando um novo invólucro de desenvolvedor para a mesma tecnologia de kernel Linux que o LXC tinha em serviço apareceu - afinal, as versões anteriores do Docker “nos bastidores” usavam o LXC e os contêineres se tornaram - um fenômeno de massa real, pois os desenvolvedores estavam imbuídos da simplicidade e das possibilidades de reutilizar imagens de contêineres do Docker e comandos simples para trabalhar com eles.

É claro que a Docker não foi a única pessoa que queria ganhar uma participação no mercado de contêineres quando o hype que os acompanhou não pensou em diminuir após o primeiro interesse explosivo em 2014. Ao longo dos anos, surgiram várias idéias alternativas para ambientes de contêineres executáveis ​​do CoreOS (rkt) , Intel Clear Containers , hyper.sh (virtualização leve baseada em contêiner) e Singularidade e mudança no mundo da pesquisa em computação de alto desempenho (HPC).

O mercado continuou a crescer e amadurecer e, com a Open Container Initiative (OCI), veio o esforço de padronizar as idéias iniciais promovidas pela Docker. Atualmente, muitos ambientes executáveis ​​de contêineres já são compatíveis com a OCI ou estão a caminho disso, oferecendo aos fabricantes condições iguais para promover seus recursos e capacidades focados em um aplicativo específico.

Popularidade de Kubernetes

O próximo estágio na evolução dos contêineres foi combinar contêineres de computação distribuídos à microsserviços com contêineres - e tudo isso no novo mundo de iterações rápidas de desenvolvimento e implantação (podemos dizer que o DevOps), que estava ganhando impulso ativamente junto com a popularidade do Docker.

Embora o Apache Mesos e outras plataformas de orquestração de software existissem antes do Kubernetes dominar, o K8s decolou rapidamente de um pequeno projeto de código aberto do Google para o projeto principal da CNC Native (Cloud Native Computing Foundation) .

Nota perev. : Você sabia que o CNCF apareceu em 2015 por ocasião do lançamento do Kubernetes 1.0? Ao mesmo tempo, o projeto foi transferido pelo Google para uma nova organização independente que se tornou parte da Linux Foundation.


Evento de lançamento do K8s 1.0 patrocinado por, entre outros, Mesosfera, CoreOS, Mirantis, OpenStack, Bitnami

Das notícias sobre o lançamento do Kubernetes 1.0 no ZDNet

Mesmo depois que o Docker lançou a plataforma de orquestração rival, Swarm , incorporada ao Docker e apresentando simplicidade no Docker e foco na configuração padrão de cluster seguro, isso não era mais suficiente para conter o crescente interesse no Kubernetes.

No entanto, muitas partes interessadas fora das comunidades nativas da nuvem em rápido crescimento estavam confusas. Um observador comum não conseguia descobrir o que estava acontecendo: os Kubernetes brigam com o Docker ou com a cooperação deles. Como o Kubernetes era apenas uma plataforma de orquestração, era necessário um ambiente de contêiner executável que iniciasse diretamente contêineres orquestrados no Kubernetes. Desde o início, o Kubernetes usou o mecanismo do Docker e, apesar da tensão competitiva entre o Swarm e o Kubernetes, o Docker ainda era o tempo de execução padrão e era necessário para o cluster Kubernetes funcionar.

Com um pequeno número de tempos de execução de contêiner além do Docker, parecia claro que o tempo de execução do emparelhamento com o Kubernetes exigiria uma interface especialmente escrita - shim - para cada tempo de execução. A falta de uma interface clara para implementar os tempos de execução do contêiner dificultava a adição de suporte para novos tempos de execução no Kubernetes.

Interface de Tempo de Execução do Contêiner (CRI)

Para resolver a crescente complexidade da implementação de tempos de execução no Kubernetes, a comunidade definiu uma função específica da interface que o tempo de execução do contêiner deveria implementar no Kubernetes - nomeando-a Interface de Tempo de Execução do Container (CRI) (que apareceu no Kubernetes 1.5 - tradução aproximada). . Esse evento não apenas ajudou o problema do crescente número de fragmentos da base de código Kubernetes que afetava o uso de tempos de execução do contêiner, mas também ajudou a entender quais funções deveriam ser suportadas por tempos de execução em potencial, se eles quisessem cumprir o CRI.

Como você pode imaginar, o CRI espera coisas muito simples do tempo de execução. Esse ambiente deve poder iniciar e parar pods, manipular todas as operações com contêineres no contexto de pods (iniciar, parar, pausar, eliminar, excluir) e também oferecer suporte ao gerenciamento de imagens de contêineres usando o registro. Também existem funções auxiliares para coletar logs, métricas etc.

Quando novos recursos aparecem no Kubernetes, se eles dependem da camada do tempo de execução do contêiner, essas alterações são feitas na API CRI com versão. Por sua vez, isso cria uma nova dependência funcional do Kubernetes e requer o lançamento de versões mais recentes dos tempos de execução que suportam novos recursos (um exemplo recente são os espaços de nome de usuário).

Cenário atual do CRI

A partir de 2018, existem várias opções para uso como tempos de execução de contêineres no Kubernetes. Conforme mostrado na ilustração abaixo, uma das opções reais ainda é o Docker, com seu dockershim que implementa a API do CRI. De fato, na maioria das instalações do Kubernetes atualmente, é ele, Docker, quem permanece o tempo de execução padrão.



Uma das conseqüências interessantes da tensão entre a estratégia de orquestração do Docker com o Swarm e a comunidade Kubernetes foi um projeto conjunto, que tomou a base do tempo de execução do Docker e reuniu um novo projeto de código aberto desenvolvido em conjunto - contemerd . Com o tempo, o containererd foi transferido para o CNCF, a mesma organização que gerencia e é dona do projeto Kubernetes. ( Nota : traduzimos a aparência de container em mais detalhes em um artigo separado .)


A partir do anúncio de containsererd no blog Docker

O Containerd, sendo uma implementação simples, básica e independente da empresa (não opinativa) do tempo de execução para o Docker e o Kubernetes (via CRI), começou a ganhar popularidade como um substituto potencial para o Docker em muitas instalações do Kubernetes. Até o momento, o IBM Cloud e o Google Cloud possuem clusters baseados emerd no modo beta / acesso antecipado. O Microsoft Azure também prometeu mudar para oerderd no futuro, e a Amazon ainda está considerando várias opções de tempos de execução para suas soluções de contêiner (ECS e EKS), enquanto continua usando o Docker.

A Red Hat entrou no espaço de tempo de execução do contêiner criando uma implementação simples de CRI chamada cri-o com base na implementação de referência da OCI, runc . O Docker e oerderd também são baseados em runc, mas os criadores do cri-o afirmam que seus tempos de execução são "apenas o suficiente" para o Kubernetes e não precisam de mais - apenas adicionaram as funções mais necessárias para implementar o Kubernetes CRI sobre o binário básico do runc. ( Observação : escrevemos mais sobre o projeto CRI-O neste artigo e aqui sobre seu desenvolvimento na forma de podman.)

Projetos leves de virtualização: Intel Clear Containers e hyper.sh - apareceram nos bastidores da OpenStack Foundation, contêineres Kata e oferecem sua visão de contêineres virtualizados para isolamento adicional usando uma implementação de CRI chamada frakti . Cri-o e container também funcionam com contêineres Kata, portanto, seu tempo de execução compatível com OCI pode ser selecionado como uma opção conectável.

Prevendo o futuro

Dizer que você sabe que o futuro geralmente não é muito sábio, mas podemos pelo menos corrigir algumas tendências emergentes à medida que o ecossistema de contêineres se move do entusiasmo e do hype para um estágio mais maduro da nossa existência.

Havia temores iniciais de que o ecossistema de contêineres formaria um ambiente fragmentado, cujos diferentes participantes apresentariam idéias diferentes e incompatíveis sobre o que é um contêiner. Graças ao trabalho da OCI e às ações responsáveis ​​dos principais fornecedores e participantes, vimos um ambiente saudável no setor entre as ofertas de software que preferiam a compatibilidade com a OCI.

Mesmo em ambientes mais recentes, onde o padrão de uso do Docker encontrou menos resistência devido às restrições existentes - por exemplo, no HPC - todas as tentativas de criar ambientes de contêineres não baseados no Docker também chamaram a atenção para o OCI. Estão em andamento discussões sobre se a OCI pode ser uma solução viável para as necessidades específicas das comunidades de cientistas e pesquisadores.

Adicionando a isso a padronização dos tempos de execução do contêiner de plug-in no Kubernetes usando o CRI, podemos imaginar um mundo em que desenvolvedores e administradores podem escolher as ferramentas e pilhas de software certas para suas tarefas, aguardando e observando a interoperabilidade em todo o ecossistema do contêiner.

Considere um exemplo específico para entender melhor este mundo:

• Um desenvolvedor com um MacBook usa o Docker para Mac para desenvolver seu aplicativo e até usa o suporte Kubernetes interno (o Docker aqui funciona como tempo de execução CRI) para tentar implantar um novo aplicativo nos pods do K8s.
• O aplicativo passa pelo CI / CD no software do fornecedor, que usa código runc e especial (gravado pelo fornecedor) para empacotar a imagem OCI e carregá-la no registro corporativo de contêineres para teste.
• A instalação local do cluster Kubernetes, trabalhando com o container como um tempo de execução CRI, executa um conjunto de testes para o aplicativo.
• Por alguma razão, essa empresa escolheu os contêineres Kata para determinadas cargas de trabalho na produção; portanto, quando você implanta o aplicativo, ele inicia nos pods com o container configurado para usar os contêineres Kata como tempo de execução em vez de runc.

Todo o cenário descrito funciona maravilhosamente devido à compatibilidade com a especificação OCI para ambientes e imagens de tempo de execução e o fato de o CRI fornecer flexibilidade na escolha do tempo de execução.

Essa possível flexibilidade e escolha tornam o ecossistema de contêineres verdadeiramente notável e também é uma condição muito importante para a maturidade da indústria, que cresce tão rapidamente desde 2014. No limiar de 2019 e nos anos seguintes, vejo um futuro brilhante com inovações e flexibilidade contínuas para quem usa e cria plataformas baseadas em contêineres.

Mais informações sobre esse tópico podem ser encontradas em uma recente conversa de Phil Estes no QCon NY: “ Mergulho profundo nos tempos de execução do CRI: quem está executando meu pod de Kubernetes!? "

PS do tradutor

Leia também em nosso blog:

• " Red Hat substitui o Docker pelo Podman ";
• “A integração do container com o Kubernetes, substituindo o Docker, está pronta para produção ”;
• “ CRI-O - uma alternativa ao Docker para lançamento de contêineres no Kubernetes ”;
• " O que e por que o Docker está fazendo o Moby para se integrar ao Kubernetes?" "
• “ Então, o que é um pod em Kubernetes? "