Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Arquitetura

Servidores e Agentes

  • Um nó de servidor é definido como um host executando o comando k3s server, com componentes do plano de controle e de armazenamento de dados gerenciados pelo K3s.

  • Um nó de agente é definido como um host executando o comando k3s agent, sem quaisquer componentes de armazenamento de dados ou de plano de controle.

  • Tanto servidores quanto agentes executam o kubelet, o tempo de execução do contêiner e o CNI. Consulte a documentação Opções Avançadas para mais informações sobre como executar servidores sem agentes.

how it works k3s revised

Configuração de servidor único com um banco de dados embutido

O diagrama a seguir mostra um exemplo de um cluster que possui um servidor K3s de nó único com um banco de dados SQLite embutido.

Nesta configuração, cada nó de agente é registrado no mesmo nó de servidor. Um usuário do K3s pode manipular recursos do Kubernetes chamando a API do K3s no nó do servidor.

Arquitetura do K3s com um Servidor Único

K3s de Alta Disponibilidade

Clusters de servidor único podem atender a uma variedade de casos de uso, mas para ambientes onde o tempo de atividade do plano de controle do Kubernetes é crítico, você pode executar o K3s em uma configuração de HA. Um cluster K3s de HA é composto por:

  • Banco de Dados Embutido

  • Banco de Dados Externo

  • Três ou mais nós de servidor que servirão a API do Kubernetes e executarão outros serviços do plano de controle

  • Um armazenamento de dados etcd embutido (em oposição ao armazenamento de dados SQLite embutido usado em configurações de servidor único)

Arquitetura do K3s com Servidores de Alta Disponibilidade

  • Dois ou mais nós de servidor que servirão a API do Kubernetes e executarão outros serviços do plano de controle

  • Um armazenamento de dados externo (como MySQL, PostgreSQL ou etcd)

Arquitetura K3s com Servidores de Alta Disponibilidade e um Banco de Dados Externo

Endereço de Registro Fixo para Nós Agentes

Na configuração de servidor de alta disponibilidade, cada nó também pode se registrar na API do Kubernetes usando um endereço de registro fixo, conforme mostrado no diagrama abaixo.

Após o registro, os nós agentes estabelecem uma conexão diretamente com um dos nós de servidor.

Registro de Agente HA

Como Funciona o Registro do Nó Agente

Os nós agentes são registrados com uma conexão websocket iniciada pelo processo k3s agent, e a conexão é mantida por um balanceador de carga do lado do cliente que opera como parte do processo do agente. Inicialmente, o agente se conecta ao supervisor (e ao kube-apiserver) através do balanceador de carga local na porta 6443. O balanceador de carga mantém uma lista de endpoints disponíveis para conexão. O endpoint padrão (e inicialmente único) é definido a partir do nome do host do endereço --server. Uma vez conectado ao cluster, o agente recupera uma lista de endereços do kube-apiserver a partir da lista de endpoints do serviço Kubernetes no namespace padrão. Esses endpoints são adicionados ao balanceador de carga, que então mantém conexões estáveis com todos os servidores no cluster, fornecendo uma conexão ao kube-apiserver que tolera falhas de servidores individuais.

Os agentes se registrarão no servidor usando o segredo do cluster do nó junto com uma senha gerada aleatoriamente para o nó, armazenada em /etc/rancher/node/password. O servidor armazenará as senhas para nós individuais como segredos do Kubernetes, e quaisquer tentativas subsequentes devem usar a mesma senha. Os segredos de senha do nó são armazenados no namespace kube-system com nomes usando o modelo <host>.node-password.k3s. Isso é feito para proteger a integridade dos IDs dos nós.

Se o diretório /etc/rancher/node de um agente for removido, ou se você desejar reintegrar um nó usando um nome existente, o nó deve ser removido do cluster. Isso limpará tanto a entrada do nó antigo quanto o segredo da senha do nó, permitindo que o nó (re)ingresse no cluster.

Se você reutiliza frequentemente nomes de host, mas não consegue remover os segredos de senha do nó, um ID de nó exclusivo pode ser automaticamente anexado ao nome do host ao iniciar servidores ou agentes K3s usando a flag --with-node-id. Quando ativado, o ID do nó também é armazenado em /etc/rancher/node/.