Update!. In de comments stelde een van de lezers voor om te proberen (misschien werkt hij er zelf aan), dus heb ik een sectie over deze oplossing toegevoegd. Ook heb ik geschreven , omdat het proces sterk verschilt van de andere.
Om eerlijk te zijn, ik heb het opgegeven en ben gestopt met (althans, voorlopig). Ik ga gebruiken . Waarom? Vanwege opslag! Wie had gedacht dat ik meer tijd zou besteden aan opslag dan aan Kubernetes zelf. Ik gebruik , omdat het goedkoop is en de prestaties goed zijn, en vanaf het begin heb ik clusters uitgerold met . Ik heb geen beheerde Kubernetes-services van Google/Amazon/Microsoft/DigitalOcean en anderen geprobeerd, omdat ik alles zelf wilde leren. Bovendien ben ik zuinig.
Dus ja, ik heb veel tijd verspild met het proberen te beslissen welke opslag ik moest kiezen bij het overwegen van een mogelijke stack op Kubernetes. Ik geef de voorkeur aan oplossingen met open source, en niet alleen vanwege de prijs, maar ik heb een paar betaalde opties uitgeprobeerd uit nieuwsgierigheid, omdat ze gratis versies met beperkingen hebben. Ik heb een paar cijfers genoteerd uit recente tests toen ik verschillende opties vergeleek, en die kunnen interessant zijn voor degenen die opslag in Kubernetes onderzoeken. Hoewel ik persoonlijk tot nu toe afscheid heb genomen van Kubernetes. Ik wil ook vermelden , waarmee je rechtstreeks volumes van Hetzner Cloud kunt voorbereiden, maar ik heb het nog niet geprobeerd. Ik heb cloud-gebaseerde softwaregedefinieerde opslag onderzocht, omdat ik replicatie nodig had en de mogelijkheid om snel permanente volumes aan elke node te koppelen, vooral in geval van node-fouten en soortgelijke situaties. Sommige oplossingen bieden snapshots op een bepaald moment en offsite back-ups, wat handig is.
Ik heb 6-7 opslagoplossingen getest:
Zoals ik al zei , na de meeste opties uit de lijst te hebben getest, ben ik aanvankelijk bij OpenEBS gebleven. OpenEBS is heel eenvoudig te installeren en te gebruiken, maar eerlijk gezegd heeft de prestatie me teleurgesteld na tests met echte gegevens onder belasting. Het is open source, en de ontwikkelaars zijn op hun ze hebben me altijd zeer geholpen wanneer ik hulp nodig had. Helaas is de prestaties heel laag in vergelijking met andere opties, waardoor ik de tests opnieuw moest uitvoeren. Op dit moment heeft OpenEBS 3 opslag-engines, maar ik publiceer de benchmarkresultaten voor cStor. Tot nu toe heb ik geen cijfers voor Jiva en LocalPV.
In het kort, Jiva is iets sneller, terwijl LocalPV zelfs snel is, niet slechter dan de benchmark van de schijf rechtstreeks. Het probleem met LocalPV is dat toegang alleen mogelijk is op de node waar het is voorbereid, en er is helemaal geen replicatie. Ik had enkele problemen met het herstellen van een backup via op het nieuwe cluster, omdat de namen van de nodes anders waren. Wat backups betreft, cStor heeft , waarmee je off-site backups van snapshots in de tijd kunt maken, wat handiger is dan file-level backups met Velero-Restic. Ik heb geschreven , om het beheren van backups en herstel met deze plugin gemakkelijker te maken. Over het algemeen ben ik erg blij met OpenEBS, maar de prestaties...
Rook heeft ook open source code, en onderscheidt zich van de andere opties in de lijst omdat het een opslagorchestrator is die complexe opslagbeheertaken uitvoert met verschillende backends, zoals , en anderen, wat het werk aanzienlijk vergemakkelijkt. Ik had problemen met EdgeFS toen ik het een paar maanden geleden probeerde, dus ik heb voornamelijk getest met Ceph. Ceph biedt niet alleen block storage, maar ook object storage dat compatibel is met S3/Swift en een gedistribueerd bestandssysteem. Wat ik leuk vind aan Ceph, is de mogelijkheid om de gegevens van een volume over meerdere schijven te verspreiden, zodat het volume meer schijfruimte kan gebruiken dan op Ć©Ć©n schijf past. Dat is handig. Een andere geweldige functie is dat wanneer je schijven toevoegt aan het cluster, het automatisch de gegevens over alle schijven herverdeelt.
Ceph heeft snapshots, maar voor zover ik weet kunnen ze niet rechtstreeks gebruikt worden in Rook/Kubernetes. Ik heb me daar echter niet verder in verdiept. Off-site backups zijn er niet, dus je zult iets moeten gebruiken zoals Velero/Restic, maar zij maken alleen backups op bestandsniveau, geen snapshots op een bepaald moment. Wat ik wel fijn vind aan Rook, is dat het de complexe dingen van Ceph bijna volledig verbergt en tools biedt om direct met Ceph te communiceren voor probleemoplossing. Helaas had ik tijdens de stresstest van de Ceph-volumes voortdurend , waardoor Ceph onbetrouwbaar wordt. Het is nog onduidelijk of dit een bug in Ceph zelf is of een probleem met hoe Rook Ceph beheert. Ik heb wat met de geheugeneinstellungen gespeeld, en het ging beter, maar het probleem is nog niet volledig opgelost. Ceph heeft goede prestaties, zoals te zien is in de benchmarks hieronder. Ook heeft het een goed dashboard voor monitoring.
Ik ben echt enthousiast over Longhorn. Voor mijn gevoel is het een veelbelovende oplossing. De ontwikkelaars zelf (Rancher Labs) erkennen echter dat het momenteel niet geschikt is voor productieomgevingen, en dat is duidelijk. Het heeft open source-code en goede prestaties (hoewel ze daar nog niet aan de optimalisatie hebben gewerkt), maar volumes verbinden zich heel langzaam met de pod, en in de slechtste gevallen duurt dat 15-16 minuten, vooral na het herstel van een grote backup of het upgraden van de workload. Het heeft snapshots en off-site backups van die snapshots, maar deze zijn alleen van toepassing op volumes, dus je hebt nog steeds iets als Velero nodig om de rest van de middelen te back-uppen. Backups en herstellingen zijn zeer betrouwbaar, maar belachelijk langzaam. Serieus, gewoon echt te langzaam. Het gebruik van CPU-resources en systeembelasting stijgt vaak bij het werken met gemiddelde datahoeveelheden in Longhorn. Er is een handig dashboard om Longhorn te beheren. Ik heb al eerder gezegd dat ik Longhorn leuk vind, maar er moet nog wel flink aan gewerkt worden.
StorageOS is het eerste betaalde product op de lijst. Het heeft een ontwikkelaarsversie met een beperkte omvang van het beheerde opslagcapaciteit van 500 GB, maar het aantal knooppunten is vermoedelijk onbeperkt. In de verkoopafdeling zeiden ze dat de prijs begint bij $125 per maand voor 1 TB, als ik het me goed herinner. Er is een basispaneel voor monitoring en een gebruiksvriendelijke CLI, maar met de prestaties lijkt er iets vreemd aan de hand: in sommige benchmarks is het behoorlijk prima, maar bij de stresstest van de volumes was ik helemaal niet tevreden over de snelheid. Kortom, ik weet niet wat ik ervan moet denken. Daarom heb ik me er niet verder in verdiept. Er zijn geen off-site back-ups en je moet ook Velero met Restic gebruiken voor het back-uppen van volumes. Vreemd, want het product is immers betaald. Bovendien waren de ontwikkelaars niet erg bereid om via Slack te communiceren.
Ik hoorde over Robin op Reddit van hun technische directeur. Eerder had ik er nog nooit van gehoord. Misschien omdat ik naar gratis oplossingen zocht, terwijl Robin betaald is. Ze hebben een vrij genereuze gratis versie met 10 TB opslag en drie nodes. Over het algemeen is het product behoorlijk goed en heeft het leuke functies. Er is een geweldige CLI, maar het beste is dat je een snapshot en een backup van de hele applicatie kunt maken (in de resource selector worden deze 'Helm releases' of 'flex apps' genoemd), inclusief volumes en andere resources, waardoor je Velero kunt overslaan. En alles zou geweldig zijn, als het niet voor Ć©Ć©n klein detail was: als je een applicatie herstelt (of 'importeert', zoals het in Robin wordt genoemd) op een nieuwe cluster, bijvoorbeeld in het geval van een disaster recovery, werkt het herstel natuurlijk, maar je kunt de applicatieback-up niet voortzetten. In deze release is dat gewoon niet mogelijk, en de ontwikkelaars hebben dat bevestigd. Dat is, om het mild te zeggen, vreemd, vooral gezien de andere voordelen (zoals ongelooflijk snelle backups en herstel). De ontwikkelaars beloven alles te verhelpen voor de volgende release. De prestaties zijn over het algemeen goed, maar ik merkte iets vreemds op: als je een benchmark rechtstreeks op het volume dat aan de host is gekoppeld uitvoert, is de leessnelheid veel hoger dan bij hetzelfde volume van binnen de pod. Alle andere resultaten zijn identiek, maar theoretisch zou er geen verschil moeten zijn. Hoewel ze hieraan werken, was ik teleurgesteld over het probleem met herstel en backup ā het leek alsof ik eindelijk een geschikte oplossing had gevonden, en ik was zelfs bereid ervoor te betalen wanneer ik meer ruimte of meer servers nodig had.
Hier valt weinig te zeggen. Het is een betaald product, even fantastisch als duur. De prestaties zijn gewoonweg geweldig. Voorlopig is dit de beste score. In Slack werd me verteld dat de prijs begint bij $205 per maand per node, zoals aangegeven in de Google GKE Marketplace. Ik weet niet of het goedkoper is als je direct koopt. Hoe dan ook, ik kan me dat niet veroorloven, dus was ik heel erg teleurgesteld dat de ontwikkelaarslicentie (tot 1 TB en 3 nodes) praktisch nutteloos is met Kubernetes, tenzij je genoegen neemt met een statische opzet. Ik hoopte dat de bedrijfslicentie automatisch zou verlagen naar ontwikkelaar niveau aan het einde van de proefperiode, maar dat gebeurde niet. De ontwikkelaarslicentie kan alleen rechtstreeks met Docker worden gebruikt, en de configuratie in Kubernetes is heel ingewikkeld en beperkt. Natuurlijk geef ik de voorkeur aan open source, maar als ik het geld had, zou ik zeker voor Portworx kiezen. Tot nu toe zijn de prestaties gewoon niet te vergelijken met andere opties.
Ik heb dit gedeelte toegevoegd nadat ik het bericht had gepubliceerd, toen een lezer voorstelde om Linstor te proberen. Ik heb het geprobeerd en vond het leuk! Maar ik moet nog verder kijken. Op dit moment kan ik zeggen dat de prestaties behoorlijk zijn (de benchmarkresultaten heb ik hieronder toegevoegd). In wezen kreeg ik dezelfde prestaties als met de schijf direct, helemaal zonder kosten. (Vraag niet waarom de cijfers van Portworx beter zijn dan de benchmark van de schijf direct. Ik heb er geen idee van. Magie, denk ik.) Dus Linstor lijkt op dit moment erg efficiƫnt. Het installeren is niet echt moeilijk, maar ook niet zo eenvoudig als andere opties. Eerst moest ik Linstor installeren (kernelmodule en tools/diensten) en LVM configureren voor thin provisioning en ondersteuning van snapshots buiten Kubernetes, direct op de host, en toen moest ik de middelen aanmaken die nodig zijn om de opslag vanuit Kubernetes te gebruiken. Het stoort me dat het niet werkte op CentOS en dat ik Ubuntu moest gebruiken. Het is natuurlijk niet erg, maar het is een beetje frustrerend, omdat in de documentatie (die trouwens uitstekend is) enkele pakketten worden genoemd die niet te vinden zijn in de gespecificeerde Epel-repositories. Linstor heeft snapshots, maar geen offsite back-ups, dus hier moest ik weer Velero met Restic gebruiken voor het back-uppen van volumes. Ik zou liever snapshots hebben dan back-ups op bestandsniveau, maar dat is te verdragen als de oplossing snel en betrouwbaar is. Linstor heeft open source code, maar er is betaalde ondersteuning beschikbaar. Als ik het goed heb, kan het zonder beperkingen worden gebruikt, zelfs als je geen ondersteuningscontract hebt, maar dat moet worden bevestigd. Ik weet niet hoe goed Linstor getest is voor Kubernetes, maar het opslagniveau bevindt zich buiten Kubernetes en, gezien het feit dat de oplossing niet gister is ontstaan, is het waarschijnlijk al in de echte wereld getest. Is er hier een oplossing die me zou doen twijfelen en terug naar Kubernetes zou brengen? Ik weet het niet, ik weet het niet. Ik moet nog verder kijken en de replicatie bestuderen. We zullen zien. Maar de eerste indruk is goed. Ik zou zeker liever mijn eigen Kubernetes-clusters gebruiken in plaats van Heroku, zodat ik meer vrijheid krijg en iets nieuws leer. Aangezien Linstor niet zo eenvoudig te installeren is als de anderen, zal ik binnenkort een bericht hierover schrijven.
Benchmarks
Helaas heb ik weinig vergelijkingsgegevens opgeslagen, omdat ik er niet aan dacht om hierover te schrijven. Ik heb alleen de resultaten van basis-benchmarks van fio en alleen voor clusters met Ć©Ć©n knoop, dus voor gerepliceerde configuraties heb ik nog geen cijfers. Maar uit deze resultaten kan je een globaal idee krijgen van wat je van elke optie kunt verwachten, omdat ik ze op dezelfde cloudservers heb vergeleken, met 4 kernen, 16 GB RAM, met een extra schijf van 100 GB voor de te testen volumes. Ik heb de benchmarks drie keer voor elke oplossing uitgevoerd en het gemiddelde resultaat berekend, plus ik resette de serverinstellingen voor elk product. Dit is allesbehalve wetenschappelijk, gewoon zodat je een algemeen beeld hebt. In andere tests kopieerde ik 38 GB fotoās en videoās van het volume en op het volume, om lezen en schrijven te testen, maar helaas heb ik de cijfers niet bewaard. Kort gezegd: Portworkx was veel sneller.
Voor de volume benchmark gebruikte ik deze 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: 4Eerst creƫerde ik een volume met de juiste opslagklasse, en daarna startte ik de taak met fio op de achtergrond. Ik nam 1 GB om de prestaties in te schatten en niet te lang te hoeven wachten. Hier zijn de resultaten:
Ik heb de beste waarde voor elke metriek in het groen gemarkeerd, en de slechtste in het rood.
Conclusie
Zoals je kunt zien, heeft Portworx in de meeste gevallen het beste resultaat behaald. Maar voor mij is het duur. Ik weet niet hoeveel Robin kost, maar er is een uitstekende gratis versie, dus als je een betaald product nodig hebt, kun je dat proberen (ik hoop dat ze snel het probleem met herstel en back-ups oplossen). Van de drie gratis opties had ik de minste problemen met OpenEBS, maar de prestaties zijn hĆØĆ©l slecht. Jammer dat ik niet meer resultaten heb bewaard, maar hopelijk helpen de gegeven cijfers en mijn opmerkingen je verder.
Bron: habr.com
