Actualización!. Nos comentarios, un dos lectores suxeriu probalo (quizais el mesmo estea a traballar niso) así que engadín unha sección sobre esta solución. Eu tamén escribín , porque o proceso é moi diferente ao resto.
Para ser sincero, deime por vencido e dei por vencido (polo menos por agora). Vou usar . Por que? Por mor do almacenamento! Quen diría que xogaría máis co almacenamento que co propio Kubernetes. Eu uso porque é barato e o rendemento é bo e dende o principio fun despregando clusters usando . Non probei servizos de Kubernetes xestionados de Google/Amazon/Microsoft/DigitalOcean, etc., etc., porque quería aprender todo eu. Tamén son frugal.
Entón, si, pasei moito tempo intentando decidir que almacenamento escoller cando estaba avaliando unha posible pila de Kubernetes. Prefiro as solucións de código aberto, non só polo prezo, senón que busquei un par de opcións de pago por curiosidade porque teñen versións gratuítas con limitacións. Anotei algúns números de probas recentes cando comparei diferentes opcións, e poden ser de interese para aqueles que aprenden sobre o almacenamento de Kubernetes. Aínda que persoalmente despedínme de Kubernetes polo momento. Tamén quero mencionar , que pode proporcionar directamente volumes de Hetzner Cloud, pero aínda non o probei. Busquei o almacenamento definido por software na nube porque necesitaba replicación e a capacidade de montar rapidamente volumes persistentes en calquera nodo, especialmente en caso de fallos de nodos e outras situacións similares. Algunhas solucións ofrecen instantáneas puntuales e copias de seguridade fóra do sitio, o que é conveniente.
Probei 6-7 solucións de almacenamento:
Como xa dixen Despois de probar a maioría das opcións da lista, inicialmente decidín OpenEBS. OpenEBS é moi sinxelo de instalar e usar, pero para ser honesto, despois de probar con datos reais baixo carga, quedei decepcionado co seu rendemento. Isto é de código aberto e os desenvolvedores son por conta propia sempre moi útil cando necesitaba axuda. Desafortunadamente, ten un rendemento moi pobre en comparación con outras opcións, polo que houbo que repetir as probas. OpenEBS ten actualmente 3 motores de almacenamento, pero estou publicando resultados de referencia para cStor. Aínda non teño números para Jiva e LocalPV.
En poucas palabras, Jiva é un pouco máis rápido e LocalPV é xeralmente rápido, non peor que o benchmark do disco directamente. O problema con LocalPV é que só se pode acceder ao volume no nodo onde se preparou e non hai replicación en absoluto. Tiven algúns problemas ao restaurar unha copia de seguridade mediante nun clúster novo porque os nomes dos nodos eran diferentes. Se falamos de copias de seguridade, cStor ten , co que pode facer copias de seguridade fóra do sitio de instantáneas nun momento, o que é máis cómodo que as copias de seguridade a nivel de ficheiro con Velero-Restic. escribín , para facilitar a xestión de copias de seguridade e restauracións con este complemento. En xeral, gústame moito OpenEBS, pero o seu rendemento...
Rook tamén é de código aberto e difire do resto das opcións da lista en que é un orquestrador de almacenamento que realiza tarefas complexas de xestión de almacenamento con diferentes backends, p. ex. , e outros, o que simplifica moito o traballo. Tiven problemas con EfgeFS cando o probei hai uns meses, polo que probei principalmente con Ceph. Ceph non só ofrece almacenamento en bloque, senón tamén almacenamento de obxectos compatible con S3/Swift e o sistema de ficheiros distribuídos. O que me gusta de Ceph é a capacidade de espallar os datos de volume en varios discos para que o volume poida usar máis espazo no disco do que cabe nun só disco. É cómodo. Outra característica interesante é que cando engades discos a un clúster, este redistribúe automaticamente os datos en todos os discos.
Ceph ten instantáneas, pero que eu saiba, non se poden usar directamente en Rook/Kubernetes. É certo, non afondei nisto. Pero non hai copias de seguridade fóra do sitio, polo que terás que usar algo con Velero/Restic, pero só hai copias de seguridade a nivel de ficheiro, non instantáneas puntuales. O que me gustou moito de Rook foi o fácil que é traballar con Ceph: oculta case todas as cousas complicadas e ofrece ferramentas para falar directamente con Ceph para solucionar problemas. Desafortunadamente, durante a proba de esforzo dos volumes Ceph, seguín tendo problemas , o que fai que Ceph se volva inestable. Aínda non está claro se este é un erro no propio Ceph ou un problema na forma en que Rook xestiona Ceph. Retoquei a configuración da memoria e mellorou, pero o problema non se resolveu completamente. Ceph ten un rendemento decente, como podes ver nos puntos de referencia a continuación. Tamén ten un bo panel.
Gústame moito Longhorn. Na miña opinión, esta é unha solución prometedora. É certo, os propios desenvolvedores (Rancher Labs) admiten que aínda non é axeitado para o ambiente de traballo, e iso demostra. É de código aberto e ten un rendemento decente (aínda que aínda non o optimizaron), pero os volumes tardan moito en conectarse ao pod, e no peor dos casos tardan entre 15 e 16 minutos, especialmente despois de restaurar unha copia de seguridade grande ou actualizar a carga de traballo. Ten instantáneas e copias de seguridade fóra do sitio destas instantáneas, pero só se aplican aos volumes, polo que aínda necesitarás algo como Velero para facer copias de seguridade doutros recursos. As copias de seguridade e restauracións son moi fiables, pero indecentemente lentas. En serio, moi lento. O uso da CPU e a carga do sistema adoitan aumentar cando se traballa cunha cantidade media de datos en Longhorn. Hai un panel conveniente para xestionar Longhorn. Xa dixen que me gusta Longhorn, pero necesita algo de traballo.
StorageOS é o primeiro produto de pago da lista. Ten unha versión para desenvolvedores cun tamaño de almacenamento xestionado limitado de 500 GB, pero non creo que haxa un límite no número de nodos. O departamento de vendas díxome que o custo comeza en 125 dólares ao mes por 1 TB, se non recordo mal. Hai un panel básico e unha CLI conveniente, pero algo estraño está a suceder co rendemento: nalgúns puntos de referencia é bastante decente, pero na proba de esforzo de volume non me gustou nada a velocidade. En xeral, non sei que dicir. Entón non entendín moito. Non hai copias de seguranza fóra do sitio aquí e tamén terás que usar Velero con Restic para facer copias de seguridade dos volumes. É estraño, porque o produto está de pago. E os desenvolvedores non estaban ansiosos por comunicarse en Slack.
Aprendín sobre Robin en Reddit co seu director técnico. Nunca oíra falar del. Quizais porque buscaba solucións gratuítas, pero Robin é de pago. Teñen unha versión gratuíta bastante xenerosa con 10 TB de almacenamento e tres nodos. En xeral, o produto é bastante decente e ten boas características. Hai unha excelente CLI, pero o máis xenial é que podes facer unha instantánea e facer unha copia de seguridade de toda a aplicación (no selector de recursos chámase versións de Helm ou "aplicacións flexibles"), incluíndo volumes e outros recursos, para que poidas prescindir de Velero. E todo sería marabilloso se non fose por un pequeno detalle: se restauras (ou "importas", como se chama en Robin) unha aplicación nun novo clúster - por exemplo, en caso de recuperación dun desastre - a restauración, por suposto, funciona, pero seguir facendo unha copia de seguridade da aplicación está prohibido. Isto simplemente non é posible nesta versión, como confirmaron os desenvolvedores. Isto é, por dicilo suavemente, estraño, especialmente tendo en conta as outras vantaxes (por exemplo, copias de seguridade e restauracións incriblemente rápidas). Os desenvolvedores prometen arranxar todo na próxima versión. O rendemento é xeralmente bo, pero notei unha peculiaridade: se executo o benchmark directamente nun volume conectado ao host, a velocidade de lectura é moito máis rápida que executar o mesmo volume desde o pod. Todos os demais resultados son idénticos, pero en teoría non debería haber diferenzas. Aínda que están a traballar niso, estaba molesto polo problema coa restauración e a copia de seguridade: pensei que por fin atopara unha solución axeitada e incluso estaba disposto a pagar por iso cando necesitase máis espazo ou máis servidores.
Non teño moito que dicir aquí. Este é un produto de pago, igualmente xenial e caro. A actuación é simplemente incrible. Este é o mellor indicador ata agora. Slack díxome que os prezos comezan a partir de 205 dólares ao mes por nodo, segundo se indica no GKE Marketplace de Google. Non sei se será máis barato se compras directamente. De todos os xeitos non podo pagar iso, así que quedei moi, moi decepcionado porque a licenza de programador (ata 1 TB e 3 nodos) sexa practicamente inútil con Kubernetes a non ser que te conformes co aprovisionamento estático. Esperaba que a licenza de volume baixase automaticamente á versión de programador ao final do período de proba, pero iso non sucedeu. A licenza de programador só se pode usar directamente con Docker e a configuración en Kubernetes é moi complicada e limitada. Por suposto, prefiro o código aberto, pero se tivese diñeiro, definitivamente escollería Portworx. Ata agora, o seu rendemento simplemente non se compara con outras opcións.
Engadín esta sección despois da publicación da publicación, cando un lector suxeriu probar Linstor. Probeino e gustoume! Pero aínda temos que afondar. Agora podo dicir que o rendemento non é malo (engadín os resultados de referencia a continuación). Esencialmente, obtiven o mesmo rendemento que o disco directamente, sen sobrecarga. (Non pregunte por que Portworx ten números mellores que o benchmark da unidade directamente. Non teño nin idea. Maxia, supoño.) Polo que Linstor parece moi eficaz ata agora. Non é tan difícil de instalar, pero non é tan fácil como outras opcións. Primeiro tiven que instalar Linstor (módulo do núcleo e ferramentas/servizos) e configurar LVM para o aprovisionamento fino e soporte de instantáneas fóra de Kubernetes, directamente no host, e despois crear os recursos necesarios para usar o almacenamento de Kubernetes. Non me gustou que non funcionase en CentOS e tiven que usar Ubuntu. Non terrible, por suposto, pero un pouco molesto, porque a documentación (que é excelente, por certo) menciona varios paquetes que non se poden atopar nos repositorios de Epel especificados. Linstor ten instantáneas, pero non copias de seguridade fóra do sitio, así que aquí de novo tiven que usar Velero con Restic para facer copias de seguridade dos volumes. Preferiría instantáneas en lugar de copias de seguridade a nivel de ficheiro, pero isto pódese tolerar se a solución é eficiente e fiable. Linstor é de código aberto pero ten soporte de pago. Se entendo ben, pódese utilizar sen restricións, aínda que non teñas un contrato de soporte, pero hai que aclaralo. Non sei como está probado Linstor para Kubernetes, pero a propia capa de almacenamento está fóra de Kubernetes e, ao parecer, a solución non apareceu onte, polo que probablemente xa se probou en condicións reais. Hai algunha solución aquí que me faga cambiar de opinión e volver a Kubernetes? Eu non sei. Aínda temos que afondar e estudar a réplica. Vexamos. Pero a primeira impresión é boa. Definitivamente preferiría usar os meus propios clústeres de Kubernetes en lugar de Heroku para ter máis liberdade e aprender cousas novas. Xa que Linstor non é tan fácil de instalar como outros, escribirei unha publicación sobre el en breve.
Puntos de referencia
Desafortunadamente, non gardei moitas notas sobre a comparación porque non pensei que escribiría sobre ela. Só teño resultados dos benchmarks básicos de fio e só para clusters de nodos únicos, polo que aínda non teño números para configuracións replicadas. Pero a partir destes resultados pódese facer unha idea aproximada de que esperar de cada opción, porque os comparei nos mesmos servidores na nube, 4 núcleos, 16 GB de RAM, cun disco adicional de 100 GB para os volumes probados. Realicei os puntos de referencia tres veces para cada solución e calculei o resultado medio, ademais de restablecer a configuración do servidor para cada produto. Todo isto é completamente pouco científico, só para darche unha idea xeral. Noutras probas, copiei 38 GB de fotos e vídeos do volume para probar a lectura e a escritura, pero, por desgraza, non gardei os números. En resumo: Portworkx foi moito máis rápido.
Para a referencia de volume usei este manifesto:
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: 4Primeiro creei un volume coa clase de almacenamento adecuada e despois executei o traballo con fio entre bastidores. Tardei 1 GB en estimar o rendemento e non esperar demasiado. Aquí están os resultados:
Destaquei o mellor valor para cada métrica en verde e o peor en vermello.
Conclusión
Como podes ver, na maioría dos casos Portworx funcionou mellor que outros. Pero para min é caro. Non sei canto custa Robin, pero teñen unha gran versión gratuíta, así que se queres un produto de pago, podes probalo (esperemos que solucionen o problema coa restauración e as copias de seguridade en breve). Dos tres gratuítos, o que menos problemas tiven con OpenEBS, pero o seu rendemento é pésimo. É unha mágoa non gardar máis resultados, pero espero que os números e os meus comentarios vos axuden.
Fonte: www.habr.com