Questão de Sistemas Operacionais — Contêineres (Docker, Kubernetes, etc.) — VUNESP 2023
- Código
- vu197370
- Banca
- VUNESP
- Órgão
- TJM SP
- Ano
- 2023
- Cargo
- Ana SJ ( )
- Anamespace.
- Bmetadata.
- Cstatus.
- Ddesired.
- Espec.
GabaritoE — spec.
Gabarito: letra E. No arquivo YAML de um objeto do Kubernetes, o campo spec é o que descreve o estado desejado do objeto — é nele que o usuário declara como o recurso deve ser configurado, e o controlador do cluster trabalha para que o estado real (status) se aproxime do desejado. Essa é a estrutura central do modelo declarativo do Kubernetes, presente na grande maioria dos tipos de objeto.
O Kubernetes adota um modelo declarativo: o usuário define o que quer (estado desejado) e o sistema se encarrega de alcançar e manter esse estado. Essa definição é feita por meio de arquivos YAML que descrevem objetos como Pods, Deployments, Services, entre outros. A estrutura básica de um manifesto Kubernetes é composta por quatro campos principais: apiVersion, kind, metadata e spec. O campo spec é o coração do manifesto, pois contém a especificação do estado desejado — por exemplo, para um Pod, define a imagem do contêiner, as portas, os volumes, as variáveis de ambiente, etc. O status é o campo que reflete o estado atual do objeto, preenchido pelo próprio Kubernetes (pelo controlador), e não pelo usuário. O metadata traz informações de identificação, como nome, namespace e labels. O namespace é um campo dentro de metadata que serve para organizar e isolar recursos dentro do cluster.
A distinção entre spec e status é fundamental para entender o funcionamento do Kubernetes. O spec é a intenção declarada pelo usuário; o status é a realidade observada pelo sistema. O controlador (controller manager) compara os dois e executa ações para convergir o estado atual ao desejado. Por exemplo, se um Deployment define replicas: 3 no spec, e o status mostra apenas 2 réplicas ativas, o controlador cria uma nova réplica para atingir o número desejado. Essa é a essência do loop de reconciliação do Kubernetes.
A pegadinha da questão está em confundir o campo que o usuário edita (spec) com o campo que o sistema preenche (status). O candidato que não domina a estrutura do manifesto pode ser tentado a marcar status (alternativa C), mas o status é apenas uma leitura do estado atual, não a descrição do estado desejado. O campo desired (alternativa D) não existe na estrutura padrão do Kubernetes — é um nome genérico que não corresponde a nenhum campo real do manifesto. Já namespace (alternativa A) e metadata (alternativa B) são campos de identificação e organização, não de especificação do estado desejado.
Guarde a estrutura do manifesto Kubernetes: apiVersion, kind, metadata e spec. O spec é o campo que descreve o estado desejado, e é exatamente isso que a questão cobra.
namespace é um campo dentro de metadata que define o namespace (espaço de nomes) ao qual o objeto pertence. Ele serve para organizar e isolar recursos dentro do cluster, mas não descreve o estado desejado do objeto. É um campo de identificação, não de especificação.
metadata é o campo que contém informações de identificação do objeto, como name, namespace, labels e annotations. Ele identifica o objeto, mas não descreve o estado desejado. A descrição do estado desejado fica no campo spec.
status é o campo que reflete o estado atual do objeto, preenchido pelo próprio Kubernetes (pelo controlador) após a aplicação do manifesto. Ele não é editado pelo usuário e não descreve o estado desejado — pelo contrário, é o resultado da reconciliação entre o spec e a realidade do cluster.
desired não é um campo padrão da estrutura de um manifesto Kubernetes. O nome correto do campo que descreve o estado desejado é spec. A alternativa usa um termo genérico em inglês que pode parecer intuitivo, mas não corresponde à nomenclatura oficial do Kubernetes.
O campo spec é o que descreve o estado desejado do objeto no Kubernetes. Ele é aplicável à grande maioria dos tipos de objeto (Pods, Deployments, Services, etc.) e contém a especificação declarativa do que o usuário deseja que o recurso seja. O controlador do cluster compara o spec com o status e age para convergir o estado atual ao desejado.
Para memorizar a estrutura do manifesto Kubernetes, lembre-se da ordem: apiVersion, kind, metadata, spec. O spec é o que você declara (desejado); o status é o que o sistema reporta (atual). Se a alternativa trouxer status como descrição do estado desejado, é pegadinha clássica — o status é o estado atual, não o desejado.
Gabarito: letra E
Link permanente: /questoes/vu197370