ANÚNCIO

~/questoes/devops

Qual componente do Control Plane funciona como banco de dados distribuído do Kubernetes?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Para fixar

O etcd: O Banco de Dados do Kubernetes

Conceito central

O etcd é um banco de dados distribuído que armazena de forma persistente e confiável todo o estado do cluster Kubernetes. Ele funciona como a memória do cluster, guardando informações sobre pods, serviços, configurações e qualquer outro recurso que você criar no Kubernetes.

Por que essa resposta faz sentido

O etcd persiste o estado completo do cluster de forma distribuída e confiável. Diferentemente de outros componentes que tomam decisões ou executam ações, o etcd apenas guarda dados. Sem o etcd, o cluster perderia todas as informações sobre sua configuração quando reiniciasse.

Armadilhas comuns

  • Confundir etcd com API Server: o API Server é a porta de entrada, mas o etcd é o cofre onde os dados realmente ficam guardados.
  • Achar que etcd é apenas um banco de dados normal: ele é distribuído, o que significa que funciona em múltiplas máquinas e mantém consistência entre elas.
  • Pensar que dados em memória temporária são suficientes: o Kubernetes precisa persistir dados para recuperar o estado do cluster após reinicializações ou falhas.

Entenda as alternativas

A

O API Server é o ponto de entrada para comunicação com o cluster, mas não armazena dados em memória temporária. Ele usa o etcd como banco de dados permanente. Dados em memória temporária seriam perdidos quando o componente reiniciasse.

B

O etcd é exatamente isso: um banco de dados distribuído que persiste o estado completo do cluster. Todo pod, serviço, configuração e segredo do Kubernetes é armazenado no etcd de forma durável.

C

O Controller Manager coordena controladores que mantêm o estado desejado do cluster, não cria backups de dados. Sua função é tomar decisões e executar ações, não armazenar informações do cluster.

D

O Scheduler decide em quais nós os pods devem rodar, mas não guarda informações sobre nós disponíveis de forma permanente. Essa informação é armazenada no etcd, que o Scheduler consulta para tomar suas decisões.

Dica prática: Quando você executa `kubectl create`, `kubectl apply` ou qualquer outro comando, o resultado é armazenado no etcd. Por isso, fazer backup do etcd é crítico para recuperação de desastres em produção. Muitos problemas de Kubernetes raros estão relacionados a corrupção ou perda de dados no etcd.

Revise pensando: Se o etcd de um cluster Kubernetes fosse apagado completamente, o que aconteceria com todos os pods e serviços em execução?