Kubernetes K3s Alta Disponibilidade: Replicação Síncrona e Failover em 2 Nós

Simplificando a Alta Disponibilidade (HA) do K3s: Porquê escolher SafeKit em vez do MetalLB e do Longhorn?

Embora a pilha padrão de código aberto (MetalLB + Longhorn) para K3s seja poderosa para grandes centros de dados, ela introduz uma complexidade excessiva para locais com 2 nós. SafeKit simplifica o ambiente K3s, substituindo ferramentas de rede e armazenamento autónomas por um único motor de alta disponibilidade consolidado.

Por que usar SafeKit para alta disponibilidade (HA) de K3s com 2 nós?

• Verdadeira Alta Disponibilidade de 2 Nós: SafeKit oferece redundância total com apenas 2 nós, eliminando a necessidade de 3 nós para o quórum do etcd.
• Perda de dados zero (RPO = 0): Substitui o armazenamento em bloco de alta sobrecarga por replicação síncrona ao nível de byte para desempenho de SSD local.
• Proteção flexível ao nível de ficheiros: SafeKit executa a replicação baseada no anfitrião ao nível de ficheiros, o que é completamente transparente para a aplicação. Protege não só as bases de dados, mas também todas as pastas e dados associados. Pode replicar as pastas existentes exatamente onde estão instaladas, mesmo no disco do sistema.
• IP Virtual Integrado (VIP): Gerencia nativamente o IP do cluster ao nível do kernel, eliminando a necessidade de configurações separadas do MetalLB.
• Failover e Failback Automáticos: Acionam uma transição imediata para o nó secundário em caso de falha; assim que o nó primário estiver operacional, SafeKit executa a resincronização automática de dados sem intervenção manual.
• Overhead ultrabaixo: SafeKit opera sem o pesado overhead de gestão de pods de armazenamento (CSI/Longhorn) e pods de rede (CNI/MetalLB) exigidos pelas pilhas padrão, libertando RAM e CPU críticas para as suas aplicações.
• Amigável para o técnico de TI generalista: Substitui a complexa infraestrutura YAML para rede e armazenamento por uma interface gráfica web simples e scripts de implementação automatizados, permitindo que se concentre apenas nas suas aplicações.

Alta disponibilidade (HA) sem partilha de recursos para clusters K3s de 2 nós

⚡ Guia rápido de instalação de um cluster Kubernetes HA >

Índice

• Como o software SafeKit implementa de forma simples um cluster de alta disponibilidade Kubernetes K3s?
• Como funciona o cluster mirror SafeKit com Kubernetes K3S?
• Limitações de Alta Disponibilidade SafeKit
• Comparação: SafeKit vs. Stack K3s Padrão (MetalLB & Longhorn)
• Guia em Vídeo: Configuração de um cluster HA mirror SafeKit
• 🔍 Explore SafeKit

Como o software SafeKit implementa de forma simples um cluster de alta disponibilidade Kubernetes K3s?

Como implemento alta disponibilidade para um cluster Kubernetes K3s de 2 nós?

É possível implementar alta disponibilidade (HA) para um cluster Kubernetes K3s de 2 nós utilizando o módulo mirror k3s.safe SafeKit. Esta solução permite implementar um ambiente redundante sem a necessidade de armazenamento NFS externo, uma base de dados de configuração externa dedicada ou conhecimentos especializados Kubernetes.

Por que usar o K3s para computação de ponta e IoT?

O K3s é o motor Kubernetes preferido para IoT e computação de ponta (Edge computing) porque é uma distribuição leve e certificada, concebida para ambientes com recursos limitados. Simplifica a sobrecarga operacional do Kubernetes padrão, mantendo a compatibilidade total.

Quais são as principais características do módulo mirror k3s.safe?

O módulo k3s.safe fornece uma pilha de alta disponibilidade abrangente para o K3s, implementando:

• Nós Ativos Duplos: Executa 2 mestres/agentes K3s ativos em simultâneo para alojar pods.
• Replicação de Base de Dados: Replicação em tempo real da base de dados de configuração MariaDB entre nós.
• Armazenamento Persistente: Replicação de volumes persistentes através de um provisionador dinâmico de cliente NFS integrado (nfs-client).
• Continuidade da Rede: Inclui um endereço IP virtual para acesso contínuo do cliente.
• Recuperação Automatizada: Suporte completo para comutação automática de contingência e retorno à condição normal.

Além do K3s, que aplicações e ambientes SafeKit pode proteger?

SafeKit é uma solução versátil de alta disponibilidade para Windows e Linux que vai muito além cluster mirror K3s. Permite replicação síncrona em tempo real e failover automático para uma vasta gama de cargas de trabalho críticas, incluindo:

• Ambientes Virtuais e Físicos: Máquinas virtuais Hyper-V ou KVM completas.
• Orquestração de contentores: ambientes Docker, Podman.
• Dados e Serviços: Diretórios de ficheiros individuais, serviços e várias bases de dados.
• Infraestrutura em Nuvem: Alta disponibilidade para aplicações em nuvem.

