---
title: "Alta disponibilidad K3S con SafeKit: Instale el módulo k3s.safe para la conmutación por error"
canonical: "https://safekit.eviden.com/es/quick-install/safekit-quick-installation-guide-with-kubernetes/"
description: "Implemente el módulo k3s.safe para SafeKit para habilitar la replicación síncrona en tiempo real y la conmutación por error automática de Kubernetes en Linux. Esta guía le muestra cómo configurar un clúster sin SAN de 2 nodos para aplicaciones críticas Linux sin almacenamiento compartido."
category: "quick-install"
lang: "es"
topics: "Guía de instalación rápida de alta disponibilidad para Kubernetes, Limitaciones de alta disponibilidad SafeKit, Descripción general de la solución SafeKit/Kubernetes, Instalación y configuración de la solución SafeKit/Kubernetes en Linux (k3s.safe), ¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster?, Demostración de la solución mirror SafeKit"
translation: "translate_md 2026-11-08.15 | glossaire 2026-11-09.11 | Translation LLM | 31 expressions"
---
# Alta disponibilidad K3S con SafeKit: Instale el módulo k3s.safe para la conmutación por error {#k3s-high-availability-with-safekit-install-the-k3ssafe-module-for-failover}
## Guía de instalación rápida de alta disponibilidad para Kubernetes {#quick-guide}
Esta guía explica cómo configurar un **clúster mirror** para Kubernetes utilizando SafeKit, garantizando la conmutación por error automática y la replicación síncrona sin necesidad de almacenamiento compartido.
Para obtener ayuda, puedes usar [SafeKit AI 🤖](https://safekit.eviden.com/es/resources/safekit-support/).
### 1. Descripción general {#1-overview}
* **Arquitectura:** utiliza un sistema de dos nodos (primario/secundario).
* **Protección de datos:** implementa la replicación síncrona en tiempo real para **una pérdida de datos nula** (RPO = 0).
### 2. Instalación {#2-installation}
* **Software:** Instale el motor SafeKit en ambos servidores.
* **Módulo:** Descargue el módulo de aplicación `k3s.safe` preconfigurado.
### 3. Configuración {#3-configuration}
* **Consola web:** configure las carpetas específicas que contienen los archivos Kubernetes.
* **Supervisión:** Inicie la supervisión y protección de la aplicación Kubernetes.
## Limitaciones de alta disponibilidad SafeKit {#safekit-ha-limitations}
Límite / Requisito | Motivo e impacto | Alternativa recomendada
---|---|---
Tamaño de la replicación: unos pocos TB | Tiempo de resincronización tras un fallo ([paso 3](https://safekit.eviden.com/es/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)):
• Red de 1 Gb/s ≈ 3 horas/TB
• Red de 10 Gb/s ≈ 1 hora/TB (dependiendo del rendimiento de escritura del disco) | • Utilizar [almacenamiento compartido externo](https://safekit.eviden.com/es/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (más caro, más complejo).
Número de archivos: < 1 000 000 | • Rendimiento del tiempo de resincronización después de una falla ([paso 3](https://safekit.eviden.com/es/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Tiempo necesario para comparar cada archivo entre ambos nodos. | • Coloque los numerosos archivos que se van a replicar en un disco duro virtual o en una máquina virtual.
• En este caso, solo se replicarán y resincronizarán los archivos que representan el disco duro virtual o la máquina virtual.
Capacidad de conmutación por error: ≤ 32 máquinas virtuales | • Cada máquina virtual se ejecuta en un módulo mirror independiente.
• Máximo de 32 módulos mirror que se ejecutan en el mismo clúster. | • Utilizar un almacenamiento compartido externo y otra solución de clúster de máquinas virtuales (más cara y más compleja).
Arquitectura de red: red LAN/VLAN entre sitios remotos | • Conmutación por error automática de la [dirección IP virtual](https://safekit.eviden.com/es/best-practises/how-a-virtual-ip-address-works/) con 2 nodos en la misma subred.
• Buen ancho de banda para la resincronización ([paso 3](https://safekit.eviden.com/es/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Baja latencia para [la replicación sincrónica](https://safekit.eviden.com/es/best-practises/synchronous-replication-vs-asynchronous-replication/): normalmente < 5 ms RTT; los valores más altos deben validarse con la tasa de escritura de la aplicación. | • Si los dos nodos están en subredes diferentes (común en la nube), utilice [otras opciones de reenvío](https://safekit.eviden.com/es/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): un balanceador de carga, las CLI del proveedor de la nube, BGP o la redirección de DNS.
• Utilice soluciones de copia de seguridad con replicación asíncrona para redes con alta latencia.
## Descripción general de la solución SafeKit/Kubernetes {#overview-of-the-safekit--kubernetes-solution}
La solución se describe aquí: **💡 [Alta disponibilidad Kubernetes K3s: replicación síncrona y conmutación por error de 2 nodos]()**
## Instalación y configuración de la solución SafeKit/Kubernetes en Linux (k3s.safe) {#installation-and-configuration-of-the-safekit--kubernetes-solution-on-linux-k3ssafe}
### 1. Descargar paquetes {#1-download-packages}
* Descargue la versión gratuita de SafeKit 8.2 para Linux (safekitlinux_xx.bin)
* Descargue el módulo Linux k3s.safe
* Descargue el script k3sconfig.sh
* Documentación (pptx)
Nota: el script k3sconfig.sh instala K3S, MariaDB, NFS y SafeKit en 2 nodos Linux Ubuntu 24.04.
[Descargar SafeKit (Linux) >]()
Descargar k3s.safe (Linux) >
[Descargar k3sconfig.sh >]()
[Documentación (pdf) >]()
### 2. Primero en ambos nodos {#2-first-on-both-nodes}
En 2 nodos Linux Ubuntu 24.04, como root:
* Asegúrese de que el nodo tenga acceso a Internet (podría ser a través de un proxy)
* Copie k3sconfig.sh, k3s.safe y el paquete safekit_xx.bin en un directorio y acceda a él con cd
* Cambie el nombre del archivo .bin a "safekit.bin"
* Asegúrese de que k3sconfig.sh y safekit.bin sean ejecutables.
* Edite el script k3sconfig.sh y personalice las variables de entorno según su entorno (incluida una IP virtual)
* Ejecute en ambos nodos: `./k3sconfig.sh prereq`
El script:
* Instale los paquetes Debian necesarios: alien, nfs-kernel-server, nfs-common, mariadb-server
* Instalación segura de MariaDB
* Crear directorios para la replicación de archivos
* Prepare el servidor NFS para compartir los directorios replicados
* Instalar SafeKit
### 3. En el primer nodo {#3-on-the-first-node}
Ejecute en el primer nodo: `./k3sconfig.sh first`
El script:
* Cree la base de datos de configuración K3S y el usuario de k3s
* Cree el archivo de volumen de almacenamiento replicado (archivo disperso) y formatee el sistema de archivos como xfs
* Cree la configuración del clúster de safekit y aplíquela
* Instale y configure el módulo k3s.safe en el clúster
* Inicia el módulo k3s como "prim" en el primer nodo
* Descarga, instala e inicia k3s
* Descargue e instale el gráfico de Helm de nfs-subdir-external-provisioner
* Mostrar el token K3S (para usarlo durante la segunda fase de instalación del nodo)
### 4. En el segundo nodo {#4-on-the-second-node}
Ejecute en el segundo nodo: `./k3sconfig.sh second `
* es la cadena que se muestra al final de la ejecución de " k3sconfig.sh first" en el primer nodo
El script:
* Asegúrese de que el módulo k3s se inicie como primario en el primer nodo
* Instala k3s en el segundo nodo
* Inicia el módulo k3s
### 5. Compruebe que el módulo k3s SafeKit se esté ejecutando en ambos nodos {#5-check-that-the-k3s-safekit-module-is-running-on-both-nodes}
Compruebe con este comando en ambos nodos: `/opt/safekit/safekit –H "*" state`
La respuesta debe ser similar a la imagen.
/opt/safekit/safekit –H "*" state
---------------- Servidor= http://10.0.0.20:9010 ----------------
acción admin =ejecutar
--------------------- Estado de k3s ---------------------
Local (127.0.0.1): PRIM (Servicio: Disponible) (Color: Verde)
Éxito
---------------- Servidor= http://10.0.0.21:9010 ----------------
acción admin =ejecutar
--------------------- Estado de k3s ---------------------
Local (127.0.0.1): SECOND (Servicio: Disponible) (Color: Verde)
Éxito
### 6. Inicie la consola web SafeKit para administrar el clúster {#6-start-the-safekit-web-console-to-administer-the-cluster}
* Conecte un navegador a la URL de la consola web SafeKit `http://server0-IP:9010`.
* Deberías ver una página similar a la imagen.
* Compruebe con las líneas de comandos Linux que K3S se inicia en ambos nodos (iniciado en `start_prim` y `start_second`) y que MariaDB se inicia en el nodo principal (iniciado en `start_prim`).
### 7. Pruebas {#7-testing}
* Detenga el nodo PRIM desplazándose hacia abajo en su menú contextual y haciendo clic en `Stop`.
* Verifique que haya una conmutación por error en el SECOND nodo, que debería quedar ALONE (en verde).
* Y con las líneas de comando en Linux, compruebe la conmutación por error de los servicios (detenidos en el nodo 1 en el script `stop_prim` e iniciados en el nodo 2 en el script `start_prim`). MariaDB y K3S deberían ejecutarse en node2.
Si no se alcanza ALONE (verde) en node2, analice el motivo con el registro del módulo del nodo 2.
* Haga clic en `node2` para visualizar el registro del módulo.
* [Ejemplo de un registro de módulo SQL Server]() donde el nombre del servicio en `start_prim` no es válido. El proceso sqlserver.exe está supervisado, pero como no se inicia, al final el módulo se detiene.
Si todo está bien, inicie un inicio en node1, que resincronizará los directorios replicados desde node2.
Si las cosas van mal, detenga node2 y [fuerce el inicio como primario]() del node1, que se reiniciará con sus datos localmente saludables en el momento de la detención.
🛠️ [Más información sobre las pruebas en la Guía del usuario.]()
### 8. Pruebe el clúster con una aplicación Kubernetes como WordPress {#8-try-the-cluster-with-a-kubernetes-application-like-wordpress}
En la imagen tienes el ejemplo de una instalación de WordPress: un portal web con una base de datos de backend implementada por pods.
Puedes implementar tu propia aplicación de la misma manera.
WordPress es automáticamente de alta disponibilidad:
* con sus datos (php + base de datos) en volúmenes persistentes replicados en tiempo real por SafeKit
* con una dirección IP virtual para que los usuarios accedan al sitio de WordPress
* con conmutación por error automática y failback automático
Notas:
* El gráfico de WordPress define un servicio con balanceo de carga que escucha en los puertos y .
* WordPress es accesible a través de la URL: `http://:.`
* La IP virtual es administrada por SafeKit y se cambia automáticamente en caso de conmutación por error.
* Por defecto, K3S implementa balanceadores de carga con Klipper.
* Klipper escucha en : y enruta los paquetes TCP/IP a la dirección IP y el puerto del pod de WordPress que ha seleccionado.
$ 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
El comando helm anterior debería descargar la imagen de WordPress desde `registry-1.docker.io`. Es posible que encuentre problemas de autenticación en `registry-1.docker.io`. En este caso, debe:
* Cree `/etc/rancher/k3s/registries.yaml` en ambos nodos con el siguiente contenido:
configs:
"registry-1.docker.io":
auth:
username: your_user_name
password: your_password
tls:
insecure_skip_verify: true
* Detenga e inicie k3s para que se tengan en cuenta los cambios, con `systemctl stop k3s` y `systemctl start k3s`.
* Ejecute `helm registry login -u your_user_name docker.io` y, a continuación, introduzca su contraseña
### 9. Soporte {#9-support}
* Para obtener soporte, haga 2 `Snapshots` SafeKit (2 archivos .zip), una para cada nodo.
🛠️ [Solución de problemas en la Guía del usuario.]()
### 10. Si es necesario, configure un checker split-brain {#10-if-necessary-configure-a-splitbrain-checker}
* Consulte a continuación ["¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster?"](#isolation) para saber si necesita configurar un checker split-brain.
* En la configuración del módulo, haga clic en `Advanced Configuration` (ver imagen) para editar `userconfig.xml`.
* Declare el checker split-brain añadiendo lo siguiente en la sección `` de `userconfig.xml`:
...
...
* `Save and apply` la nueva configuración para volver a implementar el archivo userconfig.xml modificado en ambos nodos (el módulo debe detenerse en ambos nodos para guardar y aplicar).
**Parámetros**:
* `ident="witness"` identifica el testigo con un nombre de recurso: `splitbrain.witness`. Puede cambiar este valor para identificar el testigo.
* `exec="ping"` hace referencia al código ping que se va a ejecutar. No cambie este valor."
* `arg="witness IP"` es un argumento para el ping. Cambie este valor por la IP del testigo (un elemento robusto, normalmente un router).
## ¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster? {#isolation}
### Una única red {#a-single-network}
Cuando hay un aislamiento de red, el comportamiento predeterminado es:
* a medida que se pierden heartbeats de cada nodo, cada nodo pasa a ALONE y ejecuta la aplicación con su dirección IP virtual (doble ejecución de la aplicación que modifica sus datos locales),
* Cuando se repara el aislamiento, un nodo ALONE se ve obligado a detenerse y a resincronizar sus datos desde el otro nodo
* Al final, el clúster es PRIM-SECOND (o SECOND-PRIM, según la detección de direcciones IP virtuales duplicadas realizada por Windows).
### Dos redes con una red de replicación dedicada {#two-networks-with-a-dedicated-replication-network}
Cuando hay un aislamiento de red, el comportamiento con una red de replicación dedicada es el siguiente:
* se implementa una red de replicación dedicada en una red privada,
* se pierden heartbeats en la red de producción (red aislada),
* Heartbeats en la red de replicación funcionan (no en una red aislada),
* El clúster permanece en el estado PRIM/SECOND.
### Una única red y un checker split-brain {#a-single-network-and-a-splitbrain-checker}
Cuando hay un aislamiento de red, el comportamiento con un checker split-brain es:
* se ha configurado un checker split-brain con la dirección IP de un testigo (normalmente un enrutador),
* el checker split-brain funciona cuando un servidor pasa de PRIM a ALONE o de SECOND a ALONE,
* En caso de aislamiento de la red, antes de pasar a ALONE, ambos nodos prueban la dirección IP
* el nodo que puede acceder a la dirección IP pasa a ALONE, el otro pasa a WAIT,
* Cuando se repara el aislamiento, el nodo WAIT resincroniza sus datos y se convierte en SECOND.
Nota: Si el testigo está inactivo o desconectado, ambos nodos pasan a WAIT y la aplicación deja de ejecutarse. Por eso debe elegir un testigo robusto como un enrutador.
## Demostración de la solución mirror SafeKit {#demonstration-of-the-safekit-mirror-solution}
### Vídeo SafeKit: Agrupación en clúster a nivel de aplicación (8:47) {#demo-mirror-ha-cluster}
En este vídeo, descubra cómo SafeKit implementa un **clúster HA mirror** sin la complejidad de una SAN. Aunque esta demostración utiliza Microsoft SQL Server, la solución funciona de forma idéntica para otras bases de datos y aplicaciones.
### Capítulos {#chapters}
1. 🎬 [2 nodos con SQL Server](https://www.youtube.com/watch?v=mGwEguDnnH0&t=0s) (0:32)
2. 🎬 [Configura el clúster y el módulo mirror.safe](https://www.youtube.com/watch?v=mGwEguDnnH0&t=32s) (3:58)
3. 🎬 [Iniciar y probar la replicación, migración y conmutación por error de SQL en caso de fallo](https://www.youtube.com/watch?v=mGwEguDnnH0&t=270s) (4:17)
### Implementación paso a paso {#step-by-step-implementation}
* 🛠️ [Lee la guía sobre cómo configurar un clúster mirror en Windows](https://safekit.eviden.com/es/quick-install/safekit-quick-installation-guide-for-a-new-windows-application-with-real-time-replication-and-failover/)
* 🛠️ [Lee la guía sobre cómo configurar un clúster mirror en Linux](https://safekit.eviden.com/es/quick-install/safekit-quick-installation-guide-for-a-new-linux-application-with-real-time-replication-and-failover/)