Plataforma CI/CD Kubernetes Gitorion. NAS replicado para clúster Kubernetes de alta disponibilidad / Sudo Null IT News
¡Hola a todos! En este artículo hablaremos sobre cómo las aplicaciones con estado almacenan sus datos en la versión de alta disponibilidad de la plataforma Gitorion CI/CD. La plataforma Gitorion incluye tres aplicaciones Stateful:
Gitea/Forgejo: almacena repositorios git con código de aplicación;
Jenkins: almacena su configuración y canalizaciones;
Registro de Docker: almacena imágenes de Docker de microservicios personalizados.
Las aplicaciones de usuario que se desarrollarán en la plataforma y se implementarán en producción también pueden almacenar sus datos.
Declaración abstracta del problema
Para un clúster de Kubernetes de alta disponibilidad, distribuido geográficamente en dos centros de datos, desarrolle un almacenamiento de datos en el que las aplicaciones con estado puedan almacenar sus archivos y directorios. En caso de que uno de los centros de datos falle, el segundo centro de datos debe tener una copia actualizada de los datos de la aplicación Stateful. Los módulos de aplicaciones con estado deben conectarse al almacenamiento a través de la red para permitir el escalamiento horizontal.
Sistema de discos y gestión de particiones.
En cada uno de los dos centros de datos, asignamos un nodo que actuará como NAS. Un VPS independiente o un servidor dedicado con discos de servidor pueden actuar como NAS. Depende de tu presupuesto y preferencias. Es importante poder conectar nuevas unidades cuando se agote el espacio libre.
Usamos LVM para la gestión de particiones.
Realizamos los siguientes pasos en espejo en ambos NAS de cada centro de datos. Cree un grupo de volúmenes separado con el nombre “nas”. Un VG separado resolverá dos problemas:
almacenar los datos de la aplicación por separado del sistema operativo, de modo que, en caso de falla, el sistema operativo no arrastre los datos de almacenamiento consigo;
agregue nuevos discos a VG y expanda las particiones de volumen lógico cuando se queden sin espacio libre.
Para las instancias de Gitea/Forgejo, Jenkins y Docker-registry, creamos volúmenes lógicos separados en el grupo de volúmenes “nas” creado anteriormente. De cara al futuro, observamos que la replicación requerirá LV del mismo tamaño en cada uno de los centros de datos para una instancia específica.
Replicación de datos entre centros de datos.
Para la replicación de datos, elegimos entre Ceph, GlusterFS y DRBD. Ceph es superficial debido a sus demandas de recursos y al requisito de un nodo separado para almacenar metadatos. GlusterFS resultó ser bastante bueno para la replicación dentro del mismo centro de datos con bajos retrasos de red entre nodos replicados e inadecuado para la replicación entre nodos geográficamente separados y con altos retrasos de red. Como resultado, nuestra elección recayó en DRBD, una herramienta probada incluida en el kernel de Linux desde 2009.
DRBD replica un dispositivo de bloque local a través de la red a un dispositivo de bloque remoto. Una especie de espejo de red RAID1. En nuestro caso, el papel de los dispositivos de bloques replicados es el Volumen Lógico creado en el párrafo anterior. DRBD crea dispositivos de bloques virtuales /dev/drbd1, /dev/drbd2, /dev/drbd3… /dev/drbdX y los asocia con dispositivos de bloques replicados. Posteriormente se crea un sistema de archivos en el dispositivo de bloque virtual /dev/drbdX, se monta y es utilizado por las aplicaciones.
Archivo de configuración DRBD:
resource r0 {
volume 0 {
device /dev/drbd1;
disk /dev/nas/forgejo;
meta-disk internal;
}
volume 1 {
device /dev/drbd2;
disk /dev/nas/jenkins;
meta-disk internal;
}
volume 2 {
device /dev/drbd3;
disk /dev/nas/registry;
meta-disk internal;
}
on dc1-nas {
address 1.1.1.1:7789;
}
on dc2-nas {
address 2.2.2.2:7789;
}
}Lista de dispositivos de bloqueo:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 5G 0 disk
├─sda1 8:1 0 487M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4.5G 0 part
├─template--vg-root 254:1 0 3.6G 0 lvm /
└─template--vg-swap_1 254:3 0 980M 0 lvm
sdb 8:16 0 5G 0 disk
├─nas-forgejo 254:0 0 1G 0 lvm
│ └─drbd1 147:1 0 1023.9M 0 disk
├─nas-jenkins 254:2 0 1G 0 lvm
│ └─drbd2 147:2 0 1023.9M 0 disk
├─nas-registry 254:4 0 1G 0 lvm
└─drbd3 147:3 0 1023.9M 0 diskConvertir el almacenamiento de archivos en NAS
Hay varios opciones conectar volúmenes persistentes externos a módulos de Kubernetes. Seleccionamos el volumen de red Volumen persistente del tipo NFS. Esta solución arquitectónica le permite escalar horizontalmente un clúster de Kubernetes, de lo que hablaremos un poco más adelante.
Mientras tanto, convirtamos nuestro almacenamiento de archivos en un NAS. Realizamos acciones adicionales solo en el nodo primario, que es la fuente de replicación DRBD en el centro de datos líder. Formateamos los dispositivos de bloques virtuales DRBD y los montamos en el directorio /mnt
mkfs.ext4 /dev/drbd1
mkfs.ext4 /dev/drbd2
mkfs.ext4 /dev/drbd3
mount /dev/drbd1 /mnt/forgejo
mount /dev/drbd2 /mnt/jenkins
mount /dev/drbd3 /mnt/registryInstalamos un servidor NFS y exportamos sistemas de archivos montados a la red utilizando el protocolo NFS. Archivo /etc/exportaciones
/mnt/forgejo/ 3.3.3.3(rw,sync,no_subtree_check,all_squash)
/mnt/jenkins/ 3.3.3.3(rw,sync,no_subtree_check,all_squash)
/mnt/registry/ 3.3.3.3(rw,sync,no_subtree_check,all_squash)
Como resultado, recibimos un NAS en un centro de datos líder, que envía directorios montados en dispositivos de bloques virtuales DRBD a la red a través de NFS. Y DRBD replica los datos al nodo DRBD de Seconrady en el centro de datos esclavo.
Conexión de pods de Kubernetes al NAS
En Kubernetes, creamos volúmenes persistentes del tipo NFS que se conectan a través de la red al NAS. Y el volumen persistente está conectado a los módulos Stateful Kubernetes.
Caída de un centro de datos esclavo
Si el centro de datos esclavo falla, los módulos con estado simplemente continúan su trabajo en el centro de datos maestro. Lo único que hay que hacer es desconectar el nodo primario del clúster DRBD en el centro de datos líder y cambiarlo al modo independiente mientras reparan el centro de datos caído. Tan pronto como se repare el centro de datos esclavo, deberá volver a conectar el nodo primario al clúster DRBD y el delta de datos acumulado se replicará en el nodo DRBD secundario.
La caída de un centro de datos líder
Si el centro de datos maestro falla, Kubernetes iniciará módulos de aplicación con estado en el centro de datos esclavo superviviente. Y los volúmenes de volumen persistente de los módulos Gitea/Forgejo, Jenkins y Docker-registry se conectarán al NAS en el centro de datos superviviente y las aplicaciones con estado seguirán funcionando con los datos que RDBD replicó desde el centro de datos caído en el momento de la caída. caer.
Destacaremos por separado el mecanismo para cambiar el volumen persistente de un NAS a otro. En la especificación de volumen persistente, especificamos el nombre de dominio del servidor NFS nas.gitorion.ru
apiVersion: v1
kind: PersistentVolume
metadata:
name: forgejo
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 50Gi
nfs:
path: /mnt/forgejo
server: nas.gitorion.ru
persistentVolumeReclaimPolicy: Retain
storageClassName: net-disksY sobre los trabajadores, asociamos estáticamente el nombre de dominio del servidor NFS nas.gitorion.ru en /etc/hosts con la dirección IP del NAS en el mismo centro de datos en el que se encuentra el trabajador:
Archivo /etc/hosts en dc1-worker:
127.0.0.1 localhost
1.1.1.1 nas.gitorion.ruArchivo /etc/hosts en dc2-worker:
127.0.0.1 localhost
2.2.2.2 nas.gitorion.ruComo resultado, los módulos de la aplicación Stateful, que utilizan el mismo nombre de dominio del servidor NFS nas.gitorion.ru, en la especificación de volumen persistente, se conectan al NAS en el centro de datos en el que se ejecutarán.
Después de restaurar un centro de datos caído, la replicación DRBD debe implementarse en la dirección opuesta: convertir el nodo DRBD en el centro de datos superviviente en Primario y en el centro de datos restaurado en Secundario.
Cerebro dividido
Esta es una situación en la que ambos centros de datos están vivos, pero la conexión entre ellos se pierde. Utilizamos únicamente replicación DRBD unidireccional. En un momento dado, los módulos Stateful se ejecutan solo en el centro de datos principal y están conectados al NAS y al nodo DRBD primario, que es la fuente de replicación. El segundo NAS siempre actúa como esclavo; el nodo DRBD que contiene funciona en modo secundario y simplemente almacena una copia de los datos en caso de que falle el centro de datos maestro. Por tanto, se excluye la situación de grabación simultánea en ambos NAS.
Escalado horizontal
La presencia de NAS replicados en dos centros de datos abre la posibilidad de escalamiento horizontal de aplicaciones Stateful de usuario cuando la capacidad de los centros de datos existentes se vuelve insuficiente.
En este caso, puede conectar trabajadores adicionales de otros centros de datos al clúster de Kubernetes y ejecutar réplicas adicionales de aplicaciones Stateful personalizadas en ellos, que se conectarán al NAS maestro a través de NFS.
Sin embargo, no olvide que las aplicaciones Stateful se conectarán al NAS a través de Internet y la latencia puede aumentar significativamente en comparación con la conexión a un NAS dentro del mismo centro de datos.
Conclusión
Como resultado, recibimos almacenamiento de archivos externo para un clúster de Kubernetes de alta disponibilidad, distribuido en dos centros de datos. El almacenamiento de archivos está conectado al clúster de Kubernetes como un NAS mediante el protocolo de red NFS, que permite que las aplicaciones Stateful escale horizontalmente. Cada centro de datos tiene su propio NAS, cuyos datos son replicados por DRBD, lo que permite detener las aplicaciones Stateful en un centro de datos e iniciarlas en otro en caso de accidente. ¡Gracias por su atención!
