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

Simplificando o K3s HA: Por que 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 data centers, ela introduz uma complexidade excessiva para sites locais de 2 nós. SafeKit simplifica o ambiente K3s, substituindo ferramentas de rede e armazenamento autônomas por um único mecanismo de HA consolidado.

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

• Alta disponibilidade real de 2 nós: SafeKit oferece redundância total com apenas 2 nós, eliminando o requisito de 3 nós para o quórum etcd.
• Perda de dados zero (RPO = 0): substitui o armazenamento em bloco de alta sobrecarga por replicação síncrona em nível de byte para desempenho de SSD local.
• Proteção flexível em nível de arquivo: SafeKit executa a replicação baseada em host no nível do arquivo, o que é completamente transparente para o aplicativo. Ele protege não apenas bancos de dados, mas todas as pastas e dados associados. Você pode replicar pastas existentes exatamente onde elas estão instaladas, mesmo no disco do sistema.
• IP Virtual Integrado (VIP): Gerencia nativamente o IP do cluster no nível do kernel, eliminando a necessidade de configurações separadas do MetalLB.
• Failover e Failback Automáticos: Dispara uma transição imediata para o nó secundário em caso de falha; assim que o nó primário estiver íntegro, SafeKit executa a resincronização automática de dados sem intervenção manual.
• Sobrecarga ultrabaixa: SafeKit opera sem a pesada sobrecarga de gerenciamento de pods de armazenamento (CSI/Longhorn) e pods de rede (CNI/MetalLB) exigida pelas pilhas padrão, liberando RAM e CPU essenciais para seus aplicativos.
• Amigável para o generalista de TI: substitui a complexa infraestrutura YAML para rede e armazenamento por uma interface gráfica da web simples e scripts de implantação automatizados, deixando você se concentrar apenas em seus aplicativos.

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

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

Índice

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

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

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

Você pode implementar alta disponibilidade (HA) para um cluster Kubernetes K3s de 2 nós usando o módulo mirror k3s.safe SafeKit. Essa solução permite implantar um ambiente redundante sem a necessidade de armazenamento NFS externo, um banco de dados de configuração externo dedicado ou conhecimento especializado Kubernetes.

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

O K3s é o motor Kubernetes preferido para IoT e computação de borda porque é uma distribuição leve e certificada, projetada para ambientes com recursos limitados. Ele simplifica a sobrecarga operacional do Kubernetes padrão, mantendo total compatibilidade.

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

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

• Nós Ativos Duplos: Executa 2 mestres/agentes K3s ativos simultaneamente para hospedar pods.
• Replicação de banco de dados: Replicação em tempo real do banco de dados de configuração MariaDB entre os nós.
• Armazenamento persistente: replicação de volumes persistentes por meio 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 failover e failback automáticos.

Além do K3s, quais 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. Ele permite replicação síncrona em tempo real e failover automático para uma ampla gama de cargas de trabalho críticas, incluindo:

• Ambientes virtuais e físicos: máquinas virtuais Hyper-V ou KVM completas.
• Orquestração de Contêineres: Ambientes Docker e Podman.
• Dados e Serviços: Diretórios de arquivos individuais, serviços e vários bancos 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 compatíveis aqui.

Como SafeKit garante 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: No caso de uma falha no nó primário, SafeKit migra automaticamente os IPs virtuais e os serviços de armazenamento para o nó secundário, garantindo o serviço ininterrupto para o cluster K3s.

Como o cluster mirror SafeKit funciona com Kubernetes K3S?

Passo 1: Replicação de arquivos em nível de byte em um cluster mirror

Esta etapa 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 entre si acessando o estado do cluster por meio do IP Virtual e da porta MariaDB. SafeKit implementa a replicação síncrona do MariaDB e dos arquivos NFS persistentes, garantindo zero perda de dados (RPO = 0) em caso de falha.

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

Passo 2: Failover automático 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 detecta a falha e migra imediatamente o endereço IP virtual do cluster para o Servidor 2. Em seguida, ele promove os serviços locais MariaDB e do NFS para um estado ativo. Devido à replicação síncrona realizada na Etapa 1, todos os bancos de dados MariaDB e os arquivos de Volume Persistente (PV) do 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 detecta a perda do agente do Servidor 1 e reagenda automaticamente os pods afetados nos agentes K3s ativos restantes. O tempo total de failover (RTO) é a soma do intervalo de detecção de falhas (padrão: 30 segundos) e o tempo necessário para os componentes K3s inicializarem no nó secundário.

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

Etapa 3: Failback e reintegração automática

