Em Kubernets, o componente que gerencia os pods que foram criados e que está sem nenhum nó atribuído é o
- A)kube-scheduler.
Certa: o kube-scheduler é quem escolhe o nó para pods ainda sem atribuição.
- B)kube-apiserver.
Errada: o kube-apiserver expõe a API do Kubernetes, mas não faz o agendamento de pods.
- C)etcd.
Errada: o etcd é o banco de dados distribuído do cluster, responsável por armazenar o estado do sistema.
- D)kube-controller-manager.
Errada: o kube-controller-manager executa controladores para manter o estado desejado, não para escolher nó de pod.
- E)cloud-controller-manager.
Errada: o cloud-controller-manager integra o Kubernetes com recursos do provedor de nuvem, sem atuar no agendamento de pods.
Gabarito: A
No Kubernetes, nem todo pod nasce com um destino certo. Quando um pod é criado e ainda não tem nó atribuído, entra em cena o componente que faz o "casamento" entre a necessidade do pod e os recursos disponíveis no cluster. Esse é o trabalho do scheduler: olhar para CPU, memória, restrições, afinidades e escolher em qual nó o pod vai rodar. Pense nele como o "porteiro inteligente" do cluster. O pod chega sem endereço, e o kube-scheduler decide onde ele vai morar. Sem essa etapa, o pod fica pendurado na fila, esperando alguém dizer onde ele deve ser executado. Por isso, o gabarito é a alternativa A. O kube-scheduler é justamente o componente responsável por selecionar o nó adequado para os pods sem atribuição. Já os outros componentes têm funções diferentes: o kube-apiserver recebe e expõe a API, o etcd guarda o estado do cluster, o kube-controller-manager coordena controladores e o cloud-controller-manager integra serviços do provedor de nuvem. Em provas, a banca costuma cobrar essa divisão de papéis com precisão. Então vale decorar a ideia central: scheduler decide o lugar do pod; controller gerencia estados; apiserver atende requisições; etcd armazena dados.