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.
- A)O comando kubectl apply é usado iniciar uma única instância do pod. Exemplo: kubectl apply -f pod.yaml
Errada: kubectl apply aplica o manifesto e cria ou atualiza o Pod, mas não é um comando para "iniciar uma única instância" nesse sentido simplificado.
- B)O comando kubectl get é usado para listar os pods. Exemplo: kubectl get pods --all-namespaces.
Certa: kubectl get pods, inclusive com --all-namespaces, é um comando padrão para listar Pods.
- C)O kubernetes agendará esse pod para ser executado em um nó saudável do cluster, onde o daemon kubelet o monitorará.
Certa: o Kubernetes agenda o Pod em um nó saudável e o kubelet do nó acompanha sua execução.
- D)Os 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.
Certa: o manifesto do Pod tem metadata e spec, e dentro da spec você descreve os containers e demais detalhes de execução.
- E)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.
Errada: requests e limits são definidos por container, e no caso de múltiplos containers não se usa o maior valor como regra do Pod inteiro.
Gabarito: E
Em Kubernetes, o manifesto do Pod é basicamente a receita do que vai rodar: metadados dizem quem é o objeto, e spec diz como ele deve ser executado. Dentro de spec, você descreve os containers, imagens, portas, variáveis, volumes e outras configurações. É por isso que a letra D está alinhada com a estrutura clássica de um manifesto de Pod. Sobre execução, o kubectl apply -f arquivo.yaml serve para criar ou atualizar o recurso descrito no manifesto, não para ficar preso à ideia de "iniciar uma única instância" como se fosse um comando de execução direta. Quem cria o Pod é o controlador do Kubernetes, que agenda o objeto em um nó disponível do cluster. Depois disso, o kubelet no nó acompanha o estado do Pod e tenta mantê-lo conforme o desejado. Isso explica a letra C. A parte que derruba a questão está nos recursos. Em Kubernetes, requests e limits são definidos por container, não por Pod como um bloco único. Se o Pod tiver vários containers, cada um pode ter seus próprios valores de CPU e memória, e o consumo total do Pod será a soma dos containers, não o maior valor entre eles. Então a ideia da letra E mistura conceitos e fica incorreta. Resumindo a lógica da prova: manifestos descrevem a configuração, o scheduler escolhe o nó, o kubelet cuida da execução local, e recursos são pensados no nível do container. Em documentação oficial do Kubernetes, a seção de resources é parte da especificação do container, o que confirma o ponto central cobrado pela banca.