instruction: Explain Arquitetura do Cluster
output: Arquitetura do Cluster
  Os conceitos arquiteturais por trás do Kubernetes.
  Um cluster Kubernetes consiste em um control plane mais um conjunto de máquinas trabalhadoras, chamadas de nodes,
  que executam aplicações containerizadas. Todo cluster precisa de pelo menos um worker node para executar Pods.
  Os worker nodes hospedam os Pods que são os componentes da carga de trabalho da aplicação.
  O control plane gerencia os worker nodes e os Pods no cluster. Em ambientes de produção,
  o control plane geralmente executa em múltiplos computadores e um cluster
  geralmente executa múltiplos nodes, fornecendo tolerância a falhas e alta disponibilidade.
  Este documento descreve os vários componentes que você precisa ter para um cluster Kubernetes completo e funcional.
  Figura 1. Componentes do cluster Kubernetes.
  Sobre esta arquitetura
  O diagrama na Figura 1 apresenta um exemplo de arquitetura de referência para um cluster Kubernetes.
  A distribuição real dos componentes pode variar com base em configurações e requisitos específicos do cluster.
  No diagrama, cada node executa o componente
  kube-proxy
  . Você precisa de um
  componente de proxy de rede em cada node para garantir que a
  API de Service
  e comportamentos associados
  estejam disponíveis na rede do seu cluster. No entanto, alguns plugins de rede fornecem sua própria
  implementação de proxy de terceiros. Quando você usa esse tipo de plugin de rede,
  o node não precisa executar o
  kube-proxy
  Componentes do control plane
  Os componentes do control plane tomam decisões globais sobre o cluster (por exemplo, agendamento),
  bem como detectam e respondem a eventos do cluster (por exemplo, iniciar um novo
  quando o campo
  replicas
  de um Deployment não está satisfeito).
  Os componentes do control plane podem ser executados em qualquer máquina do cluster. No entanto, para simplicidade, scripts de
  configuração normalmente iniciam todos os componentes do control plane na mesma máquina, e não executam containers de usuário nesta máquina.
  Consulte
  Criando clusters altamente disponíveis com kubeadm
  para um exemplo de configuração do control plane que executa em múltiplas máquinas.
  kube-apiserver
  O servidor da API é um componente da
  camada de gerenciamento
  do Kubernetes que expõe a API do Kubernetes.
  O servidor da API é o
  front end
  para a camada de gerenciamento do Kubernetes.
  A principal implementação de um servidor de API do Kubernetes é o
  kube-apiserver
  O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja,
  ele pode ser escalonado com a criação de mais instâncias.
  Você pode executar várias instâncias do kube-apiserver e distribuir o tráfego
  entre essas instâncias.
  etcd
  Armazenamento do tipo chave-valor consistente e de alta-disponibilidade, usado
  como armazenamento de apoio do Kubernetes para todos os dados do cluster.
  Se o seu cluster Kubernetes usa o etcd como seu armazenamento de apoio,
  certifique-se de ter um plano de
  backup
  para seus dados.
  Você pode encontrar informações detalhadas sobre o etcd na
  documentação
  oficial.
  kube-scheduler
  Componente da camada de gerenciamento que observa os
  Pods
  recém-criados e que ainda não
  foram atribuídos a um
  seleciona um nó para executá-los.
  Os fatores levados em consideração para as decisões de alocação incluem:
  requisitos de recursos individuais e coletivos, restrições de hardware/software/política,
  especificações de afinidade e antiafinidade, localidade de dados, interferência
  entre cargas de trabalho, e prazos.
  kube-controller-manager
  Componente da camada de gerenciamento que executa os processos de
  controlador
  Logicamente, cada
  controlador
  está em um processo separado, mas para reduzir a complexidade, eles todos são
  compilados num único binário e executam em um processo único.
  Existem muitos tipos diferentes de controllers. Alguns exemplos deles são:
  Node controller: Responsável por notar e responder quando nodes ficam indisponíveis.
  Job controller: Observa objetos Job que representam tarefas pontuais, depois cria Pods para executar essas tarefas até a conclusão.
  EndpointSlice controller: Preenche objetos EndpointSlice (para fornecer um link entre Services e Pods).
  ServiceAccount controller: Cria ServiceAccounts padrão para novos namespaces.
  A lista acima não é exaustiva.
  cloud-controller-manager
  Um componente da
  camada de gerenciamento
  do Kubernetes
  que incorpora a lógica de controle específica da nuvem. O gerenciador de controle de nuvem permite que você vincule seu
  cluster
  na API do seu provedor de nuvem, e separar os componentes que interagem com essa plataforma de nuvem a partir de componentes que apenas interagem com seu cluster.
  O cloud-controller-manager executa apenas controllers que são específicos do seu provedor de nuvem.
  Se você está executando o Kubernetes em suas próprias instalações, ou em um ambiente de aprendizado dentro do seu
  próprio PC, o cluster não tem um cloud controller manager.
  Assim como o kube-controller-manager, o cloud-controller-manager combina vários loops de controle logicamente
  independentes em um único binário que você executa como um único processo. Você pode escalar
  horizontalmente (executar mais de uma cópia) para melhorar o desempenho ou para ajudar a tolerar falhas.
  Os seguintes controllers podem ter dependências do provedor de nuvem:
  Node controller: Para verificar o provedor de nuvem para determinar se um node foi
  excluído na nuvem após parar de responder
  Route controller: Para configurar rotas na infraestrutura de nuvem subjacente
  Service controller: Para criar, atualizar e excluir load balancers do provedor de nuvem
  Componentes do node
  Os componentes do node executam em cada node, mantendo pods em execução e fornecendo o ambiente de runtime do Kubernetes.
  kubelet
  Um agente que é executado em cada
  no cluster. Ele garante que os
  contêineres
  estejam sendo executados em um
  O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos
  e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente.
  O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.
  kube-proxy (opcional)
  kube-proxy é um
  proxy
  de rede executado em cada
  no seu
  cluster
  implementando parte do conceito de
  serviço
  do Kubernetes.
  kube-proxy
  mantém regras de rede nos nós. Estas regras de rede permitem a comunicação de rede com seus
  pods
  a partir de sessões de rede dentro ou fora de seu
  cluster
  kube-proxy usa a camada de filtragem de pacotes do sistema operacional se houver uma e estiver disponível. Caso contrário, o kube-proxy encaminha o tráfego ele mesmo.
  Se você usar um
  plugin de rede
  que implementa encaminhamento de pacotes para Services
  por si só, e fornece comportamento equivalente ao kube-proxy, então você não precisa executar
  kube-proxy nos nodes do seu cluster.
  Container runtime
  O agente de execução (
  runtime
  ) de contêiner é o software responsável por executar os contêineres.
  O Kubernetes suporta diversos agentes de execução de contêineres:
  Docker
  containerd
  CRI-O
  , e qualquer implementação do
  Kubernetes CRI (Container Runtime Interface)
  Addons
  Addons usam recursos do Kubernetes (
  DaemonSet
  Deployment
  , etc) para implementar funcionalidades do cluster.
  Como estes estão fornecendo funcionalidades no nível do cluster, recursos com namespace para
  addons pertencem ao namespace
  kube-system
  Addons selecionados são descritos abaixo; para uma lista estendida de addons disponíveis,
  consulte
  Addons
  Embora os outros addons não sejam estritamente necessários, todos os clusters Kubernetes devem ter
  DNS do cluster
  , pois muitos exemplos dependem dele.
  DNS do cluster é um servidor DNS, além do(s) outro(s) servidor(es) DNS em seu ambiente,
  que serve registros DNS para services do Kubernetes.
  Containers iniciados pelo Kubernetes automaticamente incluem este servidor DNS em suas buscas DNS.
  Web UI (Dashboard)
  Dashboard
  é uma UI baseada na web de propósito geral
  para clusters Kubernetes. Ela permite aos usuários gerenciar e solucionar problemas de aplicações
  executando no cluster, bem como o próprio cluster.
  Monitoramento de recursos de container
  Monitoramento de Recursos de Container
  grava métricas genéricas de séries temporais sobre containers em um banco de dados central, e fornece uma UI para navegar nesses dados.
  Logging no nível do cluster
  Um mecanismo de
  logging no nível do cluster
  é responsável
  por salvar logs de containers em um armazenamento central de logs com uma interface de busca/navegação.
  Plugins de rede
  Plugins de rede
  são componentes de software que implementam a especificação da interface de rede de containers (CNI).
  Eles são responsáveis por alocar endereços IP para pods e permitir que eles se comuniquem
  uns com os outros dentro do cluster.
  Variações de arquitetura
  Embora os componentes principais do Kubernetes permaneçam consistentes, a forma como eles são implantados e
  gerenciados pode variar. Entender essas variações é crucial para projetar e manter
  clusters Kubernetes que atendam às necessidades operacionais específicas.
  Opções de implantação do control plane
  Os componentes do control plane podem ser implantados de várias maneiras:
  Implantação tradicional
  Os componentes do control plane executam diretamente em máquinas dedicadas ou VMs, frequentemente gerenciados como serviços systemd.
  Pods estáticos
  Os componentes do control plane são implantados como Pods estáticos, gerenciados pelo kubelet em nodes específicos.
  Esta é uma abordagem comum usada por ferramentas como kubeadm.
  Auto-hospedado
  O control plane executa como Pods dentro do próprio cluster Kubernetes, gerenciado por Deployments
  e StatefulSets ou outras primitivas do Kubernetes.
  Serviços gerenciados do Kubernetes
  Provedores de nuvem frequentemente abstraem o control plane, gerenciando seus componentes como parte de sua oferta de serviço.
  Considerações de posicionamento de carga de trabalho
  O posicionamento de cargas de trabalho, incluindo os componentes do control plane, pode variar com base no tamanho do cluster,
  requisitos de desempenho e políticas operacionais:
  Em clusters menores ou de desenvolvimento, componentes do control plane e cargas de trabalho de usuário podem executar nos mesmos nodes.
  Clusters de produção maiores frequentemente dedicam nodes específicos aos componentes do control plane,
  separando-os das cargas de trabalho de usuário.
  Algumas organizações executam addons críticos ou ferramentas de monitoramento em nodes do control plane.
  Ferramentas de gerenciamento de cluster
  Ferramentas como kubeadm, kops e Kubespray oferecem diferentes abordagens para implantar e gerenciar clusters,
  cada uma com seu próprio método de layout e gerenciamento de componentes.
  A flexibilidade da arquitetura do Kubernetes permite que organizações adaptem seus clusters às necessidades específicas,
  equilibrando fatores como complexidade operacional, desempenho e sobrecarga de gerenciamento.
  Customização e extensibilidade
  A arquitetura do Kubernetes permite customização significativa:
  Schedulers customizados podem ser implantados para trabalhar junto com o scheduler padrão do Kubernetes ou para substituí-lo completamente.
  Servidores de API podem ser estendidos com CustomResourceDefinitions e API Aggregation.
  Provedores de nuvem podem se integrar profundamente com o Kubernetes usando o cloud-controller-manager.
  A flexibilidade da arquitetura do Kubernetes permite que organizações adaptem seus clusters às necessidades específicas,
  equilibrando fatores como complexidade operacional, desempenho e sobrecarga de gerenciamento.
  Próximos passos
  Saiba mais sobre o seguinte:
  Nodes
  sua comunicação
  com o control plane.
  Controllers
  do Kubernetes.
  kube-scheduler
  que é o scheduler padrão para o Kubernetes.
  Documentação
  oficial do Etcd.
  Vários
  container runtimes
  no Kubernetes.
  Integrando com provedores de nuvem usando
  cloud-controller-manager
  Comandos
  kubectl
  Comunicação entre Nó e Control Plane
  Conceitos sobre Cloud Controller Manager
  Controladores
  Comentários
  Esta página foi útil?
  Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em
  Stack Overflow
  Abra um bug no repositório do GitHub se você deseja
  relatar um problema
  sugerir uma melhoria
  Última modificação June 30, 2025 at 11:38 PM PST:
  docs(pt-br): translate cluster architecture page to Portuguese (67263e005d)