Pontos Principais
- As opções de Plataforma de Gerenciamento de Containers cresceram ao longo do tempo para incluir outras opções além do popular runtime Docker.
- A Open Container Initiative (OCI) obteve sucesso na padronização dos conceitos de container e imagem de container para garantir a interoperabilidade entre plataformas de gerenciamento de conteinerização.
- O Kubernetes adicionou a Container Runtime Interface (CRI) para permitir que os containers possam ser conectados sob a camada de orquestração do Kubernetes.
- A inovação neste campo permitiu que os containers usem virtualização e outras técnicas de isolamento exclusivas para aumentar a segurança dos containers.
- Entre o OCI e o CRI, interoperabilidade e escolha se tornaram realidade no ecossistema de plataformas de gestão e orquestração de containers.
No mundo Linux, containers já existem há algum tempo, voltando uma década atrás para as ideias iniciais em torno de namespaces separados para sistemas de arquivos e processos. Em algum momento do passado recente, os Containers Linux (LXC) nasceram e se tornaram um caminho comum para os usuários Linux acessarem essa poderosa tecnologia de isolamento escondida dentro do kernel do Linux.
Mesmo com o LXC mascarando parte da complexidade de montar os vários fundamentos tecnológicos do que agora comumente chamamos de "container", os containers eram vistos como feitiçaria e seu uso era restrito apenas para pessoas com vasto conhecimento no assunto, não sendo popular entre as massas.
O Docker mudou tudo isso em 2014 com a chegada de um empacotamento mais amigável do kernel do Linux provida pelo LXC - na verdade, as primeiras versões do Docker usavam o LXC nos bastidores - desta forma os containers se popularizaram, conforme os desenvolvedores foram atraídos pela simplicidade e reutilização de imagens docker e comandos simples de runtime.
É claro que o Docker não estava sozinho em querer obter grande parte do mercado de containers, já que o hype cycle não mostrou sinais de desaceleração depois da explosão inicial de interesse em 2014. Nos últimos anos, apareceram várias ideias alternativas sobre containers da CoreOS (rtk), Intel Clear Containers e hyper.sh (virtualização leve unificada com containers) e pesquisas de computação de alta performance - Singularity e shifter.
A medida que o mercado continuou a crescer e amadurecer, as tentativas de padronização das ideias iniciais do Docker promovidas pela Open Container Initiative (OCI) foram implementadas. Hoje em dia, várias plataformas de containers são compatíveis com o padrão OCI ou estão a caminho disto, provendo as mesmas condições para os fornecedores se diferenciarem em algumas funcionalidades ou características das plataformas.
A popularidade do Kubernetes
O próximo passo da evolução de containers foi trazer a computação distribuída, no estilo microservices, nesse novo mundo de desenvolvimento a implantação iterativo - DevOps, diríamos - que rapidamente cresceu junto com a popularização do Docker.
Enquanto o Apache Mesos e outros softwares de orquestração de containers existiam anteriormente à sua ascensão, o Kubernetes teve um crescimento meteórico como um pequeno projeto emblemático de código aberto do Google na Cloud Native Computing Foundation (CNCF). Mesmo depois do Docker revelar sua plataforma para orquestração de containers, a Swarm, construída dentro do próprio Docker e focada em ser simples e com configuração de clusters seguros, não pareceu o suficiente para conter a maré crescente de interesse no Kubernetes.
Confuso para várias partes interessadas fora da bolha de comunidades cloud-native, não estava claro para observadores casuais se era algo como Kubernetes vs. Docker, ou Kubernetes e Docker. Como o Kubernetes era simplesmente uma plataforma de orquestração, isso solicitava um container runtime para fazer o trabalho de gerir a execução de containers via orquestração do Kubernetes. Desde o princípio, o Kubernetes havia usado o Docker runtime e, mesmo com certa tensão na competição entre Swarm versus Kubernetes, o Docker continuou como runtime padrão para a operação de clusters Kubernetes.
Com uma pequena lista de containers runtime disponíveis além do Docker, ficou clara a necessidade de escrever uma especificação para interface, ou camada, entre o Kubernetes e os containers runtime. Pois, devido a essa falta, tornava-se difícil adicionar mais containers runtime ao Kubernetes.
A Interface de Containers Runtime (Container Runtime Interface - CRI)
Para resolver o desafio crescente de incorporar o runtime escolhido no Kubernetes, a comunidade definiu a interface - especificando funções que o container runtime devia implementar em favor do Kubernetes - chamando-a de Interface de Container Runtime (CRI). Isso corrigiu tanto o problema do Kubernetes possuir no código uma extensa lista de runtimes que em casos de novas versões pedia grandes alterações, como clareou para runtimes potenciais exatamente as funções esperadas que precisariam implementar para serem suportadas pela CRI.
As expectativas da CRI para um runtime são bastante diretas. O runtime deve ser capaz de iniciar/parar pods e manipular todas as operações de container dentro de pods (iniciar, parar, pausar, remover), bem como lidar com a gestão da imagem com um registro de container. Também foram adicionadas funções utilitárias e de ajuda como coleta de logs, coleta de métricas e assim por diante.
A medida que novos recursos entram no Kubernetes, são feitas alterações na API da CRI com versionamento, e novas versões dos containers runtimes que suportam esses recursos devem ser liberadas (namespaces é um exemplo recente) para lidar com essa dependência funcional do Kubernetes.
O panorama atual da CRI
Desde 2018, existem várias opções para containers runtime sob o Kubernetes. Como a imagem abaixo mostra, o Docker ainda é uma opção viável, com o shim implementando a API CRI agora. Na verdade, na maioria dos casos atuais, o Docker ainda é o runtime padrão para instalações do Kubernetes.
Um dos resultados interessantes das tensões em torno da estratégia de orquestração do Docker com a Swarm e a comunidade Kubernetes foi que um projeto conjunto foi formado, quebrando o núcleo do Docker runtime e levando-o como novo projeto de código aberto desenvolvido em conjunto, chamado containerd. O containerd também contribuiu para a CNCF, a mesma fundação que gerencia e possui o projeto Kubernetes.
Com o containerd como núcleo, um runtime puro não opinativo sob o Docker e Kubernetes através da CRI, sua popularidade subiu como um possível substituto para o Docker em muitas instalações do Kubernetes. Atualmente, a IBM Cloud e o Google Cloud oferecem clusters baseados em containerd em um modo de acesso beta/antecipado. O Microsoft Azure também se comprometeu a migrar para o containerd no futuro e a Amazon ainda está revisando as opções de escolha de runtime sob suas ofertas de containers ECS e EKS, continuando com o Docker por enquanto.
A Red Hat também entrou no espaço de container runtime, criando uma implementação pura da CRI chamada cri-o, em torno da implementação de referência da OCI, runc. O Docker e o containerd também são baseados em torno da implementação runc, mas o cri-o afirma que é "mais do que suficiente" um runtime para o Kubernetes e nada mais, adicionando apenas as funções necessárias acima do binário base runc para implementar a Kubernetes CRI.
Os projetos (levíssimos) de virtualização, Intel Clear Containers e hyper.sh, se fundiram sob um projeto da OpenStack Foundation, os Kata containers, e também estão fornecendo seu estilo de container virtualizado para isolamento extra por meio de uma implementação de CRI, frakti. Tanto o cri-o quanto o containerd também estão trabalhando com contêineres Kata para que seu runtime compatível com o padrão OCI possa ser uma opção de runtime conectável também dentro dessas implementações de CRI.
Previsão do futuro
Embora raramente seja sábio afirmar que sabemos o futuro, podemos pelo menos inferir algumas tendências que estão emergindo à medida que o ecossistema de containers está saindo de níveis de excitação e propaganda para uma fase mais madura de sua existência.
Houve preocupações iniciais de que as disputas em todo o ecossistema do container criariam um ambiente dividido no qual várias partes acabariam com ideias diferentes e incompatíveis sobre o que é um container. Graças ao trabalho da OCI e ao comprometimento dos principais fornecedores e participantes, vemos um investimento saudável em todo o setor em ofertas de software priorizando a conformidade com o padrão OCI.
Em espaços mais novos em que o uso padrão do Docker ganhava menos tração devido a restrições exclusivas, por exemplo, HPC, até mesmo em testes de viabilidade não baseadas em Docker como container runtime, estão tomando conhecimento da OCI e seu padrão. Discussões estão em andamento e há esperança de que a OCI contemple necessidades específicas da comunidade científica também.
Adicionando a padronização nos containers runtime conectáveis na Kubernetes por meio do CRI, podemos imaginar um mundo em que os desenvolvedores e operadores possam escolher as ferramentas e stacks que funcionam para eles e experimentem a interoperabilidade em todo o ecossistema de containers.
Para ajudar a ver isso claramente, vamos dar o seguinte exemplo:
- Um desenvolvedor em seu MacBook usa Docker para Mac para desenvolver sua aplicação, e sempre usa o suporte do Kubernetes (usando Docker como CRI runtime) para tentar implantar sua nova aplicação com Kubernetes pods.
- A aplicação vai através do produto de CI/CD de algum fornecedor que usa runc para criar a imagem OCI e publicar no repositório corporativo de imagens para ela ser testada.
- Um cluster Kubernetes local usando containerd como CRI runtime roda o conjunto de testes contra a aplicação.
- Essa empresa em particular escolhe utilizar Kata containers para alguns ambientes de produção, e quando a aplicação é implantada executa os pods com containerd, configurados para usar Kata containers como runtime ao invés do runc.
Todo este cenário exemplificado funciona perfeitamente devido à conformidade com a especificação OCI para runtime e imagens, e porque o CRI permite essa flexibilidade na escolha do runtime.
Essa oportunidade de flexibilidade e escolha no ecossistema de containers é ótima para todos, e é realmente importante para a maturidade da indústria que cresceu quase da noite para o dia desde 2014. O futuro é cheio de inovação e flexibilidade contínuas para aqueles que usam e criam plataformas baseadas em containers à medida que entramos em 2019 e além!
Informações adicionais podem ser encontradas em uma palestra de Phil Estes no QCon em Nova York: "CRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!?"
Sobre o autor
Phil Estes é CTO / renomado engenheiro sobre Container e Estratégias de Arquitetura para Linux na divisão IBM Watson e Cloud Platform. Atualmente contribui no projeto Docker (agora Moby) engine, um projeto containerd da CNCF, e é membro tanto do Technical Oversight Board da Open Container Initiative (OCI) quanto parte do Comitê de Direção Técnica do Moby. Também é membro do programa Docker Captains e tem larga experiência no ecossistema open source e de containers. Palestra mundialmente em conferências da indústria e de desenvolvimento assim como em meetups relacionados a open source, Docker e tecnologias Linux de container. Seu blog contém posts regulares sobre estes tópicos e pode ser encontrado também pelo twitter como @estesp.