Questão de TI - Desenvolvimento de Sistemas — Geral — VUNESP 2026

Liveness probes no Kubernetes

Gabarito: letra C. O arquivo define um Pod com um único container que executa o script touch /tmp/h; sleep 30; rm -f /tmp/h; sleep 600. Nos primeiros 30 segundos, o arquivo /tmp/h existe, então o comando cat /tmp/h da liveness probe retorna sucesso e o container é considerado saudável. A partir do momento em que o arquivo é removido, a probe falha e o kubelet reinicia o container.

A liveness probe é um mecanismo do Kubernetes que verifica se um container está vivo e funcionando. Se a probe falhar, o kubelet mata o container e o reinicia de acordo com a política de reinicialização do Pod. No arquivo, a probe é do tipo exec, ou seja, executa um comando dentro do container e verifica se ele termina com código de saída zero. O comando é cat /tmp/h, que retorna sucesso se o arquivo existir e falha se não existir.

O script do container cria o arquivo /tmp/h, espera 30 segundos, remove o arquivo e depois dorme por 600 segundos. Isso significa que, nos primeiros 30 segundos, o arquivo existe e a probe passa. Após 30 segundos, o arquivo é removido e a probe começa a falhar. Como a probe é executada a cada 5 segundos (periodSeconds: 5), após a remoção do arquivo, a primeira falha ocorre em até 5 segundos, e o container é reiniciado após o número configurado de falhas consecutivas (failureThreshold, que não foi definido, então usa o padrão de 3).

A alternativa C está correta porque afirma que nos primeiros 30 segundos o container é considerado saudável, o que é exatamente o comportamento do script. As demais alternativas contêm erros conceituais sobre a estrutura do Pod, o tipo de probe e o comportamento do container.

Alternativa A — ❌ Incorreta

O Pod possui apenas um container, definido na seção containers. A seção args define os argumentos passados ao comando do container, não containers adicionais. O YAML mostra containers: - name: liveness, indicando um único container.

Alternativa B — ❌ Incorreta

O comando executado na inicialização é /bin/sh -c 'touch /tmp/h; sleep 30; rm -f /tmp/h; sleep 600', não registry.k8s.io/busybox:1.27.2. A imagem registry.k8s.io/busybox:1.27.2 é a imagem do container, não o comando executado. O campo image especifica a imagem, enquanto args define os argumentos do comando.

Alternativa C — ✅ Correta ⟵ GABARITO

O script touch /tmp/h; sleep 30; rm -f /tmp/h; sleep 600 cria o arquivo /tmp/h, espera 30 segundos, remove o arquivo e depois dorme. Durante os primeiros 30 segundos, o arquivo existe, então a liveness probe (cat /tmp/h) retorna sucesso e o container é considerado saudável. Após 30 segundos, o arquivo é removido e a probe falha, levando ao reinício do container.

Alternativa D — ❌ Incorreta

A liveness probe é do tipo exec, não HTTP. O campo exec define um comando a ser executado (cat /tmp/h), enquanto uma probe HTTP usaria httpGet com um caminho e porta. A alternativa confunde os tipos de probe disponíveis no Kubernetes.

Alternativa E — ❌ Incorreta

O container não é interrompido após 5 segundos. O initialDelaySeconds: 5 define o atraso antes da primeira probe ser executada, não o tempo de vida do container. O container continua rodando até que a probe falhe repetidamente (após 30 segundos, quando o arquivo é removido) e o kubelet decida reiniciá-lo.

Gabarito: letra C