Contêineres e orquestração são muito utilizados para a implementação de soluções de tecnologia em ambientes de infraestrutura moderna. A respeito de docker e kubernetes, julgue o seguinte item.
No kubernetes, cada contêiner é executado diretamente pelo plano de controle do cluster, que atua como mecanismo de execução de contêineres em substituição ao runtime de contêiner.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Kubernetes: Plano de Controle e Runtime de Contêineres
Gabarito: ERRADO. No Kubernetes, os contêineres não são executados diretamente pelo plano de controle; eles residem e são executados no plano de dados (também chamado de plano de trabalho), por meio de um runtime de contêineres (como containerd, CRI-O ou Docker). O plano de controle é responsável pela orquestração global — agendamento, controle de estado e exposição da API — e não substitui o runtime de contêineres.
Para entender por que a afirmação está incorreta, é preciso compreender a arquitetura fundamental do Kubernetes, que se divide em dois planos distintos: o plano de controle e o plano de dados. O plano de controle é o "cérebro" do cluster: ele toma decisões globais, como agendar novos pods, monitorar o estado desejado e expor a API para interação do usuário. Seus principais componentes são o API server, o etcd (banco de dados distribuído que armazena as configurações do cluster), o controller manager e o scheduler. Nenhum desses componentes executa contêineres de aplicação diretamente.
O plano de dados (ou plano de trabalho) é onde os contêineres realmente rodam. Ele é composto pelos nós de trabalho (worker nodes), e em cada nó existe um componente chamado kubelet, que é o agente responsável por gerenciar a execução dos contêineres naquele nó. O kubelet, por sua vez, se comunica com um runtime de contêineres — como containerd, CRI-O ou Docker — que é o software de baixo nível que efetivamente cria, inicia e para os contêineres, utilizando os recursos do kernel do sistema operacional (namespaces, cgroups, etc.).
A afirmação do enunciado comete um erro conceitual grave ao afirmar que o plano de controle "atua como mecanismo de execução de contêineres em substituição ao runtime de contêiner". Na realidade, o plano de controle orquestra e gerencia os contêineres, mas quem os executa é o runtime de contêineres, sob a supervisão do kubelet no plano de dados. O plano de controle não substitui o runtime; ele depende dele para que os contêineres sejam efetivamente executados.
Para fixar o contraste entre os dois planos, observe a tabela abaixo:
Critério
Plano de Controle
Plano de Dados
Função principal
Orquestração global, agendamento, controle de estado
Execução dos contêineres
Componentes principais
API server, etcd, controller manager, scheduler
Kubelet, runtime de contêineres (containerd, CRI-O, Docker)
Onde atua
Em todos os nós do cluster (geralmente em nós dedicados)
Nos nós de trabalho (worker nodes)
Executa contêineres de aplicação?
Não
Sim
A pegadinha da banca está em inverter os papéis: ela tenta fazer o candidato acreditar que o plano de controle executa contêineres, quando na verdade ele apenas os gerencia. O runtime de contêineres é uma camada essencial que o plano de controle não substitui — ele é a ponte entre o kubelet e o sistema operacional do nó.
NÃO CAIA NESSA!
A banca troca a função do plano de controle pela do runtime de contêineres. O plano de controle orquestra (agenda, monitora, mantém o estado desejado); o runtime executa (cria, inicia, para os contêineres). O kubelet, no plano de dados, é quem faz a ponte entre os dois. Guarde essa divisão: orquestração ≠ execução.
Kubernetes
1Plano de controle
API server
etcd
Controller manager
Scheduler
Não executa contêineres
2Plano de dados
Kubelet
Runtime de contêineres
containerd
CRI-O
Docker
Executa contêineres
LEVEL · soulevel.com.br
Item — ❌ ERRADO
A afirmação está incorreta porque inverte a arquitetura do Kubernetes. O plano de controle não executa contêineres diretamente; ele gerencia o cluster. A execução dos contêineres é feita pelo runtime de contêineres (containerd, CRI-O, Docker), que opera no plano de dados, sob a supervisão do kubelet em cada nó de trabalho. O plano de controle não substitui o runtime — ele depende dele para que os contêineres sejam executados. A função do plano de controle é de orquestração: agendar pods, manter o estado desejado e expor a API, não de executar contêineres.