Kubernetes 1.24 remove dockershim e encerra dependência histórica

O Kubernetes 1.24, chamado Stargazer, chegou com uma mudança aguardada desde a descontinuação anunciada na versão 1.20: o dockershim foi removido do kubelet. A partir desta release, clusters precisam usar runtimes suportados pela Container Runtime Interface, como containerd ou CRI-O, ou recorrer ao cri-dockerd quando ainda dependerem do Docker Engine como runtime.¹

Para quem acompanha Kubernetes de perto, a remoção não é surpresa. Para ambientes que cresceram organicamente, porém, ela pode revelar dependências esquecidas. Muitos times dizem "usamos Docker" quando na prática usam imagens no formato OCI, comandos de build, sockets locais, agentes de segurança e scripts que presumem a presença do daemon Docker no nó.

A mudança não impede que imagens construídas com Docker continuem rodando. O que sai do caminho é a camada de compatibilidade que deixava o kubelet conversar com o Docker Engine como se fosse runtime nativo de Kubernetes.

O runtime vira decisão explícita

Kubernetes padronizou a integração de runtime por meio da CRI para reduzir acoplamento e permitir alternativas. containerd e CRI-O falam essa linguagem diretamente. O dockershim existia para manter compatibilidade com a popularidade inicial do Docker, mas carregava complexidade dentro do projeto principal.

Remover esse componente simplifica a manutenção do Kubernetes e deixa a fronteira mais limpa: o orquestrador define comportamento de pods; o runtime executa containers; ferramentas de build e developer experience ficam em outra camada. Essa separação é saudável, mas exige maturidade operacional.

Administradores devem validar AMIs, imagens de nó, distribuições gerenciadas, plugins CNI, agentes de log, drivers de storage, scanners, DaemonSets e scripts que acessam /var/run/docker.sock. O risco não está no manifesto do Deployment, mas nas ferramentas ao redor dele. Um cluster pode iniciar bem e ainda quebrar observabilidade, segurança ou manutenção por causa de dependências no daemon Docker.

Migração precisa olhar para além do kubelet

A recomendação prática é testar o upgrade em um grupo de nós com o runtime alvo e observar comportamento de ponta a ponta. Builds de imagem podem continuar no pipeline com Docker, BuildKit, Kaniko, Buildah ou outras ferramentas. O ponto é não confundir ferramenta de criação de imagem com runtime do nó.

Também há implicações para troubleshooting. Equipes acostumadas a docker ps em nós precisarão usar crictl, ferramentas do runtime escolhido ou interfaces da própria plataforma. Runbooks, treinamento de plantão e automações de suporte devem ser atualizados antes da janela de migração.

Kubernetes 1.24 traz outras mudanças relevantes, incluindo novas APIs beta desabilitadas por padrão, assinatura de artefatos com cosign e suporte beta a OpenAPI v3. Mesmo assim, o dockershim concentra atenção porque toca hábitos antigos de operação.

O valor da remoção está em alinhar Kubernetes com sua arquitetura atual. O ecossistema de containers não depende mais de uma única ferramenta para existir. Para empresas, a versão 1.24 funciona como ponto de cobrança: se o cluster ainda assume Docker Engine no nó, é hora de tornar essa dependência visível, justificá-la ou removê-la com planejamento.