Update!. In de reacties stelde een van de lezers voor om het te proberen (misschien werkt hij er zelf aan), dus ik heb een sectie over deze oplossing toegevoegd. Ik schreef ook , omdat het proces heel anders is dan de rest.
Eerlijk gezegd gaf ik het op en gaf het op (tenminste voor nu). ik zal gebruiken . Waarom? Vanwege opslag! Wie had ooit gedacht dat ik meer aan storage zou sleutelen dan aan Kubernetes zelf. ik gebruik omdat het goedkoop is en de prestaties goed zijn en vanaf het allereerste begin heb ik clusters ingezet met behulp van . Ik heb de beheerde Kubernetes-services van Google/Amazon/Microsoft/DigitalOcean, enz., enz. niet geprobeerd, omdat ik alles zelf wilde leren. Ik ben ook zuinig.
Dus ja, ik heb veel tijd besteed aan het beslissen welke opslag ik moest kiezen toen ik een mogelijke Kubernetes-stack aan het evalueren was. Ik geef de voorkeur aan open source-oplossingen, niet alleen vanwege de prijs, maar ik heb uit nieuwsgierigheid een aantal betaalde opties bekeken omdat ze gratis versies hebben met beperkingen. Ik heb een aantal cijfers uit recente tests opgeschreven toen ik verschillende opties vergeleek, en deze kunnen interessant zijn voor degenen die meer te weten komen over Kubernetes-opslag. Al heb ik persoonlijk voorlopig afscheid genomen van Kubernetes. Ik wil het ook vermelden , waarmee Hetzner Cloud-volumes rechtstreeks kunnen worden ingericht, maar ik heb het nog niet geprobeerd. Ik heb gekeken naar door software gedefinieerde opslag in de cloud omdat ik replicatie nodig had en de mogelijkheid om snel persistente volumes op elk knooppunt te koppelen, vooral in het geval van knooppuntstoringen en andere soortgelijke situaties. Sommige oplossingen bieden point-in-time snapshots en externe back-ups, wat handig is.
Ik heb 6-7 opslagoplossingen getest:
Zoals ik al zei Nadat ik de meeste opties uit de lijst had getest, koos ik in eerste instantie voor OpenEBS. OpenEBS is heel eenvoudig te installeren en te gebruiken, maar om eerlijk te zijn, na het testen met echte gegevens onder belasting, was ik teleurgesteld over de prestaties. Dit is open source en de ontwikkelaars staan er alleen voor altijd erg behulpzaam als ik hulp nodig had. Helaas presteert het zeer slecht in vergelijking met andere opties, dus moesten de tests opnieuw worden uitgevoerd. OpenEBS heeft momenteel 3 opslagengines, maar ik post benchmarkresultaten voor cStor. Ik heb nog geen nummers voor Jiva en LocalPV.
Kortom, Jiva is iets sneller, en LocalPV is over het algemeen snel, niet slechter dan de schijfbenchmark direct. Het probleem met LocalPV is dat het volume alleen toegankelijk is op het knooppunt waarop het is voorbereid, en dat er helemaal geen replicatie plaatsvindt. Ik had wat problemen met het herstellen van een back-up via op een nieuw cluster omdat de knooppuntnamen anders waren. Als we het over back-ups hebben, heeft cStor dat gedaan , waarmee u op een bepaald moment off-site back-ups van snapshots kunt maken, wat handiger is dan back-ups op bestandsniveau met Velero-Restic. ik schreef , om het gemakkelijker te maken om back-ups en herstelbewerkingen te beheren met deze plug-in. Over het algemeen vind ik OpenEBS erg leuk, maar de prestaties ervan...
Rook is ook open source, en wat het onderscheidt van de rest van de opties op de lijst is dat het een opslagorkestrator is die complexe opslagbeheertaken afhandelt met verschillende backends, b.v. , en anderen, wat het werk enorm vereenvoudigt. Ik had problemen met EfgeFS toen ik het een paar maanden geleden probeerde, dus ik testte voornamelijk met Ceph. Ceph biedt niet alleen blokopslag, maar ook objectopslag die compatibel is met S3/Swift en gedistribueerd bestandssysteem. Wat ik leuk vind aan Ceph is de mogelijkheid om volumegegevens over meerdere schijven te verspreiden, zodat het volume meer schijfruimte kan gebruiken dan er op één schijf past. Het is comfortabel. Een andere leuke functie is dat wanneer u schijven aan een cluster toevoegt, de gegevens automatisch over alle schijven worden verdeeld.
Ceph heeft snapshots, maar voor zover ik weet kunnen deze niet direct in Rook/Kubernetes worden gebruikt. Toegegeven, ik ben hier niet diep op ingegaan. Maar er zijn geen externe back-ups, dus je zult iets met Velero/Restic moeten gebruiken, maar er zijn alleen back-ups op bestandsniveau, geen momentopnamen. Wat ik erg leuk vond aan Rook was hoe gemakkelijk het is om met Ceph te werken - het verbergt bijna alle ingewikkelde dingen en biedt tools om rechtstreeks met Ceph te praten voor het oplossen van problemen. Helaas bleef ik er tijdens de stresstest van Ceph-volumes problemen mee houden , waardoor Ceph onstabiel wordt. Het is nog niet duidelijk of dit een bug in Ceph zelf is of een probleem in de manier waarop Rook Ceph beheert. Ik heb aan de geheugeninstellingen gesleuteld en het werd beter, maar het probleem was niet helemaal opgelost. Ceph presteert behoorlijk, zoals je kunt zien in de onderstaande benchmarks. Het heeft ook een goed dashboard.
Ik vind Longhorn echt heel leuk. Naar mijn mening is dit een veelbelovende oplossing. Toegegeven, de ontwikkelaars zelf (Rancher Labs) geven toe dat het nog niet geschikt is voor de werkomgeving, en dat blijkt ook. Het is open source en levert behoorlijke prestaties (hoewel ze het nog niet hebben geoptimaliseerd), maar het duurt erg lang voordat de volumes verbinding maken met de pod, en in het ergste geval duurt het 15-16 minuten, vooral na het herstellen van een grote back-up of het opwaarderen van de werklast. Het heeft snapshots en externe back-ups van deze snapshots, maar deze zijn alleen van toepassing op volumes, dus je hebt nog steeds zoiets als Velero nodig om een back-up te maken van andere bronnen. Back-ups en herstelbewerkingen zijn zeer betrouwbaar, maar onfatsoenlijk traag. Serieus, gewoon ongelooflijk traag. CPU-gebruik en systeembelasting pieken vaak wanneer er met een gemiddelde hoeveelheid gegevens in Longhorn wordt gewerkt. Er is een handig dashboard om Longhorn te beheren. Ik heb al gezegd dat ik Longhorn leuk vind, maar er is wat werk aan.
StorageOS is het eerste betaalde product op de lijst. Het heeft een ontwikkelaarsversie met een beperkte beheerde opslaggrootte van 500 GB, maar ik denk niet dat er een limiet is aan het aantal knooppunten. De verkoopafdeling vertelde me dat de kosten beginnen bij $ 125 per maand voor 1 TB, als ik het me goed herinner. Er is een basisdashboard en een handige CLI, maar er is iets vreemds aan de hand met de prestaties: in sommige benchmarks is het behoorlijk behoorlijk, maar in de volumestresstest vond ik de snelheid helemaal niet leuk. Over het algemeen weet ik niet wat ik moet zeggen. Ik begreep er dus niet echt veel van. Er zijn hier geen externe back-ups en u zult ook Velero met Restic moeten gebruiken om back-ups van volumes te maken. Het is vreemd, omdat het product betaald is. En de ontwikkelaars wilden niet graag communiceren over Slack.
Ik hoorde over Robin op Reddit van hun technisch directeur. Ik had nog nooit van hem gehoord. Misschien omdat ik op zoek was naar gratis oplossingen, maar Robin wordt betaald. Ze hebben een behoorlijk genereuze gratis versie met 10 TB opslagruimte en drie knooppunten. Over het algemeen is het product behoorlijk behoorlijk en heeft het leuke functies. Er is een geweldige CLI, maar het coolste is dat je een momentopname en back-up kunt maken van de hele applicatie (in de bronnenkiezer wordt dit Helm-releases of "flex-apps" genoemd), inclusief volumes en andere bronnen, zodat je het zonder Velero kunt stellen. En alles zou geweldig zijn als er niet één klein detail was: als je een applicatie op een nieuw cluster herstelt (of “importeert”, zoals het in Robin wordt genoemd) - bijvoorbeeld in het geval van herstel na een ramp - de restauratie, werkt natuurlijk, maar doorgaan met het maken van back-ups van de applicatie is verboden. Dit is simpelweg niet mogelijk in deze release, zoals de ontwikkelaars hebben bevestigd. Dit is, op zijn zachtst gezegd, vreemd, vooral gezien de andere voordelen (bijvoorbeeld ongelooflijk snelle back-ups en herstelbewerkingen). De ontwikkelaars beloven alles in de volgende release op te lossen. De prestaties zijn over het algemeen goed, maar ik merkte een eigenaardigheid op: als ik de benchmark rechtstreeks uitvoer op een volume dat aan de host is gekoppeld, is de leessnelheid veel sneller dan wanneer ik hetzelfde volume vanuit de pod laat draaien. Alle andere resultaten zijn identiek, maar in theorie zou er geen verschil moeten zijn. Hoewel ze eraan werken, was ik boos over het probleem met herstel en back-up - ik dacht dat ik eindelijk een geschikte oplossing had gevonden, en ik was zelfs bereid ervoor te betalen als ik meer ruimte of meer servers nodig had.
Ik heb hier niet veel te zeggen. Dit is een betaald product, even cool en duur. De prestaties zijn gewoon geweldig. Dit is de beste indicator tot nu toe. Slack vertelde me dat de prijzen beginnen bij $ 205 per maand per node, zoals vermeld in de GKE Marketplace van Google. Ik weet niet of het goedkoper zal zijn als je rechtstreeks koopt. Dat kan ik me sowieso niet veroorloven, dus ik was heel erg teleurgesteld dat de ontwikkelaarslicentie (tot 1 TB en 3 knooppunten) praktisch nutteloos is met Kubernetes, tenzij je tevreden bent met statische provisioning. Ik hoopte dat de volumelicentie aan het einde van de proefperiode automatisch zou worden gedowngraded naar ontwikkelaar, maar dat gebeurde niet. De ontwikkelaarslicentie kan alleen rechtstreeks met Docker worden gebruikt en de configuratie in Kubernetes is erg omslachtig 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 eenvoudigweg niet te vergelijken met andere opties.
Ik heb dit gedeelte toegevoegd nadat het bericht was gepubliceerd, toen een lezer voorstelde om Linstor te proberen. Ik heb het geprobeerd en het beviel me! Maar ik moet er nog wat dieper in duiken. Voorlopig kan ik zeggen dat de prestaties behoorlijk goed zijn (ik heb de benchmarkresultaten hieronder toegevoegd). Sterker nog, ik behaalde dezelfde prestaties als met een directe schijfbenchmark, zonder enige overhead. (Vraag me niet waarom de cijfers van Portworx beter zijn dan die van de directe schijfbenchmark. Ik heb geen idee. Magie, denk ik.) Linstor lijkt tot nu toe dus erg effectief. De installatie is niet echt moeilijk, maar ook niet zo eenvoudig als andere opties. Eerst moest ik Linstor installeren (kernelmodule en tools/services) en LVM instellen voor thin provisioning en snapshot-ondersteuning buiten Kubernetes, direct op de host, en vervolgens de benodigde resources creëren om de opslag vanuit Kubernetes te gebruiken. Ik was niet blij dat het niet werkte op CentOS en moest gebruikmaken van UbuntuHet is natuurlijk geen ramp, maar wel een beetje vervelend omdat de documentatie (die overigens uitstekend is) verschillende pakketten noemt die niet beschikbaar zijn in de opgegeven Epel-repositories. Linstor heeft snapshots, maar geen off-site back-ups, dus moest ik Velero met Restic weer gebruiken voor volumeback-ups. Ik heb liever snapshots dan back-ups op bestandsniveau, maar dat is acceptabel als de oplossing goed presteert en betrouwbaar is. Linstor is open source, maar er is betaalde ondersteuning. Als ik het goed begrijp, kun je het onbeperkt gebruiken, zelfs zonder supportcontract, maar dat moet ik nog even navragen. Ik weet niet hoe goed Linstor getest is voor Kubernetes, maar de opslaglaag zelf bevindt zich buiten Kubernetes en het lijkt erop dat het al een tijdje bestaat, dus het is waarschijnlijk al getest in de praktijk. Is er een oplossing die me zou kunnen overtuigen om toch weer voor Kubernetes te kiezen? Ik weet het niet. Ik moet me nog wat verder verdiepen in replicatie. We zullen zien. Maar de eerste indruk is goed. Ik zou zeker liever mijn eigen Kubernetes-clusters gebruiken in plaats van Heroku, voor meer vrijheid en om nieuwe dingen te leren. Omdat Linstor niet zo makkelijk te installeren is als andere tools, zal ik daar binnenkort een blogpost over schrijven.
Benchmarks
Helaas heb ik niet veel aantekeningen bijgehouden over de vergelijking, omdat ik niet dacht dat ik erover zou schrijven. Ik heb alleen resultaten van de standaard fio-benchmarks en alleen voor clusters met één knooppunt, dus ik heb nog geen cijfers voor gerepliceerde configuraties. Maar uit deze resultaten kun je een globaal idee krijgen van wat je van elke optie kunt verwachten, omdat ik ze heb vergeleken op dezelfde cloudservers, 4 cores, 16 GB RAM, met een extra schijf van 100 GB voor de geteste volumes. Ik heb voor elke oplossing drie keer de benchmarks uitgevoerd en het gemiddelde resultaat berekend, en ik heb voor elk product de serverinstellingen opnieuw ingesteld. Dit is allemaal volkomen onwetenschappelijk, om je maar een algemeen idee te geven. Bij andere tests heb ik 38 GB aan foto's en video's uit het volume gekopieerd om het lezen en schrijven te testen, maar helaas heb ik de cijfers niet opgeslagen. Kortom: Portworkx was veel sneller.
Voor de volumebenchmark heb ik dit manifest gebruikt:
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: 4Ik heb eerst een volume met de juiste opslagklasse gemaakt en vervolgens de klus met fio achter de schermen uitgevoerd. Ik had 1 GB nodig om de prestaties te schatten en niet te lang te wachten. Hier zijn de resultaten:
Ik heb de beste waarde voor elke statistiek in het groen gemarkeerd en de slechtste in het rood.
Conclusie
Zoals u kunt zien presteerde Portworx in de meeste gevallen beter dan andere. Maar voor mij is het duur. Ik weet niet hoeveel Robin kost, maar ze hebben een geweldige gratis versie, dus als je een betaald product wilt, kun je het proberen (hopelijk lossen ze het probleem met herstel en back-ups snel op). Van de drie gratis versies had ik de minste problemen met OpenEBS, maar de prestaties zijn verschrikkelijk. Het is jammer dat ik niet meer resultaten heb opgeslagen, maar ik hoop dat de cijfers en mijn opmerkingen je zullen helpen.
Bron: www.habr.com
