Actualización! . En los comentarios, uno de los lectores sugirió probar Linstor (tal vez él mismo trabaja en él), así que agregué una sección sobre esta solución. También escribí una publicación sobre cómo instalarlo , porque el proceso es muy diferente del resto.
Para ser sincero, me di por vencido y abandoné Kubernetes (al menos por ahora). Usaré Heroku . Por qué ¡Por el almacenamiento! ¿Quién hubiera pensado que me molestaría más con el almacenamiento que con Kubernetes? Utilizo Hetzner Cloud porque es económico y el rendimiento es bueno, y desde el principio implementé clústeres con Rancher . No he probado los servicios administrados de Kubernetes de Google / Amazon / Microsoft / DigitalOcean, etc., etc., porque quería aprender todo por mí mismo. Y yo soy económico.
Entonces, sí, pasé mucho tiempo tratando de decidir qué almacenamiento elegir cuando estaba considerando una posible pila en Kubernetes. Prefiero las soluciones de código abierto, y no solo por el precio, sino que estudié un par de opciones pagas por curiosidad, porque tienen versiones gratuitas con restricciones. Escribí algunos números de las últimas pruebas cuando estaba comparando diferentes opciones, y podrían ser de interés para aquellos que estudian el almacenamiento en Kubernetes. Aunque personalmente hasta ahora he dicho adiós a Kubernetes. También quiero mencionar el controlador CSI , en el que puede preparar directamente los volúmenes de Hetzner Cloud, pero aún no lo he probado. Estudié el almacenamiento definido por software basado en la nube porque necesitaba replicación y la capacidad de montar rápidamente volúmenes persistentes en cualquier nodo, especialmente en el caso de una falla del nodo y otras situaciones similares. Algunas soluciones ofrecen instantáneas en un momento dado y copias de seguridad fuera del sitio, lo cual es conveniente.
Probé 6-7 soluciones de almacenamiento:
Como dije en una publicación anterior , después de probar la mayoría de las opciones en la lista, inicialmente me decidí por OpenEBS. OpenEBS es muy fácil de instalar y usar, pero para ser honesto, después de probar con datos reales bajo carga, su rendimiento me decepcionó. Este es un código abierto, y los desarrolladores en su canal Slack siempre me ayudaron mucho cuando necesitaba ayuda. Desafortunadamente, tiene un rendimiento muy bajo en comparación con otras opciones, por lo que tuve que ejecutar las pruebas nuevamente. OpenEBS ahora tiene 3 motores de almacenamiento, pero estoy publicando los resultados de referencia para cStor. Hasta ahora no tengo números para Jiva y LocalPV.
En pocas palabras, Jiva es un poco más rápido, y LocalPV es generalmente más rápido, no peor que el punto de referencia del disco directamente. El problema con LocalPV es que el acceso al volumen solo se puede obtener en el nodo donde se preparó, y no hay absolutamente ninguna replicación. Tuve algunos problemas para recuperar la copia de seguridad a través de Velero en un nuevo clúster, porque los nombres de los nodos eran diferentes. Si hablamos de copias de seguridad, cStor tiene un complemento para Velero , con el que puede hacer copias de seguridad de instantáneas fuera del sitio a la vez, lo cual es más conveniente que las copias de seguridad a nivel de archivo con Velero-Restic. Escribí varios scripts para facilitar la administración de copias de seguridad y restauraciones con este complemento. En general, me gusta mucho OpenEBS, pero su rendimiento ...
Rook también tiene código fuente abierto, y se diferencia de las otras opciones en la lista en que es un orquestador de almacenamiento que realiza tareas complejas de administrar el almacenamiento con diferentes backends, como Ceph , EdgeFS y otros, lo que simplifica enormemente el trabajo. Tuve problemas con EfgeFS cuando lo probé hace unos meses, así que probé principalmente con Ceph. Ceph ofrece no solo almacenamiento en bloque, sino también almacenamiento de objetos compatible con S3 / Swift y el sistema de archivos distribuido. Lo que me gusta de Ceph es la capacidad de distribuir datos de volumen a través de múltiples discos para que el volumen pueda usar más espacio del disco que el que cabe en un solo disco. Esto es conveniente Otra característica interesante es que cuando agrega discos a un clúster, redistribuye automáticamente los datos en todos los discos.
Hay instantáneas en Ceph, pero que yo sepa, no se pueden usar directamente en Rook / Kubernetes. Es cierto, no entré en esto. Pero fuera del sitio no hay copias de seguridad, por lo que debe usar algo con Velero / Restic, pero solo hay copias de seguridad a nivel de archivo, no instantáneas en ese momento. Pero en Rook, me gustó mucho el trabajo simple con Ceph: oculta casi todas las cosas complejas y ofrece herramientas para comunicarse directamente con Ceph para la resolución de problemas. Desafortunadamente, en la prueba de esfuerzo de los volúmenes de Ceph, tuve este problema todo el tiempo, debido a lo cual Ceph se volvió inestable. Todavía no está claro si esto es un error en Ceph o un problema en cómo Rook controla a Ceph. Conjuré con la configuración de memoria, y mejoró, pero el problema no se resolvió hasta el final. Ceph tiene un buen rendimiento, como puede ver en los puntos de referencia a continuación. Él también tiene un buen tablero de instrumentos.
Realmente me gusta Longhorn. En mi opinión, esta es una solución prometedora. Es cierto que los propios desarrolladores (Rancher Labs) reconocen que no es adecuado para el entorno de trabajo, y esto se puede ver. Tiene un código fuente abierto y un buen rendimiento (aunque aún no lo han optimizado), pero los volúmenes tardan mucho en conectarse al hogar, y en el peor de los casos tarda entre 15 y 16 minutos, especialmente después de restaurar una copia de seguridad grande o actualizar la carga de trabajo. Tiene instantáneas y copias de seguridad fuera del sitio de estas instantáneas, pero se aplican solo a los volúmenes, por lo que aún necesita algo como Velero para respaldar otros recursos. Las copias de seguridad y la recuperación son muy confiables, pero indecentemente lentas. En serio, solo prohibitivamente lento. La utilización de la CPU y la carga del sistema a menudo saltan cuando se trabaja con datos promedio en Longhorn. Hay un tablero conveniente para controlar el Longhorn. Ya dije que me gusta Longhorn, pero hay que trabajarlo.
StorageOS es el primer producto pagado en la lista. Tiene una versión para desarrolladores con un almacenamiento administrado limitado de 500 GB, pero el número de nodos, en mi opinión, no es limitado. El departamento de ventas me dijo que el costo comienza en $ 125 por mes por 1 TB, si no recuerdo mal. Hay un tablero básico y una CLI conveniente, pero algo extraño está sucediendo con el rendimiento: en algunos puntos de referencia es bastante decente, pero no me gustó en absoluto la velocidad en la prueba de esfuerzo de los volúmenes. En general, no sé qué decir. Por lo tanto, no entendí particularmente. No hay copias de seguridad fuera del sitio, y también tendrá que usar Velero con Restic para hacer copias de seguridad de los volúmenes. Es extraño, porque el producto está pagado. Y los desarrolladores no estaban ansiosos por comunicarse en Slack.
Aprendí sobre Robin en Reddit de su director técnico. Nunca había oído hablar de él antes. Tal vez porque estaba buscando soluciones gratuitas y Robin pagó. Tienen una versión gratuita bastante generosa con 10 TB de almacenamiento y tres nodos. En general, el producto es bastante decente y con buenas características. Hay una gran CLI allí, pero lo bueno es que puedes tomar instantáneas y hacer una copia de seguridad de toda la aplicación (en el selector de recursos esto se llama lanzamientos de Helm o "aplicaciones flexibles"), incluidos los volúmenes y otros recursos, para que puedas prescindir de Velero. Y todo sería maravilloso si no fuera por un pequeño detalle: si restaura (o "importa", como Robin lo llama) una aplicación en un nuevo clúster, por ejemplo, en caso de recuperación después de un accidente, la recuperación, por supuesto, funciona, pero continúa respaldando la aplicación no permitido En esta versión, esto simplemente no es posible, y los desarrolladores lo han confirmado. Esto, por decirlo suavemente, es extraño, especialmente cuando considera las otras ventajas (por ejemplo, copias de seguridad y recuperación increíblemente rápidas). Los desarrolladores prometen arreglar todo para la próxima versión. El rendimiento generalmente es bueno, pero noté algo extraño: si ejecuta el punto de referencia directamente en el volumen conectado al host, la velocidad de lectura es mucho mayor que en el mismo volumen, pero desde el interior. Todos los demás resultados son idénticos, pero en teoría no debería haber diferencia. Aunque están trabajando en ello, estaba molesto por el problema con la recuperación y la copia de seguridad: me pareció que finalmente encontré una solución adecuada, e incluso estaba listo para pagar cuando necesitaba más espacio o más servidores.
Realmente no tengo nada que decir aquí. Este es un producto pagado, igualmente genial y costoso. El rendimiento es un milagro. Hasta ahora este es el mejor indicador. Slack me dijo que el precio comienza en $ 205 por mes por nodo, como se indica en Google GKE Marketplace. No sé si será más barato si compras directamente. En cualquier caso, no puedo pagarlo, así que me decepcionó mucho que la licencia de desarrollador (hasta 1 TB y 3 nodos) sea prácticamente inútil con Kubernetes, a menos que esté satisfecho con la preparación estática. Esperaba que la licencia por volumen cayera automáticamente al nivel del desarrollador al final del período de prueba, pero no fue así. La licencia de desarrollador solo se puede usar directamente con Docker, y la configuración en Kubernetes es muy engorrosa y limitada. Por supuesto, prefiero el código abierto, pero si tuviera dinero, definitivamente elegiría Portworx. Hasta ahora, su rendimiento simplemente no se compara con otras opciones.
Agregué esta sección después de la publicación de la publicación, cuando un lector sugirió probar Linstor. ¡Lo probé y me gustó! Pero aún tienes que cavar. Ahora puedo decir que el rendimiento no es malo (agregué los resultados de referencia a continuación). De hecho, obtuve el mismo rendimiento que para la unidad directamente, sin absolutamente ninguna sobrecarga. (No pregunte por qué Portworx tiene mejores números que el punto de referencia de la unidad directamente. No tengo idea. Magia, probablemente.) Entonces Linstor todavía parece muy efectivo. Instalarlo no es tan difícil, pero no tan fácil como las otras opciones. Primero tuve que instalar Linstor (el módulo del núcleo y las herramientas / servicios) y configurar LVM para el aprovisionamiento ligero y las instantáneas de soporte fuera de Kubernetes, directamente en el host, y luego crear los recursos necesarios para usar el almacenamiento de Kubernetes. No me gustó que no funcionó en CentOS y tuve que usar Ubuntu. No da miedo, por supuesto, pero es un poco molesto, porque la documentación (que, por cierto, es excelente) menciona varios paquetes que no se pueden encontrar en los repositorios especificados de Epel. Linstor tiene instantáneas, pero no copias de seguridad fuera del sitio, por lo que aquí nuevamente tuve que usar Velero con Restic para respaldar volúmenes. Preferiría instantáneas en lugar de copias de seguridad a nivel de archivo, pero esto se puede tolerar si la solución es productiva y confiable. Linstor tiene código abierto, pero hay soporte pagado. Si entiendo correctamente, se puede usar sin restricciones, incluso si no tiene un acuerdo de soporte, pero esto debe aclararse. No sé cómo se prueba Linstor para Kubernetes, pero el nivel de almacenamiento en sí está fuera de Kubernetes y, aparentemente, la solución no apareció ayer, por lo que probablemente ya se haya probado en condiciones reales. ¿Hay alguna solución aquí que me haga cambiar de opinión y volver a Kubernetes? No lo sé, no lo sé. Todavía es necesario cavar más profundo, estudiar la replicación. A ver Pero la primera impresión es buena. Definitivamente preferiría usar mis propios grupos de Kubernetes en lugar de Heroku para obtener más libertad y aprender cosas nuevas. Dado que Linstor no se instala tan fácilmente como otros, escribiré una publicación sobre esto pronto.
Puntos de referencia
Desafortunadamente, he mantenido pocos registros de la comparación, porque no pensé que escribiría sobre eso. Solo tengo los resultados de los puntos de referencia base de fio, y solo para los clústeres de un solo nodo, por lo que para las configuraciones replicadas todavía no tengo números. Pero a partir de estos resultados, puede obtener una idea aproximada de qué esperar de cada opción, porque los comparé en los mismos servidores en la nube, 4 núcleos, 16 GB de RAM, con un disco adicional de 100 GB para los volúmenes bajo prueba. Ejecuté los puntos de referencia tres veces para cada solución y calculé el resultado promedio, además de restablecer la configuración del servidor para cada producto. Todo esto es completamente no científico, solo para hacerte entender en términos generales. En otras pruebas, copié 38 GB de fotos y videos del volumen y para probar la lectura y la escritura, pero, por desgracia, no guardé los números. En resumen: Portworkx fue mucho más rápido.
Para el punto de referencia de los volúmenes, utilicé este manifiesto:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: dbench spec: storageClassName: ... accessModes: - ReadWriteOnce resources: requests: storage: 5Gi --- apiVersion: batch/v1 kind: Job metadata: name: dbench spec: template: spec: containers: - name: dbench image: sotoaster/dbench:latest imagePullPolicy: IfNotPresent env: - name: DBENCH_MOUNTPOINT value: /data - name: FIO_SIZE value: 1G volumeMounts: - name: dbench-pv mountPath: /data restartPolicy: Never volumes: - name: dbench-pv persistentVolumeClaim: claimName: dbench backoffLimit: 4
Primero creé un volumen con la clase de almacenamiento correspondiente, y luego comencé la tarea con fio detrás de escena. Tomé 1 GB para estimar el rendimiento y no esperar demasiado. Aquí están los resultados:
Destaqué el mejor valor para cada indicador en verde, y el peor en rojo.
Conclusión
Como puede ver, en la mayoría de los casos Portworx se desempeñó mejor que otros. Pero para mí, él es querido. No sé cuánto cuesta Robin, pero hay una gran versión gratuita, por lo que si necesita un producto pago, puede probarlo (espero que solucionen el problema con la recuperación y las copias de seguridad pronto). De los tres gratuitos, tuve menos problemas con OpenEBS, pero su rendimiento no es un infierno. Es una pena, no guardé más resultados, pero espero que las cifras dadas y mis comentarios te ayuden.