Ontem a comunidade parou diante da notícia de que o Kubernetes não daria mais suporte ao Docker como Container Runtime. Mas afinal, qual o impacto real dessa decisão na sua vida? Como isso influencia seu dia-a-dia?

Para produzir alguma explicação minimamente consistente, precisamos entender quais recursos cada um tem, para depois podemos analisar o que está acontecendo.

Kubernetes

Kubernetes foi pensado como orquestrador de containers altamente extensível. Ao ponto de que o Container Runtime também não é dele. É um contrato, uma interface chamada de CRI (Container Runtime Interface).

Isso quer dizer que Kubernetes não faz build de imagem, não faz execução de container, nada disso. Ele orquestra quem faz. E especificamente no build, sequer isso.

Docker

Já o Docker também foi pensado em ser extensível, mas de alguma forma isso não vingou muito. Dá a impressão de que extensibilidade era algo desejável para eles, mas não tão importante. Há anos a página de plugins para volumes e rede continua com o path legacy_plugins (https://docs.docker.com/engine/extend/legacy_plugins/) na URL, mas em texto algum eles de fato se pronunciam sobre isso.

Mas além disso, docker foi projetado para ser uma solução tudo-em-um (all-in-one). Ou seja, de cabo-a-rabo. Com docker, docker swarm, seus plugins de rede, seus plugins de volume.

O DockerShim

Como Docker não é uma implementação CRI compliant, é necessário criar um adapter para que possa ser usado como runtime de containers no Kubernetes. O DockerShim é esse adapter. Shim vem do inglês calçar, mas no sentido de colocar um calço.

E na real, não é que o Docker será deprecated, é o DockerShim que está entrando em Deprecation. E você pode entender todos os argumentos no Dockershim Deprecation FAQ, lá no blog do Kubernetes.

Aliás, nesse FAQ temos a explicação sobre o containerd continuar funcionando, por exemplo.

ContainerD

A Docker Inc fez um movimento anos atrás que foi a criação do containerd. O containerd nasce da quebra do código do docker referente à execução dos containers. Essa é uma das demonstrações claras de que docker é muito mais que um executor de containers. A Docker Inc resolveu quebrar o produto, e isolar o runtime, que roda junto com o daemon do docker. Em março de 2017 o containerd passa a fazer parte da CNCF no anúncio containerd joins the Cloud Native Computing Foundation que está no blog da Docker Inc.

O que isso quer dizer?

Sendo objetivo: nada muda!

Tendo em comum o OCI (Open Container Initiative), imagens produzidas com Docker continuam sendo compatíveis. Esse é o poder do standard.

Executando clusters pequenos, e poucos projetos, você continua tirando muito proveito do Docker sem o Kubernetes como já fazia. Tendo a oportunidade de migrar para um cluster kubernetes a qualquer momento, exatamente como era feito.

A diferença é que o cluster kubernetes que usava docker, agora usará outro container runtime, containerd ou cri-o ou algum outro. E em nada é diferente pela ótica da aplicação que subimos.

Mas…. se você usava a Docker CLI para listar os containers dos pods, e entender como as coisas estavam funcionando, lamento mas isso não será possível mais. Você terá de usar 100% da cli do Kubernetes para entender como as coisas estão funcionando.

Sobre docker e containerd, olha ele na imagem abaixo!

A thread abaixo ajuda a entender tudo que estou falando, mas as referências acima, para os links do FAQ continuam sendo a melhor fonte. Aqui vemos um pouco de emoção na explicação o que nos dá a oportunidade de entender o que estava acontecendo.

Bom, embora tenha gerado confusão, essa é uma notícia que deu mais alarde do que deveria. Em linhas gerais, se você não é um administrador de cluster on premise, isso sequer diz respeito a você.

Se você é administrador de cluster PaaS, como AKS e concorrentes, talvez seja uma questãozinha. Talvez esse rollout necessite de algum tipo de planejamento, ou até já tenha acontecido.

Agora, se você resolveu subir um cluster na mão, na unha! Meu amigo, eu não gostaria de estar na sua pele!

Nem antes da notícia, muito menos depois.

Especulação

Acredito que alguém deva assumir o DockerShim, possivelmente virar um produto de retrocompatibilidade. Ou ainda a própria docker incorporar ou criar um projeto pra isso. Não sei. Isso tudo é especulativo e depende de diversas variáveis.

UPDATE 10/12/2020

Desenhei um fluxo para você entender do que estamos falando:

Quando eu digo: Durma bem.

Se você é desenvolvedor ou trabalha com devops, mas não administra o cluster, isso sequer é um assunto que deveria tomar 1 minuto do seu tempo.

Se vc administra um cluster PaaS, muito provavelmente você já não usa docker há meses ou anos.

Dependendo da idade/versão dos teus nós

VOCÊ PODE NUNCA TER USADO DOCKER NO KUBERNETES!

Mirantis assumirá o suporte do Kubernetes dockershim

Como eu havia dito no instagram, só quem sai perdendo com a ausência do DockerShim é a Mirantis. Natural que ela se posicionasse a respeito.