¡Actualizar!. En los comentarios, uno de los lectores sugirió probar (tal vez él mismo esté trabajando en ello), así que he agregado una sección sobre esa solución. yo tambien escribi porque el proceso es muy diferente al resto.
Para ser honesto, me di por vencido y me di por vencido (por ahora). usaré . ¿Por qué? ¡Por el almacenamiento! ¿Quién hubiera pensado que estaría jugando con el almacenamiento más que con el propio Kubernetes? yo suelo , porque es económico y el rendimiento es bueno, y desde el principio implementé clústeres con . No he probado los servicios administrados de Kubernetes de Google/Amazon/Microsoft/DigitalOcean, etc., etc., porque quería aprender todo yo mismo. Yo también soy frugal.
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 miré un par de opciones pagas por curiosidad, porque tienen versiones gratuitas con restricciones. Anoté algunos números de puntos de referencia recientes cuando estaba comparando diferentes opciones, y pueden ser de interés para aquellos que estudian el almacenamiento en Kubernetes. Aunque personalmente me he despedido de Kubernetes hasta ahora. también quiero mencionar , en el que puedes aprovisionar directamente los volúmenes de Hetzner Cloud, pero aún no lo he probado. Estaba investigando el almacenamiento definido por software en la nube porque necesitaba la replicación y la capacidad de montar rápidamente volúmenes persistentes en cualquier nodo, especialmente en caso de fallas del nodo y otras situaciones similares. Algunas soluciones ofrecen instantáneas de un punto en el tiempo y copias de seguridad fuera del sitio, lo cual es útil.
Probé 6-7 soluciones de almacenamiento:
Como ya dije , habiendo probado la mayoría de las opciones de 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ó. Esto es de código abierto, y los desarrolladores están solos. siempre muy útil cuando necesitaba ayuda. Desafortunadamente, tiene un rendimiento muy bajo en comparación con otras opciones, por lo que tuve que realizar las pruebas nuevamente. En este momento, OpenEBS tiene 3 motores de almacenamiento, pero estoy publicando resultados de referencia para cStor. Todavía no tengo números para Jiva y LocalPV.
En pocas palabras, Jiva es un poco más rápido y LocalPV es generalmente rápido, no peor que el punto de referencia de la unidad directamente. El problema con LocalPV es que solo se puede acceder al volumen en el nodo donde se aprovisionó y no hay replicación en absoluto. Tuve algunos problemas con la restauración de una copia de seguridad a través de en el nuevo clúster porque los nombres de los nodos eran diferentes. Hablando de copias de seguridad, cStor tiene , con el que puede realizar copias de seguridad de instantáneas en un momento dado fuera del sitio, lo cual es más conveniente que las copias de seguridad a nivel de archivo con Velero-Restic. escribí para facilitar la gestión de copias de seguridad y restauraciones con este complemento. En general, me gusta mucho OpenEBS, pero su rendimiento...
Rook también es de código abierto y se diferencia del resto de opciones de la lista en que es un orquestador de almacenamiento que realiza tareas complejas de administración de almacenamiento con diferentes backends, por ejemplo , y otros, lo que simplifica mucho el trabajo. Tuve problemas con EfgeFS cuando lo probé hace unos meses, así que probé principalmente con Ceph. Ceph no solo ofrece 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 en varios discos para que el volumen pueda usar más espacio en disco del que cabe en un disco. Es cómodo. Otra característica interesante es que cuando agrega discos al clúster, redistribuye automáticamente los datos en todos los discos.
Ceph tiene instantáneas, pero que yo sepa, no se pueden usar directamente en Rook/Kubernetes. Es cierto que no profundicé en eso. Pero no hay copias de seguridad fuera del sitio, por lo que debe usar algo con Velero / Restic, pero solo hay copias de seguridad a nivel de archivo, no instantáneas de un momento dado. Sin embargo, lo que realmente me gusta de Rook es la facilidad de trabajar con Ceph: oculta casi todas las cosas complejas y ofrece herramientas para hablar directamente con Ceph para solucionar problemas. Desafortunadamente, en la prueba de estrés de los volúmenes de Ceph, siempre tuve , lo que hace que Ceph se vuelva inestable. Todavía no está claro si se trata de un error en Ceph o de un problema en la forma en que Rook administra Ceph. Jugué con la configuración de la memoria y mejoró, pero el problema no se resolvió por completo. Ceph tiene un buen rendimiento como se ve en los puntos de referencia a continuación. También tiene un buen tablero de instrumentos.
Me gusta mucho Longhorn. Creo que esta es una solución prometedora. Es cierto que los propios desarrolladores (Rancher Labs) admiten que aún no es adecuado para un entorno de producción, y esto se nota. Es de código abierto y tiene un rendimiento decente (aunque aún no lo han optimizado), pero los volúmenes tardan mucho en adjuntarse al módulo 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 una carga de trabajo. Tiene instantáneas y copias de seguridad fuera del sitio de esas instantáneas, pero solo se aplican a los volúmenes, por lo que aún necesita algo como Velero para hacer una copia de seguridad del resto de los recursos. Las copias de seguridad y las restauraciones son muy confiables, pero indecentemente lentas. En serio, prohibitivamente lento. El uso de la CPU y la carga del sistema a menudo aumentan cuando se trabaja con una cantidad promedio de datos en Longhorn. Hay un tablero útil para administrar Longhorn. Ya dije que me gusta Longhorn, pero debe trabajarse adecuadamente.
StorageOS es el primer producto de pago de la lista. Tiene una versión para desarrolladores con un tamaño de almacenamiento administrado limitado de 500 GB, pero no creo que haya un límite en la cantidad de nodos. El departamento de ventas me dijo que el costo comienza en $125 por mes por 1 TB, si mal no recuerdo. Hay un tablero básico y un CLI práctico, pero algo extraño está pasando con el rendimiento: en algunos puntos de referencia es bastante decente, pero en la prueba de estrés de volúmenes, no me gustó la velocidad en absoluto. En general, no sé qué decir. Así que realmente no entendí. Aquí 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 raro, porque el producto es de pago. Y los desarrolladores no estaban ansiosos por comunicarse en Slack.
Aprendí sobre Robin en Reddit de su CTO. Nunca había oído hablar de él antes. Tal vez porque estaba buscando soluciones gratuitas, y a Robin se le paga. 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 excelente CLI, pero lo mejor es que puede hacer una instantánea y hacer una copia de seguridad de toda la aplicación (llamadas versiones de Helm o "aplicaciones flexibles" en el selector de recursos), incluidos los volúmenes y otros recursos, para que pueda prescindir de Velero. Y todo sería maravilloso si no fuera por un pequeño detalle: si restaura (o "importa", como se llama en Robin) una aplicación en un nuevo clúster, por ejemplo, en el caso de una recuperación de desastres, la restauración de Por supuesto, funciona, pero continuar con la copia de seguridad de la aplicación está prohibido. En esta versión, esto simplemente no es posible y los desarrolladores lo han confirmado. Esto es extraño, por decir lo menos, especialmente cuando considera otras ventajas (por ejemplo, copias de seguridad y restauraciones increíblemente rápidas). Los desarrolladores prometen arreglar todo para la próxima versión. El rendimiento en general es bueno, pero noté algo extraño: si ejecuta el punto de referencia directamente en un volumen conectado al host, la velocidad de lectura es mucho mayor que en el mismo volumen, pero desde el interior del módulo. Todos los demás resultados son idénticos, pero en teoría no debería haber diferencia. Aunque están trabajando en ello, me frustré con el problema de la restauración y la copia de seguridad; me pareció que finalmente había encontrado una solución adecuada e incluso estaba dispuesto a pagarla cuando necesitaba más espacio o más servidores.
No tengo mucho que decir aquí. Este es un producto pagado, igualmente genial y caro. El rendimiento es simplemente increíble. Hasta ahora este es el mejor indicador. Slack me dijo que los precios comienzan en $ 205 por mes por nodo, como se indica en GKE Marketplace de Google. No sé si será más barato si compras directamente. De todos modos, no me lo puedo permitir, así que me decepcionó mucho que una licencia de desarrollador (hasta 1 TB y 3 nodos) sea prácticamente inútil con Kubernetes, a menos que esté satisfecho con el aprovisionamiento estático. Tenía la esperanza de que la licencia por volumen bajara automáticamente a 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 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 que se publicó la publicación, cuando un lector sugirió probar Linstor. Lo probé y me gustó! Pero todavía tienes que cavar. Ahora puedo decir que el rendimiento no es malo (los resultados de referencia se agregan a continuación). De hecho, obtuve el mismo rendimiento que con la unidad directamente, sin sobrecarga alguna. (No pregunte por qué los números de Portworx son mejores que el punto de referencia de la unidad directamente. No tengo idea. Magia, supongo). Así que Linstor parece muy efectivo hasta ahora. Instalarlo no es tan difícil, pero no tan fácil como otras opciones. Primero tuve que instalar Linstor (módulo kernel y herramientas/servicios) y configurar LVM para el aprovisionamiento delgado y la compatibilidad con instantáneas fuera de Kubernetes, directamente en el host, y luego crear los recursos necesarios para usar el almacenamiento de Kubernetes. No me gustó que no funcionara en CentOS y tuviera que usar Ubuntu. No es terrible, por supuesto, pero sí un poco molesto, porque la documentación (que, por cierto, es excelente) menciona varios paquetes que no se pueden encontrar en los repositorios de Epel especificados. Linstor tiene instantáneas, pero no copias de seguridad fuera del sitio, así que nuevamente tuve que usar Velero con Restic para hacer copias de seguridad de los volúmenes. Preferiría las instantáneas a las copias de seguridad a nivel de archivo, pero esto se puede tolerar si la solución es eficiente y confiable. Linstor es de código abierto pero tiene soporte pagado. Si entiendo bien, se puede usar sin restricciones, incluso si no tiene un contrato de soporte, pero esto debe aclararse. No sé cómo se prueba Linstor para Kubernetes, pero la capa de almacenamiento en sí está fuera de Kubernetes y, aparentemente, la solución no apareció ayer, por lo que probablemente ya esté probada en condiciones reales. ¿Hay alguna solución aquí que me haga cambiar de opinión y volver a Kubernetes? No lo sé. Todavía tenemos que profundizar más, estudiar la replicación. Vamos a ver. 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 cosas nuevas. Dado que Linstor no es tan fácil de instalar como otros, pronto escribiré una publicación al respecto.
Puntos de referencia
Desafortunadamente, guardé pocos registros de la comparación, porque no pensé que escribiría sobre eso. Solo tengo resultados de referencia de referencia fio y solo para clústeres de un solo nodo, por lo que aún no tengo números para configuraciones replicadas. Pero a partir de estos resultados puede hacerse una idea aproximada de qué esperar de cada opción, porque las 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 probados. 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 acientífico, solo para que lo entiendas en términos generales. En otras pruebas, copié 38 GB de fotos y videos del volumen y para probar lectura y escritura, pero, lamentablemente, no guardé los números. En resumen: Portworkx fue mucho más rápido.
Para el punto de referencia de volumen, 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 adecuada y luego ejecuté el trabajo con fio en segundo plano. Tomé 1 GB para estimar el rendimiento y no esperar demasiado. Aquí están los resultados:
He resaltado el mejor valor para cada métrica en verde y el peor en rojo.
Conclusión
Como puede ver, en la mayoría de los casos, Portworx funcionó mejor que otros. Pero para mi es caro. No sé cuánto cuesta Robin, pero hay una excelente versión gratuita, por lo que si necesita un producto pago, puede probarlo (espero que solucionen el problema con las restauraciones y las copias de seguridad pronto). De los tres gratuitos, he tenido la menor cantidad de problemas con OpenEBS, pero su rendimiento es pésimo. Lamento no haber guardado más resultados, pero espero que los números y mis comentarios te ayuden.
Fuente: habr.com