Actualització!. Als comentaris, un dels lectors va suggerir provar-ho (potser ell mateix hi està treballant), així que he afegit una secció sobre aquesta solució. També vaig escriure , perquè el procés és molt diferent de la resta.
Per ser sincer, em vaig rendir i em vaig rendir (almenys de moment). faré servir . Per què? A causa de l'emmagatzematge! Qui hauria pensat que jugaria més amb l'emmagatzematge que amb el mateix Kubernetes. jo utilitzo perquè és barat i el rendiment és bo i des del principi he estat desplegant clústers utilitzant . No vaig provar els serveis gestionats de Kubernetes de Google/Amazon/Microsoft/DigitalOcean, etc., etc., perquè volia aprendre-ho tot jo mateix. També sóc frugal.
Així que sí, vaig passar molt de temps intentant decidir quin emmagatzematge triar quan estava avaluant una possible pila de Kubernetes. Prefereixo les solucions de codi obert, no només pel preu, sinó que he mirat un parell d'opcions de pagament per curiositat perquè tenen versions gratuïtes amb limitacions. He anotat alguns números de proves recents quan he comparat diferents opcions, i poden ser d'interès per a aquells que aprenen sobre l'emmagatzematge de Kubernetes. Encara que personalment m'he acomiadat de Kubernetes de moment. També vull esmentar , que pot subministrar directament volums Hetzner Cloud, però encara no ho he provat. Vaig mirar l'emmagatzematge definit per programari al núvol perquè necessitava replicació i la capacitat de muntar ràpidament volums persistents a qualsevol node, especialment en cas de fallades de nodes i altres situacions similars. Algunes solucions ofereixen instantànies puntuals i còpies de seguretat fora del lloc, cosa que és convenient.
Vaig provar 6-7 solucions d'emmagatzematge:
Com ja he dit Després d'haver provat la majoria de les opcions de la llista, inicialment em vaig establir per OpenEBS. OpenEBS és molt fàcil d'instal·lar i utilitzar, però per ser sincer, després de provar amb dades reals sota càrrega, em va decebre el seu rendiment. Això és de codi obert, i els desenvolupadors estan sols sempre molt útil quan necessitava ajuda. Malauradament, té un rendiment molt baix en comparació amb altres opcions, de manera que les proves s'han hagut de tornar a executar. Actualment, OpenEBS té 3 motors d'emmagatzematge, però estic publicant resultats de referència per a cStor. Encara no tinc números de Jiva i LocalPV.
En poques paraules, Jiva és una mica més ràpid i LocalPV és generalment ràpid, no pitjor que el punt de referència del disc directament. El problema amb LocalPV és que només es pot accedir al volum des del node on es va preparar i no hi ha cap replicació. Vaig tenir alguns problemes per restaurar una còpia de seguretat via en un clúster nou perquè els noms dels nodes eren diferents. Si parlem de còpies de seguretat, cStor en té , amb la qual podeu fer còpies de seguretat fora del lloc de les instantànies en un moment determinat, cosa que és més convenient que les còpies de seguretat a nivell de fitxer amb Velero-Restic. vaig escriure , per facilitar la gestió de còpies de seguretat i restauracions amb aquest connector. En general, m'agrada molt OpenEBS, però el seu rendiment...
Rook també és de codi obert i es diferencia de la resta d'opcions de la llista perquè és un orquestrador d'emmagatzematge que realitza tasques complexes de gestió d'emmagatzematge amb diferents backends, p. , i altres, que simplifica molt la feina. Vaig tenir problemes amb EfgeFS quan el vaig provar fa uns mesos, així que vaig provar principalment amb Ceph. Ceph no només ofereix emmagatzematge en blocs, sinó també emmagatzematge d'objectes compatible amb S3/Swift i el sistema de fitxers distribuït. El que m'agrada de Ceph és la capacitat de repartir dades de volum entre diversos discs perquè el volum pugui utilitzar més espai del disc del que hi pot cabre en un sol disc. És còmode. Una altra característica interessant és que quan afegiu discs a un clúster, redistribueix automàticament les dades a tots els discos.
Ceph té instantànies, però pel que jo sé, no es poden utilitzar directament a Rook/Kubernetes. És cert, no vaig aprofundir en això. Però no hi ha còpies de seguretat fora del lloc, de manera que haureu d'utilitzar alguna cosa amb Velero/Restic, però només hi ha còpies de seguretat a nivell de fitxer, no instantànies puntuals. El que em va agradar molt de Rook va ser el fàcil que és treballar amb Ceph: amaga gairebé totes les coses complicades i ofereix eines per parlar directament amb Ceph per resoldre problemes. Malauradament, durant la prova d'estrès dels volums Ceph, vaig seguir tenint problemes , que fa que Ceph es torni inestable. Encara no està clar si es tracta d'un error al mateix Ceph o d'un problema en la manera com Rook gestiona Ceph. Vaig modificar la configuració de la memòria i va millorar, però el problema no es va resoldre completament. Ceph té un rendiment decent, com podeu veure als punts de referència a continuació. També té un bon quadre de comandament.
M'agrada molt Longhorn. Al meu entendre, aquesta és una solució prometedora. És cert que els mateixos desenvolupadors (Rancher Labs) admeten que encara no és adequat per a l'entorn de treball, i això es demostra. És de codi obert i té un rendiment decent (tot i que encara no l'han optimitzat), però els volums triguen molt a connectar-se al pod, i en el pitjor dels casos triguen entre 15 i 16 minuts, sobretot després de restaurar una còpia de seguretat gran o actualització de la càrrega de treball. Té instantànies i còpies de seguretat fora del lloc d'aquestes instantànies, però només s'apliquen als volums, de manera que encara necessitareu alguna cosa com Velero per fer una còpia de seguretat d'altres recursos. Les còpies de seguretat i les restauracions són molt fiables, però indecentment lentes. De debò, increïblement lent. L'ús de la CPU i la càrrega del sistema sovint augmenten quan es treballa amb una quantitat mitjana de dades a Longhorn. Hi ha un tauler de control convenient per gestionar Longhorn. Ja he dit que m'agrada Longhorn, però necessita una mica de feina.
StorageOS és el primer producte de pagament de la llista. Té una versió per a desenvolupadors amb una mida limitada d'emmagatzematge gestionat de 500 GB, però no crec que hi hagi un límit en el nombre de nodes. El departament de vendes em va dir que el cost comença a partir de 125 dòlars al mes per 1 TB, si no recordo malament. Hi ha un tauler bàsic i una CLI convenient, però alguna cosa estranya està passant amb el rendiment: en alguns punts de referència és força decent, però a la prova d'esforç de volum no m'ha agradat gens la velocitat. En general, no sé què dir. Així que realment no entenia gaire. Aquí no hi ha còpies de seguretat fora del lloc i també haureu d'utilitzar Velero amb Restic per fer còpies de seguretat dels volums. És estrany, perquè el producte es paga. I els desenvolupadors no tenien ganes de comunicar-se a Slack.
Vaig saber sobre Robin a Reddit pel seu director tècnic. Mai havia sentit a parlar d'ell abans. Potser perquè buscava solucions gratuïtes, però en Robin està de pagament. Tenen una versió gratuïta força generosa amb 10 TB d'emmagatzematge i tres nodes. En general, el producte és bastant decent i té bones característiques. Hi ha una CLI fantàstica, però el millor és que podeu capturar i fer una còpia de seguretat de tota l'aplicació (al selector de recursos això s'anomena llançaments Helm o "aplicacions flexibles"), inclosos els volums i altres recursos, de manera que podeu prescindir de Velero. I tot seria meravellós si no fos per un petit detall: si restaureu (o "importeu", com s'anomena a Robin) una aplicació en un clúster nou, per exemple, en cas de recuperació d'un desastre, la restauració, per descomptat, funciona, però continuar fent una còpia de seguretat de l'aplicació està prohibit. Això simplement no és possible en aquesta versió, tal com han confirmat els desenvolupadors. Això és, per dir-ho suaument, estrany, sobretot tenint en compte els altres avantatges (per exemple, còpies de seguretat i restauracions increïblement ràpides). Els desenvolupadors prometen arreglar-ho tot abans de la propera versió. En general, el rendiment és bo, però he notat una curiositat: si executo el benchmark directament en un volum connectat a l'amfitrió, la velocitat de lectura és molt més ràpida que executar el mateix volum des del pod. Tots els altres resultats són idèntics, però en teoria no hi hauria d'haver cap diferència. Tot i que hi estan treballant, em va molestar el problema amb la restauració i la còpia de seguretat: vaig pensar que finalment havia trobat una solució adequada i fins i tot estava disposat a pagar-ho quan necessités més espai o més servidors.
Aquí no tinc gaire a dir. Aquest és un producte de pagament, igual de genial i car. L'actuació és senzillament increïble. Aquest és el millor indicador fins ara. Slack em va dir que el preu comença a partir de 205 dòlars al mes per node, tal com es mostra al GKE Marketplace de Google. No sé si et sortirà més barat si compres directament. No em puc permetre això de totes maneres, així que em va decebre molt i molt que la llicència de desenvolupador (fins a 1 TB i 3 nodes) sigui pràcticament inútil amb Kubernetes tret que us conformeu amb el subministrament estàtic. Esperava que la llicència per volum es reduís automàticament a desenvolupador al final del període de prova, però això no va passar. La llicència de desenvolupador només es pot utilitzar directament amb Docker i la configuració a Kubernetes és molt complicada i limitada. Per descomptat, prefereixo el codi obert, però si tingués els diners, definitivament triaria Portworx. Fins ara, el seu rendiment simplement no es compara amb altres opcions.
Vaig afegir aquesta secció després de la publicació de la publicació, quan un lector va suggerir provar Linstor. Ho vaig provar i em va agradar! Però encara hem d'aprofundir. Ara puc dir que el rendiment no és dolent (he afegit els resultats de referència a continuació). Essencialment, vaig obtenir el mateix rendiment que el disc directament, sense cap sobrecàrrega. (No us pregunteu per què Portworx té millors números que el punt de referència de la unitat directament. No en tinc ni idea. Màgia, suposo.) Així que Linstor sembla molt eficaç fins ara. No és tan difícil d'instal·lar, però no és tan fàcil com altres opcions. Primer vaig haver d'instal·lar Linstor (mòdul del nucli i eines/serveis) i configurar LVM per a l'aprovisionament prim i el suport d'instantànies fora de Kubernetes, directament a l'amfitrió, i després crear els recursos necessaris per utilitzar l'emmagatzematge des de Kubernetes. No em va agradar que no funcionés a CentOS i vaig haver d'utilitzar Ubuntu. No és terrible, és clar, però una mica molest, perquè la documentació (que és excel·lent, per cert) esmenta diversos paquets que no es poden trobar als repositoris Epel especificats. Linstor té instantànies, però no còpies de seguretat fora del lloc, així que aquí de nou vaig haver d'utilitzar Velero amb Restic per fer còpies de seguretat de volums. Preferiria les instantànies en lloc de les còpies de seguretat a nivell de fitxer, però això es pot tolerar si la solució és eficient i fiable. Linstor és de codi obert, però té suport de pagament. Si ho entenc bé, es pot utilitzar sense restriccions, encara que no tinguis un contracte de suport, però això s'ha d'aclarir. No sé com està provat Linstor per a Kubernetes, però la capa d'emmagatzematge en si es troba fora de Kubernetes i, pel que sembla, la solució no va aparèixer ahir, de manera que probablement ja s'ha provat en condicions reals. Hi ha alguna solució aquí que em faci canviar d'opinió i tornar a Kubernetes? No ho sé. Encara hem d'aprofundir i estudiar la replicació. A veure. Però la primera impressió és bona. Definitivament preferiria utilitzar els meus propis clústers de Kubernetes en comptes d'Heroku per tenir més llibertat i aprendre coses noves. Com que Linstor no és tan fàcil d'instal·lar com d'altres, aviat escriuré una publicació sobre això.
Punts de referència
Malauradament, no vaig guardar moltes notes sobre la comparació perquè no pensava que n'escriuria. Només tinc resultats dels punts de referència bàsics de fio i només per a clústers d'un sol node, així que encara no tinc números per a configuracions replicades. Però a partir d'aquests resultats podeu fer-vos una idea aproximada de què esperar de cada opció, perquè els vaig comparar en els mateixos servidors en núvol, 4 nuclis, 16 GB de RAM, amb un disc addicional de 100 GB per als volums provats. Vaig executar els punts de referència tres vegades per a cada solució i vaig calcular el resultat mitjà, a més de restablir la configuració del servidor per a cada producte. Tot això és completament poc científic, només per donar-vos una idea general. En altres proves, vaig copiar 38 GB de fotos i vídeos del volum per provar la lectura i l'escriptura, però, per desgràcia, no vaig guardar els números. En resum: Portworkx va ser molt més ràpid.
Per a la referència de volum he utilitzat aquest manifest:
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: 4Primer vaig crear un volum amb la classe d'emmagatzematge adequada i després vaig executar el treball amb fio entre bastidors. Vaig trigar 1 GB per estimar el rendiment i no esperar massa. Aquests són els resultats:
He destacat el millor valor per a cada mètrica en verd i el pitjor en vermell.
Conclusió
Com podeu veure, en la majoria dels casos Portworx va funcionar millor que altres. Però per a mi és car. No sé quant costa Robin, però tenen una gran versió gratuïta, així que si voleu un producte de pagament, podeu provar-lo (esperem que solucionin el problema amb la restauració i les còpies de seguretat aviat). De les tres gratuïtes, vaig tenir menys problemes amb OpenEBS, però el seu rendiment és abismal. És una llàstima no haver guardat més resultats, però espero que els números i els meus comentaris us ajudin.
Font: www.habr.com