Questão de Sistemas Operacionais — Geral — FUNDATEC 2025
Sistemas Operacionais›Geral
Código
qa701226
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Cargo
ANC ( )
Uma aplicação ASP.NET Core será entregue em Kubernetes (K8s) da Empresa de Tecnologia e Informações da Previdência (Dataprev). Busca-se imagem final pequena e monitoramento de saúde nativo do cluster. Qual prática é a mais adequada?
APublicações self-contained, que exigem a imagem Software Development Kit (SDK) em produção, pois não executam corretamente em imagens apenas de runtime, mesmo quando incluem o runtime no publish.
BMulti-stage build, que aumenta o tamanho por introduzir camadas residuais do estágio de build.
CO HEALTHCHECK do Docker substitui a livenessProbe/readinessProbe do Kubernetes, tornando desnecessária a configuração de probes no nível do cluster.
DMulti-stage build aliado a livenessProbe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.
EImagens SDK, que são recomendadas em produção por conterem ferramentas de diagnóstico e compilação just-in-time.
Revelar gabarito e comentário▾
GabaritoD — Multi-stage build aliado a livenessProbe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.
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”.
Imagens Docker para ASP.NET Core em Kubernetes: multi-stage build e probes
Gabarito: letra D. A prática mais adequada combina o multi-stage build — que reduz a imagem final ao descartar as camadas do estágio de build — com as probes livenessProbe/readinessProbe do Kubernetes, que expõem a saúde da aplicação ao orquestrador de forma nativa. As demais alternativas invertem conceitos: a imagem SDK não é recomendada em produção, o HEALTHCHECK do Docker não substitui as probes do K8s, e o multi-stage build reduz (não aumenta) o tamanho da imagem.
O multi-stage build é uma técnica do Dockerfile que usa múltiplos estágios FROM. No primeiro estágio, parte-se de uma imagem SDK (com compilador e ferramentas de build) para compilar a aplicação; no estágio final, copia-se apenas o artefato publicado para uma imagem runtime (menor, sem ferramentas de desenvolvimento). O resultado é uma imagem final enxuta, contendo somente o necessário para executar a aplicação. Isso atende diretamente ao requisito do enunciado de "imagem final pequena".
Já o monitoramento de saúde nativo do cluster é feito pelas probes do Kubernetes. A livenessProbe verifica se o container está vivo — se falhar, o kubelet reinicia o container. A readinessProbe verifica se o container está pronto para receber tráfego — se falhar, o pod é removido dos endpoints do Service. Essas probes são configuradas no manifesto do pod e são o mecanismo nativo do K8s para esse fim. O HEALTHCHECK do Docker é uma instrução do Dockerfile que informa ao Docker (e a quem consultar a API) se o container está saudável, mas o Kubernetes não o utiliza para decidir reiniciar ou rotear tráfego — ele ignora o HEALTHCHECK e depende exclusivamente das probes configuradas no manifesto.
A alternativa D une os dois requisitos: multi-stage build (imagem pequena) + probes do K8s (monitoramento nativo). É exatamente o que o enunciado pede.
NÃO CAIA NESSA!
A banca explora a confusão entre o HEALTHCHECK do Docker e as probes do Kubernetes. O candidato que conhece o HEALTHCHECK pode achar que ele é suficiente, mas o K8s não o utiliza — ele só considera as probes definidas no manifesto do pod. Guarde: HEALTHCHECK é do Docker; liveness/readiness são do K8s.
ASP.NET Core em Kubernetes
1Imagem final pequena
Multi-stage build
Estágio 1: SDK (compila)
Estágio 2: runtime (só artefato)
Descarta camadas de build
2Monitoramento nativo do cluster
livenessProbe
Container vivo?
Falhou → reinicia
readinessProbe
Pronto p/ tráfego?
Falhou → remove do Service
3HEALTHCHECK do Docker
Ignorado pelo K8s
Só informa o daemon
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que publicações self-contained exigem a imagem SDK em produção. Isso é falso: publicações self-contained incluem o runtime .NET no próprio artefato publicado, permitindo executar em imagens apenas com o runtime (ou até em imagens base mínimas, como alpine). A imagem SDK é necessária apenas no estágio de build, não em produção. O erro está em afirmar que "não executam corretamente em imagens apenas de runtime" — justamente o contrário: self-contained é a modalidade que dispensa o runtime instalado na imagem.
Alternativa B — ❌ Incorreta
Afirma que o multi-stage build aumenta o tamanho da imagem por introduzir camadas residuais do estágio de build. É o oposto: o multi-stage build reduz o tamanho, pois o estágio final copia apenas os artefatos necessários, descartando as camadas do estágio de build (SDK, compilador, dependências de build). As camadas residuais não são copiadas para a imagem final.
Alternativa C — ❌ Incorreta
Afirma que o HEALTHCHECK do Docker substitui a livenessProbe/readinessProbe do Kubernetes. Isso é falso: o Kubernetes ignora o HEALTHCHECK do Docker. As probes são configuradas no manifesto do pod e são o mecanismo nativo do K8s para monitoramento de saúde. O HEALTHCHECK é uma instrução do Dockerfile que informa ao Docker daemon, mas não é consultado pelo orquestrador.
Alternativa D — ✅ Correta ⟵ GABARITO
Combina corretamente as duas práticas: multi-stage build para reduzir a imagem final (descartando o SDK e ferramentas de build) e livenessProbe/readinessProbe para expor sinais de saúde ao Kubernetes. É a prática mais adequada para os requisitos do enunciado: imagem pequena e monitoramento nativo do cluster.
Alternativa E — ❌ Incorreta
Afirma que imagens SDK são recomendadas em produção por conterem ferramentas de diagnóstico e compilação JIT. Isso é falso: imagens SDK são grandes e desnecessárias em produção. A recomendação é usar imagens runtime (ou self-contained) para reduzir o tamanho e a superfície de ataque. Ferramentas de diagnóstico e compilação JIT pertencem ao ambiente de desenvolvimento/build, não ao de produção.