O que e um container runtime? O software que roda contineres
Um container runtime e o software que de fato inicia e roda contineres a partir de imagens - a camada abaixo de ferramentas de nivel mais alto como Docker e Kubernetes.
Quando voce roda um continer, algo precisa configurar os namespaces e cgroups, descompactar a imagem e iniciar o processo. Esse algo e o container runtime. Ha dois niveis - runtimes de alto nivel que gerenciam imagens e lifecycle, e runtimes de baixo nivel que fazem o trabalho de nivel de kernel - e conhecer essa divisao esclarece muita confusao.
Runtimes de alto nivel vs de baixo nivel
Um runtime de alto nivel como o containerd ou o CRI-O gerencia imagens, storage e o lifecycle do continer. Ele entao chama um runtime de baixo nivel como o runc para fazer as syscalls que de fato criam o processo isolado. O Docker usa o containerd por baixo dos panos.
Onde o Docker se encaixa
O Docker nao e, no sentido estrito, o runtime em si - ele e uma plataforma de nivel mais alto que delega ao containerd, que delega ao runc. Essa estratificacao e a razao pela qual o mesmo containerd pode servir tanto ao Docker quanto ao Kubernetes.
O CRI no Kubernetes
O Kubernetes conversa com runtimes atraves do Container Runtime Interface (CRI). E por isso que o Kubernetes largou seu shim embutido do Docker - ele fala CRI diretamente com o containerd ou o CRI-O, sem Docker necessario no node.
Runtimes alternativos
- runc - o runtime de baixo nivel padrao OCI.
- gVisor e Kata - isolamento mais forte via um sandbox ou microVM.
- CRI-O - um runtime CRI leve construido para o Kubernetes.
Runtimes e CI
Runners de CI usam um container runtime para executar jobs e construir imagens. Voce raramente interage com ele diretamente, mas ele e o motor que faz o trabalho - e um runner bem gerenciado o mantem saudavel para que os jobs iniciem de forma confiavel.
Principais conclusões
- Um container runtime inicia e roda contineres a partir de imagens.
- Runtimes de alto nivel (containerd, CRI-O) chamam os de baixo nivel (runc) para o trabalho de kernel.
- O Kubernetes conversa com runtimes via o CRI - nenhum Docker necessario no node.