A partir das informações da situação hipotética precedente, julgue o item a seguir.
O campo selector dentro do grupo spec, no código em apreço, é usado para encontrar os pods que pertencem a esse deployment, com base no rótulo app:nginx.
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”.
Kubernetes: o campo selector do Deployment
Gabarito: ✅ CERTO. O campo selector dentro de spec é exatamente o mecanismo que o Deployment usa para identificar quais Pods ele gerencia, selecionando-os pelo rótulo (label) app: nginx — e é isso que a assertiva afirma. A função do selector é declarada na própria documentação do Kubernetes: ele define o conjunto de Pods que o Deployment controla, casando com os labels definidos no template.
O Kubernetes é um orquestrador de contêineres: ele gerencia o ciclo de vida de aplicações empacotadas em contêineres, distribuindo-as em um cluster de máquinas. Para fazer isso, ele precisa de uma forma de agrupar e identificar os objetos que gerencia — e essa forma são os labels (rótulos) e os selectors (seletores). Um label é um par chave-valor anexado a um objeto, como app: nginx; um selector é uma expressão que filtra objetos por seus labels. Essa separação entre "etiquetar" e "selecionar" é o coração do modelo declarativo do Kubernetes: você não diz ao sistema como criar os Pods, você declara o estado desejado (quantas réplicas, qual imagem, quais labels) e o controlador se encarrega de convergir o estado atual para o desejado.
No manifesto do enunciado, o Deployment declara:
replicas: 2 — o número desejado de Pods;
template.metadata.labels: app: nginx — os labels que os Pods criados a partir desse template receberão;
spec.selector.matchLabels: app: nginx — o selector que identifica quais Pods existentes pertencem a esse Deployment.
O selector é obrigatório e deve casar com os labels do template — se não casar, o Deployment não consegue gerenciar os Pods que ele mesmo cria. Na prática, quando você aplica esse manifesto, o controlador do Deployment (um componente chamado deployment controller) consulta o cluster por Pods que tenham o label app: nginx; se encontrar menos de 2, cria novos; se encontrar mais, remove os excedentes. É assim que ele garante que sempre haja exatamente 2 réplicas rodando.
A pegadinha que a banca poderia explorar — e que não aparece aqui — é confundir o selector com o template. O template define como os Pods serão criados (a "receita"); o selector define quais Pods já existentes o Deployment controla. São funções distintas e complementares. Outra confusão comum é achar que o selector serve para rotear tráfego — isso é função do Service, que também usa selectors, mas para um propósito diferente (expor os Pods para acesso de rede).
No caso concreto, a assertiva diz exatamente o que o selector faz: "encontrar os pods que pertencem a esse deployment, com base no rótulo app: nginx". Isso está perfeitamente correto — é a definição literal da função do campo. Não há nenhum erro de conceito, inversão de papéis ou termo trocado.
Deployment (Kubernetes): Template (Define como criar os Pods (receita), Labels: app: nginx); Selector (spec.selector) (Define quais Pods o Deployment controla, Filtra por labels (matchLabels: app: nginx), Obrigatório casar com o template); Replicas (Estado desejado (2), Controlador converge atual → desejado); Service (não confundir) (Também usa selector, Mas para rotear tráfego, não gerenciar)
Item — ✅ CERTO
A afirmativa descreve com precisão a função do campo selector no manifesto do Deployment: ele é usado para selecionar os Pods que o Deployment gerencia, com base nos labels definidos em matchLabels (app: nginx). Essa é a definição canônica do Kubernetes — o selector é o vínculo entre o Deployment e seus Pods, permitindo que o controlador identifique, monitore e mantenha o número desejado de réplicas. Não há qualquer imprecisão: o selector não serve para outra coisa (como expor serviços ou definir a imagem), e o rótulo citado (app: nginx) é exatamente o que aparece no manifesto, tanto no selector quanto no template. Portanto, a assertiva está correta.
NÃO CAIA NESSA!
Para fixar, lembre-se do par label × selector: o label é a "etiqueta" que você cola no objeto; o selector é o "filtro" que você usa para achar objetos com aquela etiqueta. No Deployment, o selector obrigatoriamente casa com os labels do template — se não casar, o Deployment não funciona. E não confunda com o Service, que também usa selector, mas para rotear tráfego para os Pods, não para gerenciá-los.