---
title: "Alta Disponibilidade K3S com SafeKit: Instale o Módulo k3s.safe para Failover"
canonical: "https://safekit.eviden.com/pt-pt/quick-install/safekit-quick-installation-guide-with-kubernetes/"
description: "Implemente o módulo k3s.safe para SafeKit para ativar a replicação síncrona em tempo real e o failover automático do Kubernetes em Linux. Este guia explica como configurar um cluster SANless de 2 nós para aplicações Linux críticas sem armazenamento partilhado."
category: "quick-install"
lang: "pt-pt"
topics: "Guia de Instalação Rápida de Alta Disponibilidade para Kubernetes, Limitações de Alta Disponibilidade SafeKit, Visão geral da solução SafeKit/Kubernetes, Instalação e configuração da solução SafeKit/Kubernetes em Linux (k3s.safe), Quais são os diferentes cenários em caso de isolamento de rede num cluster?, Demonstração da solução mirror SafeKit"
translation: "translate_md 2026-11-08.15 | glossaire 2026-11-09.11 | Translation LLM | 30 expressions"
---
# Alta Disponibilidade K3S com SafeKit: Instale o Módulo k3s.safe para Failover {#k3s-high-availability-with-safekit-install-the-k3ssafe-module-for-failover}
## Guia de Instalação Rápida de Alta Disponibilidade para Kubernetes {#quick-guide}
Este guia explica como configurar um **cluster mirror** para Kubernetes usando SafeKit, garantindo a comutação automática de falhas e a replicação síncrona sem a necessidade de armazenamento partilhado.
Para obter ajuda, pode usar [SafeKit AI 🤖](https://safekit.eviden.com/pt-pt/resources/safekit-support/).
### 1. Visão Geral {#1-overview}
* **Arquitetura:** Utiliza um sistema de dois nós (Primário/Secundário).
* **Proteção de Dados:** Implementa replicação síncrona em tempo real para **perda zero de dados** (RPO = 0).
### 2. Instalação {#2-installation}
* **Software:** Instale o motor SafeKit em ambos os servidores.
* **Módulo:** Descarregue o módulo de aplicação pré-configurado `k3s.safe`.
### 3. Configuração {#3-configuration}
* **Consola Web:** Configure as pastas específicas que contêm os ficheiros Kubernetes.
* **Monitorização:** Inicie a monitorização e proteção da aplicação Kubernetes.
## Limitações de Alta Disponibilidade SafeKit {#safekit-ha-limitations}
Limite / Requisito | Razão e Impacto | Alternativa Recomendada
---|---|---
Tamanho da replicação: alguns TBs | Tempo de resincronização após falha ([passo 3](https://safekit.eviden.com/pt-pt/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)):
• Rede de 1 Gb/s ≈ 3 horas/TB
• Rede de 10 Gb/s ≈ 1 hora/TB (dependendo do desempenho de escrita do disco) | • Utilizar [armazenamento partilhado externo](https://safekit.eviden.com/pt-pt/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (mais caro, mais complexo).
Número de ficheiros: < 1.000.000 de ficheiros | • Desempenho do tempo de resincronização após uma falha ([passo 3](https://safekit.eviden.com/pt-pt/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Tempo necessário para comparar cada ficheiro entre os dois nós. | • Coloque os vários ficheiros a replicar num disco rígido virtual/máquina virtual.
• Apenas os ficheiros que representam o disco rígido virtual/máquina virtual serão replicados e resincronizados neste caso.
Capacidade de contingência: ≤ 32 máquinas virtuais | • Cada máquina virtual é executada num módulo mirror independente.
• Máximo de 32 módulos mirror a funcionar no mesmo cluster. | • Utilizar um armazenamento externo partilhado e outra solução de agrupamento de máquinas virtuais (mais cara, mais complexa).
Arquitetura de rede: rede LAN/VLAN entre locais remotos | • Comutação automática de falha do [endereço IP virtual](https://safekit.eviden.com/pt-pt/best-practises/how-a-virtual-ip-address-works/) com 2 nós na mesma sub-rede.
• Boa largura de banda para resincronização ([passo 3](https://safekit.eviden.com/pt-pt/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Baixa latência para [replicação síncrona](https://safekit.eviden.com/pt-pt/best-practises/synchronous-replication-vs-asynchronous-replication/): normalmente < 5 ms RTT; valores mais elevados devem ser validados em relação à taxa de escrita da aplicação. | • Se os dois nós estiverem em subredes diferentes (comum na nuvem), utilize [outras opções de reencaminhamento](https://safekit.eviden.com/pt-pt/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): um balanceador de carga, CLIs do fornecedor de nuvem, BGP ou redirecionamento de DNS.
• Utilize soluções de cópia de segurança com replicação assíncrona para redes com alta latência.
## Visão geral da solução SafeKit/Kubernetes {#overview-of-the-safekit--kubernetes-solution}
A solução é descrita aqui: **💡 [Kubernetes K3s Alta Disponibilidade: Replicação Síncrona e Failover de 2 Nós]()**
## Instalação e configuração da solução SafeKit/Kubernetes em Linux (k3s.safe) {#installation-and-configuration-of-the-safekit--kubernetes-solution-on-linux-k3ssafe}
### 1. Descarregar pacotes {#1-download-packages}
* Descarregue a versão gratuita do SafeKit 8.2 para Linux (safekitlinux_xx.bin)
* Descarregue o módulo Linux k3s.safe
* Faça o download do script k3sconfig.sh
* Documentação (pptx)
Nota: o script k3sconfig.sh instala K3S, MariaDB, o NFS e SafeKit em 2 nós Linux Ubuntu 24.04.
[Descarregue SafeKit (Linux) >]()
Descarregue k3s.safe (Linux) >
[Descarregar k3sconfig.sh >]()
[Documentação (pdf) >]()
### 2. Primeiro em ambos os nós {#2-first-on-both-nodes}
Em 2 nós Linux Ubuntu 24.04, como root:
* Certifique-se de que o nó tem acesso à internet (pode ser através de um proxy)
* Copie os k3sconfig.sh, k3s.safe e o pacote safekit_xx.bin para um diretório e navegue até ele
* Renomeie o ficheiro .bin para "safekit.bin"
* Certifique-se de k3sconfig.sh e safekit.bin são executáveis.
* Edite o script k3sconfig.sh e personalize as variáveis de ambiente de acordo com o seu ambiente (incluindo um IP virtual)
* Execute em ambos os nós: `./k3sconfig.sh prereq`
O guião irá:
* Instale os pacotes Debian necessários: alien, nfs-kernel-server, nfs-common, mariadb-server
* Instalação segura do MariaDB
* Crie diretórios para a replicação de ficheiros
* Prepare o servidor NFS para partilhar diretórios replicados
* Instale SafeKit
### 3. No primeiro nó {#3-on-the-first-node}
Execute no primeiro nó: `./k3sconfig.sh first`
O guião irá:
* Crie a base de dados de configuração K3S e o utilizador k3s
* Crie o ficheiro de volume de armazenamento replicado (ficheiro esparso) e formate-o como um sistema de ficheiros xfs
* Crie a configuração do cluster safekit e aplique-a
* Instale e configure o módulo k3s.safe no cluster
* Inicie o módulo k3s como "prim" no primeiro nó
* Descarregue, instale e inicie o k3s
* Descarregue e instale o gráfico Helm do nfs-subdir-external-provisioner
* Exibir o token K3S (a ser utilizado durante a segunda fase de instalação do nó)
### 4. No segundo nó {#4-on-the-second-node}
Execute no segundo nó: `./k3sconfig.sh second `
* é a cadeia de caracteres exibida no final da execução de " k3sconfig.sh first" no primeiro nó
O guião irá:
* Certifique-se de que o módulo k3s é iniciado como prim no primeiro nó
* Instale o k3s no segundo nó
* Inicie o módulo k3s
### 5. Verifique se o módulo k3s SafeKit está a ser executado em ambos os nós {#5-check-that-the-k3s-safekit-module-is-running-on-both-nodes}
Verifique com este comando em ambos os nós: `/opt/safekit/safekit –H "*" state`
A resposta deve ser semelhante à imagem.
/opt/safekit/safekit –H "*" state
---------------- Servidor= http://10.0.0.20:9010 ----------------
ação admin =executar
--------------------- Estado do k3s ---------------------
Local (127.0.0.1): PRIM (Serviço: Disponível) (Cor: Verde)
Sucesso
---------------- Servidor= http://10.0.0.21:9010 ----------------
ação admin =executar
--------------------- Estado do k3s ---------------------
Local (127.0.0.1): SECOND (Serviço: Disponível) (Cor: Verde)
Sucesso
### 6. Inicie a consola web SafeKit para administrar o cluster {#6-start-the-safekit-web-console-to-administer-the-cluster}
* Ligue um navegador ao URL da consola web SafeKit `http://server0-IP:9010`.
* Deverá ver uma página semelhante à imagem.
* Verifique, através das linhas de comando Linux, se K3S está iniciado em ambos os nós (iniciado em `start_prim` e `start_second`) e se MariaDB está iniciado no nó primário (iniciado em `start_prim`).
### 7. Testes {#7-testing}
* Pare o nó PRIM, percorrendo o menu contextual e clicando em `Stop`.
* Verifique se existe um failover no SECOND nó, que deverá ficar ALONE (verde).
* E com as linhas de comando no Linux, verifique a redundância dos serviços (parados no nó 1 no script `stop_prim` e iniciados no nó 2 no script `start_prim`). MariaDB e K3S devem ser executados no node2.
Se ALONE (verde) não for atingido no node2, analise o motivo com o registo do módulo do nó 2.
* clique no `node2` para exibir o registo do módulo.
* [Exemplo de um registo de módulo SQL Server]() onde o nome do serviço em `start_prim` é inválido. O processo sqlserver.exe é monitorizado, mas como não é iniciado, no final o módulo para.
Se tudo estiver bem, inicie o node1, que irá ressincronizar os diretórios replicados do node2.
Se as coisas correrem mal, pare node2 e [force o arranque]() do node1 como primário, que será reiniciado com os seus dados localmente íntegros no momento da paragem.
🛠️ [Mais informações sobre os testes no Guia do Utilizador.]()
### 8. Experimente o cluster com uma aplicação Kubernetes, como o WordPress {#8-try-the-cluster-with-a-kubernetes-application-like-wordpress}
Na imagem, tem o exemplo de uma instalação WordPress: um portal web com uma base de dados de backend implementada por pods.
Pode implementar a sua própria aplicação da mesma forma.
O WordPress é automaticamente altamente disponível:
* com os seus dados (php + base de dados) em volumes persistentes replicados em tempo real pelo SafeKit
* com um endereço IP virtual para aceder ao site WordPress para os utilizadores
* com comutação automática de contingência e failback automático
Notas:
* O gráfico do WordPress define um serviço de balanceamento de carga que escuta nas portas e .
* O WordPress está acessível através do URL: `http://:.`
* O IP virtual é gerido pelo SafeKit e é automaticamente alterado em caso de falha.
* Por predefinição, K3S implementa balanceadores de carga com o Klipper.
* O Klipper escuta em : e encaminha os pacotes TCP/IP para o endereço IP e a porta do pod do WordPress que selecionou.
$ export KUBECONFIG= /etc/rancher/k3s/k3s.yaml
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/wordpress --set global.storageClass=nfs-client --set service.ports.http=8099,service.ports.https=4439
O comando anterior do Helm deverá descarregar a imagem do WordPress do `registry-1.docker.io`. Poderá encontrar problemas de autenticação no `registry-1.docker.io`. Nesse caso, deverá:
* Crie o ficheiro `/etc/rancher/k3s/registries.yaml` em ambos os nós com o seguinte conteúdo:
configs:
"registry-1.docker.io":
auth:
username: your_user_name
password: your_password
tls:
insecure_skip_verify: true
* Para que as alterações sejam tida em conta, é necessário parar e iniciar o k3s, utilizando os `systemctl stop k3s` e `systemctl start k3s`.
* Execute o `helm registry login -u your_user_name docker.io` e, em seguida, introduza a sua palavra-passe
### 9. Apoio {#9-support}
* Para obter suporte, faça 2 `Snapshots` SafeKit (2 ficheiros .zip), uma para cada nó.
🛠️ [Resolução de problemas no Guia do Utilizador.]()
### 10. Se necessário, configure um checker split-brain {#10-if-necessary-configure-a-splitbrain-checker}
* Consulte abaixo ["Quais são os diferentes cenários em caso de isolamento de rede num cluster?"](#isolation) para saber se precisa de configurar um checker split-brain.
* Na configuração do módulo, clique em `Advanced Configuration` (ver imagem) para editar o `userconfig.xml`.
* Declare o checker split-brain adicionando-o na secção `` do `userconfig.xml`:
...
...
* `Save and apply` a nova configuração para reimplantar o ficheiro userconfig.xml modificado em ambos os nós (o módulo deve ser parado em ambos os nós para guardar e aplicar).
**Parâmetros** :
* `ident="witness"` identifica a testemunha com o nome do recurso: `splitbrain.witness`. Pode alterar este valor para identificar a testemunha.
* `exec="ping"` refere-se ao código de ping a ser executado. Não altere este valor.
* `arg="witness IP"` é um argumento para o ping. Altere este valor para o IP da testemunha (um elemento robusto, normalmente um router).
## Quais são os diferentes cenários em caso de isolamento de rede num cluster? {#isolation}
### Uma única rede {#a-single-network}
Quando existe um isolamento de rede, o comportamento predefinido é:
* à medida que heartbeats são perdidos para cada nó, cada nó vai para ALONE e executa a aplicação com o seu endereço IP virtual (execução dupla da aplicação que modifica os seus dados locais),
* quando o isolamento é reparado, um nó ALONE é forçado a parar e a resincronizar os seus dados a partir do outro nó,
* no final, o cluster é PRIM-SECOND (ou SECOND-PRIM, de acordo com a deteção de endereço IP virtual duplicado feita pelo Windows).
### Duas redes com uma rede de replicação dedicada {#two-networks-with-a-dedicated-replication-network}
Quando existe isolamento de rede, o comportamento com uma rede de replicação dedicada é:
* uma rede de replicação dedicada é implementada numa rede privada,
* Heartbeats na rede de produção são perdidas (rede isolada),
* Heartbeats na rede de replicação estão a funcionar (não é uma rede isolada),
* o cluster permanece no estado PRIM/SECOND.
### Uma única rede e um checker split-brain {#a-single-network-and-a-splitbrain-checker}
Quando existe um isolamento de rede, o comportamento com um checker split-brain é:
* um checker split-brain foi configurado com o endereço IP de um testemunha (normalmente um router),
* o checker split-brain funciona quando um servidor passa de PRIM para ALONE ou de SECOND para ALONE,
* em caso de isolamento de rede, antes de ir para ALONE, ambos os nós testam o endereço IP,
* o nó que consegue aceder ao endereço IP vai para ALONE, o outro vai para WAIT,
* Quando o isolamento é reparado, o nó WAIT resincroniza os seus dados e torna-se SECOND.
Nota: Se a testemunha estiver inativa ou desconectada, ambos os nós entram em WAIT e a aplicação deixa de funcionar. É por isso que deve escolher uma testemunha robusta, como um router.
## Demonstração da solução mirror SafeKit {#demonstration-of-the-safekit-mirror-solution}
### Vídeo SafeKit: Agrupamento a nível de aplicação (8:47) {#demo-mirror-ha-cluster}
Neste vídeo, descubra como SafeKit implementa um **cluster de alta disponibilidade mirror** sem a complexidade de uma SAN. Embora esta demonstração utilize Microsoft SQL Server, a solução funciona de forma idêntica para outras bases de dados e aplicações.
### Capítulos {#chapters}
1. 🎬 [2 nós com SQL Server](https://www.youtube.com/watch?v=mGwEguDnnH0&t=0s) (0:32)
2. 🎬 [Configure o cluster e o módulo mirror.safe](https://www.youtube.com/watch?v=mGwEguDnnH0&t=32s) (3:58)
3. 🎬 [Iniciar e testar a replicação, migração e failover do SQL em caso de falha](https://www.youtube.com/watch?v=mGwEguDnnH0&t=270s) (4:17)
### Implementação Passo a Passo {#step-by-step-implementation}
* 🛠️ [Leia o guia sobre como configurar um cluster mirror no Windows](https://safekit.eviden.com/pt-pt/quick-install/safekit-quick-installation-guide-for-a-new-windows-application-with-real-time-replication-and-failover/)
* 🛠️ [Leia o guia sobre como configurar um cluster mirror no Linux](https://safekit.eviden.com/pt-pt/quick-install/safekit-quick-installation-guide-for-a-new-linux-application-with-real-time-replication-and-failover/)