1 votos

Kubernetes Almacenamiento para multinodo en VPS

Tengo una configuración de Kubernetes (lo hice siguiendo algunos tutoriales) en 4 servidores VPS, 1 nodo maestro y 3 nodos de trabajador. Pero ahora he leído sobre el volumen de persistencia y no sé por dónde empezar.

El plan es: alojar un sitio web que tenga cargas continuas, pero necesito que los datos se compartan en todos los trabajadores, ¿cuál es la mejor opción para basarse en clúster? ¿Hay algún módulo o complemento de Kubernetes que pueda usar para que los 3 trabajadores compartan los datos y si uno, digamos, falla, los otros continúen funcionando? Por favor, ayúdame, ya que necesito que todos los datos, incluido MySQL, estén escalados en los 3 nodos de trabajo y si uno de los nodos de trabajo se cae, todo el trabajo continúa con los nodos de trabajo 1 y 2 hasta que el 3 se restaure o se reemplace.

Por favor, apúntame en la dirección correcta, ya que no puedo crear un servidor NFS en el VPS.

0voto

SYN Puntos 352
  1. CNS

Al seguir con Kubernetes, la respuesta obvia sería investigar sobre soluciones de Almacenamiento Nativo de Contenedores (por ej: Ceph y Rook, o GlusterFS que no recomendaría).

Aunque esto usualmente implica dimensionar tus nodos y adjuntar dispositivos de bloque adecuadamente. En algunos casos, nodos dedicados podrían tener sentido, evitando problemas de concurrencia. De lo contrario, asegúrate de que todos los Pods tengan las solicitudes y límites de cpu/memoria correctamente configurados.

Una solución más simple podría haber implicado algo como MinIO. Configurarlo no es complicado, podría depender fácilmente del sistema de archivos de tus hosts. Aunque el problema principal sería que tus aplicaciones tendrían que implementar el almacenamiento s3. Sin base de datos MySQL. Es poco probable que tu sitio funcione de esa manera.

  1. Cluster Dedicado

Otra opción podría ser desplegar tu propio cluster de almacenamiento, en nodos separados. Ceph siendo un buen candidato, busca los playbooks de ceph-ansible en GitHub.

Aquí, usar nodos pequeños (1-2 CPU, 4-8G RAM, 1-3x 1T SATA2, 1x1G network) sería más fácil que con Rook. Aunque el rendimiento no será asombroso, será confiable de todas formas. Las recomendaciones de hardware apuntan al mejor rendimiento, Ceph estaba diseñado para funcionar en hardware estándar.

  1. Host(s) Dedicado(s)

Más simple que un cluster de almacenamiento: algo como un par de FreeBSD, usando ctld (objetivo iscsi), hastd (sincronización de dispositivos entre tus hosts), carp (VIP) y ifstated (scripting de failover basado en el estado de VIP). Y probablemente ZFS, para la gestión de volúmenes, instantáneas, ...

O un par de Linux con tgt (objetivo iscsi), drdb (sincronización de dispositivos) y keepalived (VIP + scripts). Y volúmenes / instantáneas de LVM.

O simplemente un servidor único (no recomendado).

Tal vez quedarse con comparticiones NFS (no recomendado).

  1. Terceros

Con un poco de suerte, tu proveedor de alojamiento ofrece una solución (dispositivos de bloque iSCSI, ceph o gluster, tal vez algunas comparticiones NFS, ... evita las de samba). Podría ser costoso, en algunos casos.

  1. Ninguno de los Anteriores

De lo contrario, te quedas con volúmenes de hostPath.

Los Datos se escribirían directamente en un nodo de Kubernetes dado, tendrías que mapear los Pods con datos persistentes con un nodo estático.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X