Julgue o próximo item, relativos a DevOps e Kubernetes.
O CRI (container runtime interface) é o principal protocolo para a comunicação entre o kubelet e o container runtime.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
CRI (Container Runtime Interface) no Kubernetes
Gabarito: letra C (CERTO). O CRI (Container Runtime Interface) é, de fato, o principal protocolo que padroniza a comunicação entre o kubelet (agente que roda em cada nó) e o container runtime (como containerd, CRI-O ou Docker). Ele define uma interface de programação (API) que permite ao kubelet gerenciar os contêineres de forma padronizada, independentemente do runtime utilizado.
O Kubernetes é um sistema de orquestração de contêineres que automatiza a implantação, o dimensionamento e a gestão de aplicações. Sua arquitetura é dividida em dois planos: o plano de controle (control plane), responsável pela orquestração global, e o plano de dados (data plane), onde os contêineres efetivamente rodam. No plano de dados, cada nó (node) executa o kubelet, um agente que garante que os contêineres estejam saudáveis e no estado desejado.
Antes da criação do CRI, o kubelet se comunicava diretamente com o Docker através de uma interface específica. Isso criava um acoplamento forte entre o Kubernetes e o Docker, dificultando a utilização de outros runtimes. Para resolver esse problema, o Kubernetes introduziu o CRI, uma interface padronizada que abstrai a comunicação entre o kubelet e qualquer container runtime que implemente essa interface. Assim, o kubelet não precisa saber os detalhes internos de cada runtime; ele apenas utiliza a API do CRI para criar, iniciar, parar e remover contêineres.
Na prática, o CRI funciona como um contrato: o kubelet envia requisições (como "criar um pod") através da API do CRI, e o container runtime (que implementa essa API) executa a ação. Isso permite que diferentes runtimes, como containerd, CRI-O e até mesmo o Docker (através do dockershim, que foi removido em versões recentes), sejam utilizados de forma intercambiável. O CRI também define o formato das imagens de contêiner e como elas devem ser puxadas e executadas.
A pegadinha que a banca pode explorar é confundir o CRI com outros componentes do Kubernetes, como o Container Network Interface (CNI), que cuida da rede, ou o Container Storage Interface (CSI), que cuida do armazenamento. O CRI é especificamente a interface de comunicação entre o kubelet e o runtime de contêineres, sendo o principal protocolo para essa finalidade.
Guarde essa distinção: o CRI é a ponte entre o kubelet e o runtime; o CNI é a ponte entre o kubelet e a rede; o CSI é a ponte entre o kubelet e o armazenamento. É exatamente nessa fronteira que as questões sobre Kubernetes costumam se dividir.
Interfaces do Kubernetes
1CRI (Container Runtime Interface)
Ponte kubelet ↔ container runtime
containerd, CRI-O, Docker (dockershim)
2CNI (Container Network Interface)
Ponte kubelet ↔ rede
3CSI (Container Storage Interface)
Ponte kubelet ↔ armazenamento
LEVEL · soulevel.com.br
Alternativa C — ✅ CERTO ⟵ GABARITO
A afirmação está correta. O CRI (Container Runtime Interface) é o principal protocolo para a comunicação entre o kubelet e o container runtime. Ele foi introduzido no Kubernetes para padronizar essa comunicação, permitindo que diferentes runtimes (containerd, CRI-O, etc.) sejam utilizados de forma intercambiável. O kubelet usa a API do CRI para gerenciar os contêineres, garantindo que eles estejam no estado desejado.
PEGA ESSA DICA!
Para fixar, lembre-se da tríade de interfaces do Kubernetes: CRI (runtime), CNI (rede) e CSI (armazenamento). Quando a questão falar em comunicação entre kubelet e runtime, a resposta é CRI. Quando falar em rede, é CNI. Quando falar em volumes, é CSI.