O failback ocorre quando o Servidor 1 é reiniciado após a resolução do problema inicial. SafeKit resincroniza automaticamente os arquivos MariaDB e NFS, atualizando apenas os dados modificados no Servidor 2 durante o tempo de inatividade. Esse 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 interrompido intencionalmente no Servidor 1, apenas as zonas específicas modificadas dentro dos arquivos são resincronizadas usando bitmaps de rastreamento de modificação. Isso garante uma reintegração ultrarrápida.
• Falha do sistema (por exemplo, falha de energia): se o Servidor 1 sofrer um desligamento incorreto, os bitmaps de modificação são ignorados por segurança. SafeKit em vez disso, resincroniza todos os arquivos 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: Restaurando a alta disponibilidade e a distribuição de carga

Após a reintegração, o cluster retorna ao modo mirror completo, espelhando o estado descrito na Etapa 1. O sistema está novamente em um 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 arquivos de volta para o Servidor 1.

O K3s Master e o K3s Agent são reiniciados automaticamente no Servidor 1. O agendador Kubernetes agora reconhece o Servidor 1 como um nó íntegro e pode começar a reagendar pods para distribuir a carga de trabalho em 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 do console da web em um momento conveniente ou automatizada através das configurações.

Como configurar um cluster mirror SafeKit?

O console da web SafeKit fornece uma interface intuitiva para orquestrar alta disponibilidade para seus aplicativos críticos. Em apenas algumas etapas, você pode configurar um cluster mirror SafeKit para garantir a continuidade dos negócios:

• Failover de Aplicativo (Guia Macros): Defina os serviços de aplicativo específicos a serem reiniciados automaticamente em caso de falha.
• Rede(s) de pulsações: Caminho(s) de comunicação dedicado(s) usado(s) pelos nós do cluster para monitorar continuamente a integridade e a disponibilidade um do outro e sincronizar as decisões de failover.
• Gerenciamento de IP virtual: configure o IP virtual (VIP) para 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 em nível de byte baseada no host.
• Verificadores: Monitore a integridade do aplicativo e acione a recuperação automática se for detectada uma falha no processo.

O cluster SafeKit inclui um verificador de divisão de rede dedicado para resolver problemas de isolamento de rede sem a necessidade de uma terceira máquina testemunha ou de uma rede de pulsações adicional. Saiba mais sobre pulsações, failover e quórum em um cluster.

Como monitorar um cluster mirror SafeKit?

O console de gerenciamento SafeKit oferece uma visão unificada da sua infraestrutura de alta disponibilidade. Ele permite que os administradores monitorem o estado operacional do cluster e acompanhem a sincronização de dados em tempo real.

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

• PRIM (Primário): O nó ativo que executa atualmente o aplicativo e gerencia o IP virtual. Ele executa gravações no armazenamento local e replicação em tempo real para o nó secundário.
• SECOND: O nó de espera recebe atualizações síncronas em nível de byte. Ele está pronto para assumir o controle instantaneamente se o primário falhar.
• ALONE Estado: Alerta visualmente quando o cluster está sendo executado em um único nó (por exemplo, durante a manutenção ou após uma falha), indicando que a redundância foi temporariamente perdida.
• Progresso da resincronização: quando um nó com falha é recuperado, seu status fica laranja durante a reintegração de dados em segundo plano, garantindo que não haja tempo de inatividade durante a fase de “retorno ao normal”.

Além de ícones de status simples, a interface fornece orquestração de failover com um clique, permitindo que você reatribua manualmente a função primária para manutenção planejada, garantindo a disponibilidade contínua para a atividade do usuário.

Limitações SafeKit de Alta Disponibilidade

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

Comparação: SafeKit vs. Open-Source Padrão (MetalLB + Longhorn)

Em resumo, enquanto uma pilha padrão de “faça você mesmo” (MetalLB + Longhorn) oferece modularidade para especialistas Kubernetes, ela cria uma dependência circular em que as ferramentas de armazenamento e rede são vulneráveis às mesmas falhas de nó que elas foram projetadas para gerenciar. SafeKit quebra esse ciclo operando como uma camada de infraestrutura independente; ele fornece uma solução de alta disponibilidade (HA) de 2 nós mais robusta e independente de hardware, que permanece operacional mesmo se o mecanismo Kubernetes ou o sistema operacional do host travar. Isso 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 pelos sistemas tradicionais de armazenamento em bloco distribuído e sobreposições de rede.

Guia em vídeo: Configurando um cluster mirror de alta disponibilidade com o SafeKit

Vídeo SafeKit: Agrupamento em nível de aplicativo (8:47)

Embora este vídeo demonstre a alta disponibilidade do SafeKit para Microsoft SQL Server, ele oferece 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 aplicativo 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. 🎬 Inicie e teste a replicação, migração e failover do SQL em caso de falha (4:17)

<br />

🔍 Explore o SafeKit

Encontre informações sobre os recursos, as arquiteturas, os vídeos, a documentação e a avaliação gratuita do SafeKit.