Questão de Sistemas Operacionais — Geral — VUNESP 2025

Kubernetes: o papel do kube-scheduler

Gabarito: letra A. O kube-scheduler é o componente do plano de controle do Kubernetes responsável por observar os pods recém-criados que ainda não possuem um nó associado e selecionar o nó mais adequado para executá-los, com base em restrições e políticas de agendamento. Essa é a definição canônica do componente, conforme a documentação oficial do Kubernetes.

O Kubernetes é uma plataforma de orquestração de contêineres que gerencia o ciclo de vida de aplicações distribuídas. Para isso, ele é dividido em dois planos: o plano de controle (control plane) e o plano de dados (data plane). O plano de controle é o "cérebro" do cluster, responsável por tomar decisões globais e manter o estado desejado; o plano de dados é onde os contêineres efetivamente rodam. O kube-scheduler faz parte do plano de controle, assim como o kube-apiserver, o etcd e o kube-controller-manager.

A função do scheduler é essencialmente um problema de agendamento (scheduling): ele precisa decidir, para cada pod que ainda não tem um nó, qual nó do cluster é o mais adequado. Esse processo envolve duas etapas principais: a filtragem (filtering), em que são descartados os nós que não atendem aos requisitos do pod (como recursos de CPU/memória, afinidade, taints/tolerations), e a pontuação (scoring), em que os nós restantes são ranqueados por uma série de políticas de prioridade, escolhendo-se o de maior pontuação. O resultado é a associação do pod a um nó, que é registrada no etcd via API.

É importante distinguir o kube-scheduler dos demais componentes do Kubernetes, pois a banca explora exatamente essa confusão. O kubelet é o agente que roda em cada nó e garante que os contêineres do pod estejam rodando; o kube-proxy é o proxy de rede que roda em cada nó e implementa o serviço de rede; o etcd é o key-value store distribuído que armazena todo o estado do cluster; o container runtime (como containerd ou CRI-O) é o software que efetivamente executa os contêineres; e o cloud-controller-manager é o componente que integra o cluster com a API de um provedor de nuvem. Cada um tem um papel distinto, e a questão testa justamente essa diferenciação.

A pegadinha desta questão é que todas as alternativas incorretas descrevem funções de outros componentes do Kubernetes, mas com nomes ou descrições ligeiramente alterados. O candidato que não domina a arquitetura do Kubernetes pode facilmente confundir o scheduler com o kubelet, o kube-proxy, o etcd ou o cloud-controller-manager. A chave é lembrar que o scheduler é o "escalonador" de pods, responsável por decidir ONDE cada pod vai rodar, e não por executar, armazenar, integrar ou fazer proxy de rede.

Guarde essa fronteira: scheduler = decisão de onde rodar; kubelet = execução local; kube-proxy = rede; etcd = armazenamento; cloud-controller-manager = integração com nuvem. É exatamente nessa distinção que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a definição precisa do kube-scheduler. Ele observa os pods recém-criados que ainda não têm um nó associado (campo nodeName vazio) e seleciona um nó para eles executarem. O processo de seleção envolve filtragem e pontuação, como descrito acima. A alternativa espelha exatamente a função do componente, sem qualquer erro conceitual.

Alternativa B — ❌ Incorreta

A alternativa descreve o container runtime (como containerd, CRI-O ou Docker), que é o software responsável por efetivamente executar os contêineres. O kube-scheduler não executa contêineres; ele apenas decide em qual nó eles devem ser executados. A execução em si é feita pelo kubelet em conjunto com o runtime.

Alternativa C — ❌ Incorreta

A alternativa descreve o cloud-controller-manager, que é o componente responsável por integrar o cluster com a API de um provedor de nuvem pública (como AWS, Azure ou GCP), gerenciando recursos como balanceadores de carga e volumes. O kube-scheduler não tem essa função; ele trabalha apenas com a topologia do cluster e os recursos dos nós.

Alternativa D — ❌ Incorreta

A alternativa descreve o etcd, que é o key-value store distribuído e de alta disponibilidade usado pelo Kubernetes para armazenar todo o estado do cluster (configurações, dados de pods, serviços, etc.). O kube-scheduler não armazena dados; ele apenas lê e escreve informações de agendamento via API, mas o armazenamento persistente é responsabilidade do etcd.

Alternativa E — ❌ Incorreta

A alternativa descreve o kube-proxy, que é o proxy de rede que executa em cada nó do cluster, implementando regras de rede e balanceamento de carga para os serviços. O kube-scheduler não é um proxy de rede e não roda em cada nó; ele roda no plano de controle, em um ou mais nós dedicados (ou em alta disponibilidade).

Gabarito: letra A