SafeKit também oferece aos clusters farm balanceamento de carga de rede nativo e failover para aplicações sem estado como servidores web.

💡 Explore a lista completa de soluções de alta disponibilidade suportadas aqui.

Como SafeKit consegue a alta disponibilidade do K3s?

Arquitetura e Lógica de Redundância para um Cluster K3s de 2 Nós usando SafeKit

Mecanismo de Failover Automático: Em caso de falha do nó primário, SafeKit migra automaticamente os IPs virtuais e os serviços de armazenamento para o nó secundário, garantindo um serviço ininterrupto para o cluster K3s.

Como funciona o cluster mirror SafeKit com Kubernetes K3S?

Passo 1: Replicação de Ficheiros ao Nível de Byte num cluster mirror

Esta fase ilustra a arquitetura de alta disponibilidade entre o Servidor 1 (PRIM) e o Servidor 2 (SECOND). Ambos os servidores executam os componentes mestre e agente do K3s, conforme definido na tabela de arquitetura.

Atualmente, o IP Virtual (VIP), o armazenamento persistente NFS e MariaDB estão ativos apenas no Servidor 1 (PRIM). Os componentes principais do K3s em ambos os nós sincronizam-se entre si acedendo ao estado do cluster através do IP Virtual e da porta MariaDB. SafeKit implementa a replicação síncrona do MariaDB e dos ficheiros NFS persistentes, garantindo zero perda de dados (RPO = 0) em caso de falha.

Os mestres do K3s distribuem a carga de trabalho por ambos os nós (ou mais) comunicando diretamente com os agentes do K3s. Os clientes externos ligam-se ao
endereço IP virtual do cluster no nó PRIM. Utilizando mecanismos padrão Kubernetes, o mestre do K3s reencaminha o tráfego para pods distribuídos pelos nós. Da mesma forma, os pods acedem aos seus volumes persistentes (PVs) no servidor PRIM através do IP virtual e da porta NFS.

Passo 2: Reposição Automática em Caso de Falha e Continuidade do Serviço

Quando o Servidor 1 (PRIM) falha, o Servidor 2 (SECOND) assume automaticamente as operações do cluster para garantir a continuidade.

SafeKit deteta a falha e migra imediatamente o endereço IP virtual do cluster para o Servidor 2. Em seguida, promove os serviços locais MariaDB e NFS para um estado ativo. Devido à replicação síncrona realizada no Passo 1, todas as bases de dados MariaDB e os ficheiros de Volume Persistente (PV) NFS já estão atualizados no Servidor 2, garantindo a perda zero de dados.

Com o estado do cluster preservado, o K3s Master no Servidor 2 continua a execução. Ele deteta a perda do agente do Servidor 1 e reagenda automaticamente os pods afetados para os agentes K3s ativos restantes. O tempo total de recuperação (RTO) é a soma do intervalo de deteção de falhas (padrão: 30 segundos) e o tempo necessário para que os componentes K3s inicializem no nó secundário.

Enquanto o Servidor 1 estiver offline, os serviços MariaDB e NFS continuam a ser executados no Servidor 2, registando as alterações apenas localmente.

Passo 3: Recuperação de Falhas e Reintegração Automática

A recuperação ocorre quando o Servidor 1 é reiniciado após a resolução do problema inicial. SafeKit resincroniza automaticamente os ficheiros MariaDB e NFS, atualizando apenas os dados modificados no Servidor 2 durante o tempo de inatividade. Este processo de reintegração não é disruptivo ; os componentes mestre e agente do K3s continuam a ser executados no Servidor 2 sem interrupção.

SafeKit otimiza o tempo de recuperação com base na forma como o servidor foi parado:

• Desligamento Limpo: Se SafeKit foi parado intencionalmente no Servidor 1, apenas as zonas específicas modificadas dentro dos ficheiros são resincronizadas usando mapas de bits de rastreamento de modificações. Isto garante uma reintegração ultrarrápida.
• Falha do Sistema (por exemplo, Falha de Energia): Se o Servidor 1 sofreu um encerramento forçado, os mapas de bits de modificação são ignorados por segurança. SafeKit em vez disso, resincroniza todos os ficheiros com um carimbo de data/hora de modificação mais recente do que o último ponto de sincronização estabelecido, garantindo a integridade total dos dados.

Passo 4: Restaurar a Alta Disponibilidade e a Distribuição de Carga

Após a reintegração, o cluster volta ao modo mirror completo, espelhando o estado descrito no Passo 1. O sistema está novamente num estado de alta disponibilidade: os serviços MariaDB e NFS permanecem ativos no Servidor 2, enquanto SafeKit executa a replicação em tempo real de todas as atualizações de ficheiros de volta para o Servidor 1.

