Arquitetura do Cluster

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.

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 pod 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 nó, e 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 nó no cluster. Ele garante que os contêineres estejam sendo executados em um Pod.

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 nó 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.

DNS

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 e 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.