A área de tecnologia da informação e comunicação (TIC)do Banco Central do Brasil (BCB) necessita disponibilizar determinado aplicativo para transações digitais que o BCB vem desenvolvendo, utilizando contêineres no Kubernetes junto ao seu provedor de nuvem. Existe o requisito de que essa aplicação seja gerida no modo serverless.
Tendo como referência a situação hipotética apresentada, julgue o próximo item, relativo a microsserviços e serverless.
No caso hipotético em tela, a área de TIC deve dimensionar a quantidade de pods de acordo com a demanda esperada,uma vez que os pods nesse modo são o ponto focal para avaliação de performance. Isso se deve ao fato de que, ao se utilizar o Kubernetes no modo serverless, cada pod gerencia os kubelets e os contêineres que estiverem contidos nos nós do cluster.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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, kubelets e o modo serverless
Gabarito: letra E (ERRADO). A afirmação está incorreta porque, no Kubernetes, o kubelet é um agente que roda em cada nó (worker node) do cluster, e não é "gerenciado" por um pod — na verdade, o kubelet é o componente responsável por gerenciar os pods e seus contêineres naquele nó. Além disso, a premissa de que "os pods são o ponto focal para avaliação de performance" e que se deve "dimensionar a quantidade de pods de acordo com a demanda esperada" contradiz o princípio fundamental do modo serverless, que é justamente o escalonamento automático baseado na demanda real, sem necessidade de dimensionamento manual prévio.
O enunciado mistura conceitos de arquitetura Kubernetes com a promessa do modelo serverless, criando uma armadilha clássica. Vamos desmontar cada parte para entender por que a assertiva é falsa.
Primeiro, é essencial entender a arquitetura do Kubernetes. O cluster é dividido em dois planos: o plano de controle (control plane) e o plano de dados (data plane). O plano de controle é responsável pela orquestração global — inclui o API server, o scheduler, o controller manager e o etcd. O plano de dados é onde os contêineres realmente rodam, nos nós de trabalho (worker nodes).
Em cada nó de trabalho, roda um componente chamado kubelet. O kubelet é o "agente" do nó: ele se comunica com o API server do plano de controle e é o responsável por gerenciar os pods e seus contêineres naquele nó específico. Ou seja, a relação é exatamente o oposto do que a assertiva afirma: o kubelet gerencia os pods, e não o contrário. Um pod é a menor unidade de computação no Kubernetes — um agrupamento lógico de um ou mais contêineres que compartilham o mesmo namespace de rede e armazenamento. O pod é agendado (scheduled) pelo scheduler para rodar em um nó, e é o kubelet desse nó que garante que os contêineres do pod estejam rodando e saudáveis.
Agora, o segundo erro conceitual: a afirmação de que "os pods nesse modo são o ponto focal para avaliação de performance" e que se deve "dimensionar a quantidade de pods de acordo com a demanda esperada". Isso descreve um modelo de dimensionamento manual ou, no máximo, um modelo de escalonamento preditivo (baseado em previsão de demanda). No entanto, o requisito do enunciado é que a aplicação seja gerida no modo serverless.
O que é o modo serverless? Em computação em nuvem, serverless (ou "computação sem servidor") é um modelo de execução em que o provedor de nuvem gerencia dinamicamente a alocação de recursos de máquina. O desenvolvedor não se preocupa com a infraestrutura subjacente — ele escreve o código (funções) e o provedor se encarrega de executá-lo, escalar automaticamente e cobrar apenas pelo tempo de execução. No contexto de Kubernetes, existem plataformas como o Knative ou o OpenShift Serverless que implementam esse modelo. A ideia central é o auto-scaling: o número de pods (ou réplicas) é ajustado automaticamente com base na demanda real (por exemplo, número de requisições por segundo, uso de CPU, etc.), podendo até escalar para zero quando não há tráfego.
Portanto, a premissa de "dimensionar a quantidade de pods de acordo com a demanda esperada" é exatamente o oposto do que o serverless propõe. No serverless, o dimensionamento é automático e reativo, não manual e preditivo. O desenvolvedor define políticas de escalonamento (como o HPA — Horizontal Pod Autoscaler), e o Kubernetes ajusta o número de pods dinamicamente.
A banca explora a confusão entre dois modelos: o modelo tradicional de Kubernetes, onde o administrador precisa dimensionar o número de réplicas (manualmente ou com base em previsões), e o modelo serverless, onde o escalonamento é automático. A assertiva mistura os dois, criando uma afirmação tecnicamente incorreta.
Para fixar, veja a comparação:
Característica
Kubernetes Tradicional
Kubernetes Serverless (ex.: Knative)
Dimensionamento
Manual ou baseado em previsão
Automático, baseado em demanda real
Escala para zero
Não (mínimo de 1 réplica)
Sim, quando não há tráfego
Foco do desenvolvedor
Gerenciar pods, serviços, deployments
Escrever funções/containers, sem se preocupar com infra
Quem gerencia os pods
O kubelet em cada nó
O kubelet em cada nó (mas o escalonamento é automático)
A pegadinha está em inverter a relação entre kubelet e pod, e em atribuir ao serverless uma característica que é do modelo tradicional. O candidato que conhece a arquitetura básica do Kubernetes e o conceito de serverless identifica o erro imediatamente.
Kubernetes serverless: Escalonamento (Manual/preditivo (demanda esperada), Automático (demanda real), Escala para zero); Kubelet (Agente em cada nó, Gerencia pods e contêineres); Pod (Menor unidade computacional, Não gerencia kubelet)
Item — ❌ ERRADO
A assertiva está errada por dois motivos principais:
Relação kubelet-pod invertida: A assertiva afirma que "cada pod gerencia os kubelets e os contêineres que estiverem contidos nos nós do cluster". Isso é falso. O kubelet é um agente que roda em cada nó e é ele quem gerencia os pods e seus contêineres naquele nó. O pod não gerencia o kubelet; o kubelet gerencia o pod. O kubelet é o componente que garante que os contêineres do pod estejam rodando e saudáveis, reportando o status ao plano de controle.
Premissa de dimensionamento manual no serverless: A assertiva afirma que "a área de TIC deve dimensionar a quantidade de pods de acordo com a demanda esperada". No modo serverless, o dimensionamento é automático e baseado na demanda real, não na demanda esperada. O provedor de nuvem (ou a plataforma serverless sobre Kubernetes) escala os pods dinamicamente, podendo até reduzir a zero quando não há tráfego. O desenvolvedor não precisa (e não deve) dimensionar manualmente a quantidade de pods; ele define políticas de auto-scaling.
Portanto, a afirmação está incorreta em sua totalidade, pois tanto a relação kubelet-pod quanto a premissa de dimensionamento manual contradizem os conceitos fundamentais do Kubernetes e do modelo serverless.