O K3s Master e o K3s Agent são reiniciados automaticamente no Servidor 1. O agendador Kubernetes reconhece agora o Servidor 1 como um nó íntegro e pode começar a reagendar os pods para distribuir a carga de trabalho por ambos os servidores.

Se o administrador preferir que os serviços MariaDB e NFS sejam executados no Servidor 1 (restaurando a função PRIM original), uma mudança pode ser acionada manualmente através da consola web num momento conveniente ou automatizada através das definições de configuração.

Como configurar um cluster mirror SafeKit?

A consola web SafeKit oferece uma interface intuitiva para orquestrar a alta disponibilidade das suas aplicações críticas. Em apenas alguns passos, pode configurar um cluster mirror SafeKit para garantir a continuidade do negócio:

• Failover da Aplicação (Separador Macros): Defina os serviços específicos da aplicação a serem reiniciados automaticamente em caso de falha.
• Rede(s) de pulsações: Caminho(s) de comunicação dedicado(s) utilizado(s) pelos nós do cluster para monitorizar continuamente a integridade e a disponibilidade uns dos outros e para sincronizar as decisões de failover.
• Gestão de IP Virtual: Configure o IP Virtual (VIP) para uma reconexão transparente do cliente após uma falha.
• Replicação em Tempo Real: Selecione os diretórios críticos para replicação síncrona ao nível de byte, baseada no anfitrião.
• Verificadores: Monitorize o estado da aplicação e acione a recuperação automática se for detetada uma falha no processo.

O cluster SafeKit inclui um verificador dedicado de “split-brain” para resolver problemas de isolamento de rede sem a necessidade de uma terceira máquina testemunha ou de uma rede adicional de “heartbeat”. Saiba mais sobre “heartbeat”, “failover” e “quorum” num cluster.

Como monitorizar um cluster mirror SafeKit?

A consola de gestão SafeKit oferece uma visão unificada da sua infraestrutura de alta disponibilidade. Permite aos administradores monitorizar o estado operacional do cluster e acompanhar a sincronização de dados em tempo real.

Para um cluster mirror de 2 nós, a consola exibe claramente as funções de cada servidor:

• PRIM (Primário): O nó ativo que executa atualmente a aplicação e gere o IP Virtual. Executa escritas no armazenamento local e replicação em tempo real para o nó secundário.
• SECOND: O nó de reserva recebe atualizações síncronas ao nível de byte. Está pronto para assumir o controlo instantaneamente se o Primário falhar.
• ALONE Estado: Alerta visualmente quando o cluster está a ser executado num único nó (por exemplo, durante a manutenção ou após uma falha), indicando que a redundância foi temporariamente perdida.
• Progresso da Ressincronização: Quando um nó que falhou recupera, o seu estado fica laranja durante a reintegração de dados em segundo plano, garantindo que não haja tempo de inatividade durante a fase de “regresso ao normal”.

Além de simples ícones de estado, a interface oferece orquestração de failover com um clique, permitindo reatribuir manualmente a função primária para manutenção planeada, garantindo simultaneamente a disponibilidade contínua para a atividade do utilizador.

Limitações de Alta Disponibilidade SafeKit

Comparação: SafeKit vs. Stack K3s Padrão (MetalLB & Longhorn)

Comparação: SafeKit vs. Solução Padrão de Código Aberto (MetalLB + Longhorn)

Em resumo, enquanto uma configuração DIY padrão (MetalLB + Longhorn) oferece modularidade para especialistas Kubernetes, ela cria uma dependência circular onde as ferramentas de armazenamento e rede são vulneráveis às mesmas falhas de nó que foram projetadas para gerir. SafeKit quebra este ciclo ao operar como uma camada de infraestrutura independente; ele fornece uma solução de alta disponibilidade (HA) de 2 nós mais robusta e agnóstica ao hardware, que permanece operacional mesmo que o motor Kubernetes ou o sistema operativo anfitrião congelem. Isto garante recuperação automatizada e integridade dos dados sem a pesada sobrecarga de recursos, o quórum obrigatório de três nós ou a complexidade de configuração exigida pelo armazenamento de blocos distribuído tradicional e pelas sobreposições de rede.

Guia em Vídeo: Configuração de um cluster mirror HA SafeKit

Vídeo SafeKit: Agrupamento a nível de aplicação (8:47)

Embora este vídeo demonstre a alta disponibilidade do SafeKit para Microsoft SQL Server, ele fornece uma excelente visão geral de como a solução protege os ambientes K3s. SafeKit funciona de forma idêntica para qualquer outro banco de dados ou aplicação de missão crítica.

Destaques do Vídeo

1. 🎬 2 nós com SQL Server (0:32)
2. 🎬 Configure o cluster e o módulo mirror.safe (3:58)
3. 🎬 Iniciar e testar a replicação, migração e failover do SQL em caso de falha (4:17)

<br />

🔍 Explore o SafeKit

Encontre informações sobre as funcionalidades, arquiteturas, vídeos, documentação e a versão de teste gratuita do SafeKit.