Um tribunal está padronizando o deploy do serviço api-judicial em Kubernetes. O time de infraestrutura propõe o seguinte manifesto:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-judicial
spec:
replicas: 3
selector:
matchLabels:
app: api-judicial
template:
metadata:
labels:
app: api-judicial
spec:
containers:
- name: api-judicial
image: registro.interno.local/api-judicial:2.0
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
Com base nesse manifesto e em conceitos de Kubernetes (contêineres, pods e orquestração), analise as afirmativas a seguir.
I. O objeto Deployment gerenciará ReplicaSets e pods de modo que, em condições normais, haja até 3 pods prontos (readiness OK) associados ao rótulo app: api-judicial.
II. A readinessProbe evita que o Service associado (caso exista) encaminhe tráfego para pods cujo endpoint /health em 8080 ainda não esteja respondendo adequadamente, mesmo que o contêiner já esteja em execução.
III. Se o time alterar apenas o campo image para uma nova versão e aplicar o manifesto com kubectl apply -f, o Deployment poderá realizar um rolling update, substituindo gradualmente os pods antigos pelos novos, desde que não haja alteração no seletor (selector.matchLabels).
Está correto o que se afirma em:
AI, apenas;
BII, apenas;
CIII, apenas;
DII e III, apenas;
EI, II e III.
Revelar gabarito e comentário▾
GabaritoE — I, II e III.
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: Deployment, ReplicaSet e Readiness Probe
Gabarito: letra E — as afirmativas I, II e III estão corretas. O Deployment é o objeto que gerencia ReplicaSets e Pods, mantendo o estado desejado de réplicas; a readinessProbe controla o roteamento de tráfego pelo Service, e a alteração apenas da imagem permite rolling update, desde que o seletor não mude. Esses são conceitos fundamentais da orquestração de contêineres no Kubernetes.
O Kubernetes (K8s) é um sistema de orquestração de contêineres que automatiza a implantação, o dimensionamento e a gestão de aplicações. Ele opera com base no conceito de estado desejado: o usuário declara como o sistema deve estar (quantas réplicas, qual imagem, quais portas), e o controlador trabalha continuamente para que o estado real do cluster corresponda a esse desejo. Essa é a essência do modelo declarativo que diferencia o Kubernetes de abordagens imperativas.
O Deployment é o objeto de mais alto nível para gerenciar aplicações stateless. Ele é responsável por criar e gerenciar ReplicaSets, que por sua vez garantem que um número específico de réplicas de Pods esteja sempre em execução. O Pod é a unidade básica de trabalho — um grupo de contêineres que compartilham rede e armazenamento. Quando você define replicas: 3, o Deployment instrui o ReplicaSet a manter exatamente 3 Pods rodando, recriando qualquer um que falhe ou seja destruído.
A readinessProbe (sonda de prontidão) é um mecanismo de verificação de saúde que determina se um Pod está pronto para receber tráfego. Diferente da livenessProbe (que verifica se o contêiner está vivo e deve ser reiniciado), a readinessProbe verifica se a aplicação está funcional e apta a atender requisições. No manifesto, a sonda faz um httpGet no caminho /health na porta 8080, com um atraso inicial de 5 segundos e verificações a cada 10 segundos. Enquanto a sonda não retornar sucesso, o Pod é marcado como "não pronto" e o Service não encaminha tráfego para ele — mesmo que o contêiner esteja em execução.
O rolling update é a estratégia padrão de atualização do Deployment. Quando você altera o campo image (ou outros campos do template do Pod) e aplica o manifesto com kubectl apply -f, o Deployment cria um novo ReplicaSet com a nova configuração e gradualmente escala-o para cima enquanto escala o ReplicaSet antigo para baixo. Isso garante que a aplicação permaneça disponível durante a atualização, sem tempo de inatividade. Uma condição crítica para o rolling update funcionar é que o selector (selector.matchLabels) não seja alterado — o seletor é imutável e define quais Pods o Deployment gerencia. Alterá-lo exigiria recriar o Deployment.
A pegadinha que a banca explora aqui é a confusão entre os diferentes tipos de probes e o papel de cada objeto. Muitos candidatos confundem readinessProbe com livenessProbe, ou não entendem que o Deployment gerencia indiretamente os Pods através do ReplicaSet. Além disso, a condição de imutabilidade do selector é um detalhe sutil que costuma passar despercebido. Guarde essas distinções: elas são exatamente o que separa as alternativas corretas das incorretas.
Deployment (Kubernetes)
1Gerencia
ReplicaSet
Mantém nº exato de Pods
Recria Pods com falha
Pods
Unidade básica de trabalho
Compartilham rede e armazenamento
2Modelo declarativo
Estado desejado
Controlador busca convergência
3Rolling update
Altera imagem
Novo ReplicaSet
Transição gradual
Selector imutável
4Probes
Readiness (prontidão)
Libera tráfego do Service
Bloqueia Pod não pronto
Liveness (vida)
Reinicia contêiner com falha
LEVEL · soulevel.com.br
Item I — ✅ Correto
O Deployment gerencia ReplicaSets, que por sua vez gerenciam os Pods. Com replicas: 3, o ReplicaSet garante que haja exatamente 3 Pods em execução, não "até 3". A afirmativa diz "até 3 pods prontos (readiness OK)", o que é uma forma de expressar que o ReplicaSet mantém o número desejado de réplicas prontas. Em condições normais, com a readinessProbe respondendo OK, haverá 3 Pods prontos associados ao rótulo app: api-judicial. O termo "até" pode ser interpretado como o teto máximo, mas o ReplicaSet busca manter exatamente o número desejado — se um Pod falhar, ele é recriado. A afirmativa está correta porque descreve o comportamento esperado do Deployment em condições normais.
Item II — ✅ Correto
A readinessProbe tem exatamente essa função: evitar que o Service encaminhe tráfego para Pods que não estão prontos. Quando a sonda HTTP GET em /health na porta 8080 não retorna sucesso, o Pod é removido dos endpoints do Service. Isso é independente do estado do contêiner — o contêiner pode estar em execução, mas a aplicação ainda não está pronta para receber requisições (por exemplo, durante a inicialização ou carregamento de dados). A afirmativa descreve precisamente o papel da readinessProbe.
Item III — ✅ Correto
Alterar apenas o campo image e aplicar com kubectl apply -f dispara um rolling update. O Deployment detecta a mudança no template do Pod, cria um novo ReplicaSet e faz a transição gradual. A condição "desde que não haja alteração no seletor" é correta e crucial: o selector.matchLabels é imutável em um Deployment existente. Alterá-lo invalidaria o manifesto e exigiria a recriação do objeto. A afirmativa está tecnicamente precisa.
Conclusão: os itens I, II e III estão corretos, portanto a alternativa correta é a letra E.