Pular para o conteúdo principal

Questão de Sistemas Operacionais — Clusters — FGV 2023

Sistemas OperacionaisClusters
Código
fg069596
Banca
FGV
Órgão
SEFAZ-MG
Ano
2023
Nível
Superior
Cargo
Auditor Fiscal da Receita Estadual - Tecnologia da Informação (Tarde)
O código a seguir corresponde a um exemplo básico do manifesto de um pod.

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx:1.14.2
name: nginx
resources:
requests:
cpu: "500m"
memory: "128Mi"
ports:
- containerPort: 80
name: http
protocol: TCP


Em relação aos manifestos, pods e sua execução, assinale a afirmativa incorreta.
  1. AO comando kubectl apply é usado iniciar uma única instância do pod. Exemplo: kubectl apply -f pod.yaml
  2. BO comando kubectl get é usado para listar os pods. Exemplo: kubectl get pods --all-namespaces.
  3. CO kubernetes agendará esse pod para ser executado em um nó saudável do cluster, onde o daemon kubelet o monitorará.
  4. DOs manifestos dos pods incluem uma seção de metadados para descrever o pod e seus labels. Também inclui uma seção de especificações para descrever diferentes informações, como por exemplo uma lista de contêineres que serão executados no pod.
  5. EOs recursos são solicitados por pod, não por contêiner. No caso de dois ou mais contêineres, os recursos definidos no manifesto, que serão compartilhados pelo pod, será definido pelos maiores valores de CPU e memória.
Revelar gabarito e comentário

GabaritoE — Os recursos são solicitados por pod, não por contêiner. No caso de dois ou mais contêineres, os recursos definidos no manifesto, que serão compartilhados pelo pod, será definido pelos maiores valores de CPU e memória.

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 - Pods e Manifestos

Gabarito: letra E (incorreta). A afirmativa E está errada porque, no Kubernetes, os recursos (requests e limits) são especificados por contêiner dentro do pod, e não por pod. O manifesto de exemplo mostra claramente que resources está dentro da seção containers, no nível de cada contêiner. As demais alternativas estão corretas conforme a documentação do Kubernetes.

NÃO CAIA NESSA!

A banca inverte a granularidade dos recursos: muitos candidatos confundem e acham que o pod inteiro compartilha uma cota única, mas na verdade cada contêiner tem seus próprios requests/limits. Quando há múltiplos contêineres, cada um especifica os seus, e o scheduler soma os requests para determinar a carga do nó.

Alternativa A — ✅ Correta

O comando kubectl apply -f pod.yaml é usado para criar ou atualizar o pod a partir de um manifesto. É uma forma declarativa de iniciar uma instância.

Alternativa B — ✅ Correta

kubectl get pods lista os pods no namespace atual; com --all-namespaces lista em todos os namespaces.

Alternativa C — ✅ Correta

O Kubernetes (scheduler) agendao pod em um nó saudável, e o kubelet em cada nó monitora e gerencia os pods.

Alternativa D — ✅ Correta

Manifestos de pod possuem seções metadata (nome, labels) e spec (containers, volumes, etc.).

Alternativa E — ❌ Incorreta (gabarito)

A afirmativa diz: "Os recursos são solicitados por pod, não por contêiner. No caso de dois ou mais contêineres, os recursos definidos no manifesto, que serão compartilhados pelo pod, será definido pelos maiores valores de CPU e memória." Isso está errado. Cada contêiner tem seu próprio bloco resources. Ademais, não há compartilhamento dos maiores valores; o que ocorre é que a soma dos requests dos contêineres é considerada para o agendamento.

Gabarito: letra E

Link permanente: /questoes/fg069596