¡Actualización!. En los comentarios, uno de los lectores sugirió probar (posiblemente, él mismo esté trabajando en ello), así que añadí una sección sobre esta solución. También escribí , porque el proceso es muy diferente al de los demás.
Si soy honesto, me rendí y renuncié a (al menos por ahora). Voy a usar . ¿Por qué? ¡Por el almacenamiento! ¿Quién podría imaginar que iba a estar lidiando más con el almacenamiento que con Kubernetes mismo? Estoy usando , porque es económico y el rendimiento es bueno, y desde el principio desplegué clústeres utilizando . No he probado los servicios gestionados de Kubernetes de Google/Amazon/Microsoft/DigitalOcean y otros, porque quería aprender yo mismo. Además, soy ahorrativo.
Así que sí, pasé un montón de tiempo tratando de decidir qué almacenamiento elegir mientras consideraba la posible pila en Kubernetes. Prefiero soluciones de código abierto, no solo por el precio, sino que investigué un par de opciones de pago por curiosidad, porque tienen versiones gratuitas con limitaciones. Anoté algunas cifras de las pruebas recientes al comparar diferentes opciones, y pueden interesar a aquellos que están explorando el almacenamiento en Kubernetes. Aunque personalmente ya he dicho adiós a Kubernetes. También quiero mencionar , que permite preparar volúmenes directamente en Hetzner Cloud, pero aún no lo he probado. He investigado sobre el almacenamiento definido por software en la nube, porque necesitaba replicación y la capacidad de conectar rápidamente volúmenes persistentes en cualquier nodo, especialmente en caso de fallos en los nodos y situaciones similares. Algunas soluciones ofrecen instantáneas en el tiempo y copias de seguridad fuera del sitio, lo cual es conveniente.
He probado de 6 a 7 soluciones de almacenamiento:
Como ya mencioné , tras probar la mayoría de las opciones de la lista, inicialmente me quedé con OpenEBS. OpenEBS es muy fácil de instalar y usar, pero, si soy honesto, después de las pruebas con datos reales bajo carga, su rendimiento me decepcionó. Es de código abierto, y los desarrolladores en su Siempre me ayudaron mucho cuando necesitaba asistencia. Desafortunadamente, su rendimiento es muy bajo en comparación con otras opciones, por lo que tuve que realizar las pruebas nuevamente. Actualmente, OpenEBS tiene 3 motores de almacenamiento, pero estoy publicando los resultados del benchmark para cStor. Hasta ahora no tengo cifras para Jiva y LocalPV.
En pocas palabras, Jiva es un poco más rápido, y LocalPV es realmente rápido, no peor que el benchmark de disco directo. El problema con LocalPV es que solo se puede acceder a él en el nodo donde fue creado, y no hay replicación en absoluto. Tuve algunos problemas para restaurar una copia de seguridad a través de en un nuevo clúster, porque los nombres de los nodos eran diferentes. Hablando de copias de seguridad, cStor tiene , que permite hacer copias de seguridad fuera del sitio de instantáneas puntuales, lo cual es más conveniente que las copias de seguridad a nivel de archivos con Velero-Restic. Escribí , para facilitar la gestión de copias de seguridad y restauraciones con este plugin. En general, me gusta mucho OpenEBS, pero su rendimiento...
Rook también tiene código abierto, y se diferencia de las otras opciones en la lista por ser un orquestador de almacenamiento que realiza tareas complejas de gestión de almacenamiento con diferentes backends, como , y otros, lo que simplifica significativamente el trabajo. Tuve problemas con EdgeFS cuando lo probé hace unos meses, así que principalmente hice pruebas con Ceph. Ceph no solo ofrece almacenamiento de bloques, sino también almacenamiento de objetos compatible con S3/Swift y un sistema de archivos distribuido. Lo que me gusta de Ceph es la posibilidad de distribuir los datos de un volumen en varios discos, para que el volumen pueda utilizar más espacio en disco del que cabe en un solo disco. Esto es conveniente. Otra función genial es que, al agregar discos al clúster, automáticamente redistribuye los datos por todos los discos.
En Ceph hay instantáneas, pero, hasta donde sé, no se pueden usar directamente en Rook/Kubernetes. Aunque no he ahondado mucho en esto. Además, no hay copias de seguridad fuera del sitio, así que habrá que usar algo como Velero/Restic, pero ahí solo hay copias de seguridad a nivel de archivos, no instantáneas en un momento dado. Sin embargo, me gustó mucho lo sencillo que es trabajar con Ceph en Rook; oculta casi todas las cosas complicadas y ofrece herramientas para interactuar directamente con Ceph para solucionar problemas. Desafortunadamente, en las pruebas de estrés de los volúmenes de Ceph, siempre me surgió , que hace que Ceph se vuelva inestable. Aún no está claro si esto es un error en Ceph mismo o un problema con cómo Rook maneja Ceph. He estado jugando con la configuración de memoria, y ha mejorado un poco, pero el problema no se ha resuelto por completo. Ceph tiene un buen rendimiento, como se puede ver en los benchmarks más abajo. Además, tiene un buen panel de monitoreo.
Me gusta mucho Longhorn. Creo que es una solución prometedora. Sin embargo, los propios desarrolladores (Rancher Labs) reconocen que no es adecuado para entornos de producción todavía, y eso es evidente. Tiene código abierto y un buen rendimiento (aunque aún no han hecho optimizaciones), pero los volúmenes tardan mucho en conectarse al pod, y en los peores casos esto puede tardar de 15 a 16 minutos, especialmente después de restaurar una gran copia de seguridad 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, así que aún necesitarás algo como Velero para respaldar los demás recursos. Las copias de seguridad y restauraciones son muy confiables, pero increíblemente lentas. En serio, son absurdamente lentas. El uso de recursos del procesador y la carga del sistema a menudo aumentan al trabajar con un volumen de datos medio en Longhorn. Hay un panel de monitoreo cómodo para gestionar Longhorn. Ya he mencionado que me gusta Longhorn, pero necesita un trabajo adecuado.
StorageOS es el primer producto de pago en la lista. Tiene una versión para desarrolladores con un tamaño de almacenamiento gestionado limitado a 500 GB, pero el número de nodos, me parece, no está limitado. En el departamento de ventas me dijeron que el costo comienza desde $125 al mes por 1 TB, si recuerdo correctamente. Hay un panel de monitoreo básico y una CLI conveniente, pero la productividad resulta bastante extraña: en algunas pruebas de referencia es bastante aceptable, pero en la prueba de estrés de volúmenes, la velocidad no me gustó en absoluto. En general, no sé qué decir. Por lo tanto, no me he metido mucho en ello. Aquí no hay copias de seguridad fuera del sitio y también tendré que usar Velero con Restic para respaldar los volúmenes. Es extraño, considerando que el producto es de pago. Además, los desarrolladores no estaban muy interesados en comunicarse por Slack.
Conocí a Robin en Reddit a través de su director técnico. Antes no había oído hablar de él. Tal vez porque buscaba soluciones gratuitas y Robin es de pago. Tienen una versión gratuita bastante generosa con 10 TB de almacenamiento y tres nodos. En general, el producto es bastante bueno y tiene características agradables. Tiene una excelente CLI, pero lo más impresionante es que se puede hacer un snapshot y backup de toda la aplicación (en el selector de recursos se llama lanzamientos de Helm o «flex apps»), incluyendo volúmenes y otros recursos, por lo que se puede prescindir de Velero. Y todo sería maravilloso si no fuera por un pequeño detalle: cuando se restaura (o «importa», como se llama en Robin) una aplicación en un nuevo clúster, por ejemplo, en caso de recuperación después de un desastre, la recuperación, por supuesto, funciona, pero no se puede continuar con el backup de la aplicación. En esta versión simplemente es imposible, y los desarrolladores lo han confirmado. Esto es, por decirlo de alguna manera, extraño, especialmente considerando las demás ventajas (por ejemplo, copias de seguridad y recuperaciones increíblemente rápidas). Los desarrolladores prometen solucionarlo para la próxima versión. El rendimiento, en general, es bueno, pero noté una rareza: si se ejecuta un benchmark directamente en el volumen conectado al host, la velocidad de lectura es mucho más alta que en el mismo volumen desde dentro del pod. Todos los demás resultados son idénticos, pero en teoría no debería haber diferencia. Aunque están trabajando en ello, estoy decepcionado por el problema de recuperación y backup; me parecía que finalmente había encontrado la solución adecuada, y estaba incluso dispuesto a pagar por ella cuando necesitaría más espacio o más servidores.
No tengo mucho que decir al respecto. Es un producto de pago, igualmente excelente y caro. El rendimiento es simplemente increíble. Hasta ahora, es el mejor indicador. En Slack me dijeron que el precio comienza en $205 al mes por nodo, como se indica en el GKE Marketplace de Google. No sé si será más barato si se compra directamente. De todos modos, no puedo permitirme eso, así que me sentí muy, muy decepcionado de que la licencia de desarrollador (hasta 1 TB y 3 nodos) sea prácticamente inútil con Kubernetes, a menos que estés satisfecho con una preparación estática. Esperaba que la licencia empresarial se convirtiera automáticamente en una licencia de desarrollador al final del período de prueba, pero eso no sucedió. 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 software de código abierto, pero si tuviera el dinero, definitivamente elegiría Portworx. Hasta ahora, su rendimiento no se compara con otras opciones.
Agregué esta sección ya después de publicar el post, cuando un lector sugirió probar Linstor. Lo intenté y me gustó. Pero aún hay que investigar más. En este momento, puedo decir que el rendimiento es bastante bueno (los resultados del benchmark se agregan más abajo). En esencia, obtuve el mismo rendimiento que al usar un disco directamente, sin apenas inconvenientes. (No pregunte por qué los números de Portworx son mejores que el benchmark del disco directamente. No tengo idea. Tal vez magia). Así que, por ahora, Linstor parece ser muy eficiente. La instalación no es complicada, pero tampoco es tan fácil como otras opciones. Primero tuve que instalar Linstor (el módulo del núcleo y herramientas/servicios) y configurar LVM para thin provisioning y soporte de snapshots fuera de Kubernetes, directamente en el host, y luego crear los recursos necesarios para usar el almacenamiento desde Kubernetes. No me gustó que no funcionara en CentOS y que tuviera que usar Ubuntu. No es un gran problema, pero resulta algo molesto, porque en la documentación (que, por cierto, es excelente) se mencionan varios paquetes que no se pueden encontrar en los repositorios especificados de Epel. Linstor tiene snapshots, pero no backups off-site, así que de nuevo tuve que usar Velero con Restic para hacer backup de los volúmenes. Preferiría tener snapshots en lugar de backups a nivel de archivos, pero se puede tolerar si la solución es eficiente y confiable. Linstor es de código abierto, pero hay soporte de pago. Si entiendo correctamente, se puede usar sin restricciones, incluso si no tiene un contrato de soporte, pero eso debe confirmarse. No sé cuánto se ha validado Linstor para Kubernetes, pero el nivel de almacenamiento está fuera de Kubernetes y, al parecer, la solución no apareció de la noche a la mañana, por lo que probablemente ya ha sido comprobada en condiciones reales. ¿Hay alguna solución aquí que me haga reconsiderar y regresar a Kubernetes? No lo sé, no lo sé. Necesito investigar más, estudiar la replicación. Veremos. Pero la primera impresión es buena. Definitivamente preferiría usar mis propios clústeres de Kubernetes en lugar de Heroku para tener más libertad y aprender algo nuevo. Dado que Linstor no se instala tan fácilmente como otros, pronto escribiré sobre esto.
Benchmarks
Lamentablemente, he guardado pocas notas sobre la comparación porque no pensé que escribiría sobre esto. Solo tengo resultados de pruebas básicas de fio y solo para clústeres con un solo nodo, así que no tengo cifras para las configuraciones replicadas. Pero a partir de estos resultados, se puede obtener una idea aproximada de lo que se puede esperar de cada opción, ya que 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 en prueba. Realicé las pruebas tres veces para cada solución y calculé el promedio, además de reiniciar la configuración del servidor para cada producto. Todo esto es completamente no científico, solo para que tengan una idea general. En otras pruebas, copié 38 GB de fotos y videos desde un volumen y hacia un volumen, para probar la lectura y escritura, pero desgraciadamente no guardé las cifras. En resumen: Portworx fue mucho más rápido.
Para el benchmark de 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: 4Primero, creé un volumen con la clase de almacenamiento correspondiente y luego ejecuté la tarea con fio en segundo plano. Tomé 1 GB para estimar el rendimiento y no esperar demasiado tiempo. Aquí están los resultados:
He destacado el mejor valor para cada métrica en verde y el peor en rojo.
Conclusión
Como pueden ver, en la mayoría de los casos Portworx se desempeñó mejor que los demás. Pero para mí es costoso. No sé cuánto cuesta Robin, pero tiene una excelente versión gratuita, así que si necesitan un producto de pago, pueden probarlo (espero que pronto solucionen el problema de la recuperación y las copias de seguridad). De los tres gratuitos, tuve menos problemas con OpenEBS, pero su rendimiento deja mucho que desear. Lamentablemente, no guardé más resultados, pero espero que las cifras presentadas y mis comentarios les ayuden.
Fuente: habr.com
