Alta disponibilidad K3S con SafeKit: Instale el módulo k3s.safe para la conmutación por error

Guía de instalación rápida de alta disponibilidad para Kubernetes

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 🤖.

1. Descripción general

• 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

• Software: Instale el motor SafeKit en ambos servidores.
• Módulo: Descargue el módulo de aplicación k3s.safe preconfigurado.

3. Configuración

• 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

Descripción general de la solución SafeKit/Kubernetes

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)

1. Descargar paquetes

• 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

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

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

Ejecute en el segundo nodo: ./k3sconfig.sh second <token>

• 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

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

• 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

• 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

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 <service.port> y <service.httpsport>.

• WordPress es accesible a través de la URL: http://<virtual-ip>:<service.port>.

• 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 : <service.port> 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

• 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

• Consulte a continuación "¿Cuáles son los diferentes escenarios en caso de aislamiento de red en un clúster?" 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 <check> de userconfig.xml:

  <service>
   ...
   <check>
    ...
    <splitbrain ident="witness" exec="ping" arg="witness IP"/>
   </check>
  

• 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?

Una única red

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

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

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

Vídeo SafeKit: Agrupación en clúster a nivel de aplicación (8:47)

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

1. 🎬 2 nodos con SQL Server (0:32)
2. 🎬 Configura el clúster y el módulo mirror.safe (3:58)
3. 🎬 Iniciar y probar la replicación, migración y conmutación por error de SQL en caso de fallo (4:17)

Implementación paso a paso

• 🛠️ Lee la guía sobre cómo configurar un clúster mirror en Windows
• 🛠️ Lee la guía sobre cómo configurar un clúster mirror en Linux

🔍 Explora SafeKit

Encuentre información sobre las características, arquitecturas, vídeos, documentación y la prueba gratuita de SafeKit.