Oppdater!. I kommentarfeltet foreslo en av leserne å prøve (kanskje han jobber med det selv) så jeg har lagt til en del om denne løsningen. Jeg skrev også , fordi prosessen er veldig forskjellig fra resten.
For å være ærlig ga jeg opp og ga opp (i hvert fall for nå). jeg vil bruke . Hvorfor? På grunn av lagring! Hvem hadde trodd at jeg skulle fikle mer med lagring enn med Kubernetes selv. jeg bruker fordi det er billig og ytelsen er god, og helt fra begynnelsen har jeg distribuert klynger ved hjelp av . Jeg prøvde ikke administrerte Kubernetes-tjenester fra Google/Amazon/Microsoft/DigitalOcean, etc., etc., fordi jeg ønsket å lære alt selv. Jeg er også nøysom.
Så ja, jeg brukte mye tid på å prøve å bestemme hvilken lagring jeg skulle velge da jeg vurderte en mulig Kubernetes-stabel. Jeg foretrekker åpen kildekode-løsninger, ikke bare på grunn av prisen, men jeg har sett på et par betalte alternativer av nysgjerrighet fordi de har gratisversjoner med begrensninger. Jeg har notert ned noen tall fra nylige tester når jeg sammenlignet forskjellige alternativer, og de kan være av interesse for de som lærer om Kubernetes-lagring. Selv om jeg personlig har sagt farvel til Kubernetes foreløpig. Jeg vil også nevne , som direkte kan levere Hetzner Cloud-volumer, men jeg har ikke prøvd det ennå. Jeg så på skyprogramvaredefinert lagring fordi jeg trengte replikering og muligheten til raskt å montere vedvarende volumer på hvilken som helst node, spesielt i tilfelle nodefeil og andre lignende situasjoner. Noen løsninger tilbyr øyeblikksbilder og sikkerhetskopiering utenfor stedet, noe som er praktisk.
Jeg testet 6-7 lagringsløsninger:
Som jeg allerede sa Etter å ha testet de fleste alternativene fra listen, slo jeg meg til å begynne med på OpenEBS. OpenEBS er veldig enkelt å installere og bruke, men for å være ærlig, etter å ha testet med ekte data under belastning, var jeg skuffet over ytelsen. Dette er åpen kildekode, og utviklerne er på egenhånd alltid veldig hjelpsom når jeg trengte hjelp. Dessverre har den svært dårlig ytelse sammenlignet med andre alternativer, så testene måtte kjøres på nytt. OpenEBS har for øyeblikket 3 lagringsmotorer, men jeg legger ut referanseresultater for cStor. Jeg har ikke tall for Jiva og LocalPV ennå.
I et nøtteskall er Jiva litt raskere, og LocalPV er generelt rask, ikke dårligere enn diskbenchmark direkte. Problemet med LocalPV er at volumet kun kan nås på noden der det ble forberedt, og det er ingen replikering i det hele tatt. Jeg hadde noen problemer med å gjenopprette en sikkerhetskopi via på en ny klynge fordi nodenavnene var forskjellige. Hvis vi snakker om sikkerhetskopier, har cStor , som du kan lage off-site sikkerhetskopier av øyeblikksbilder på et tidspunkt, noe som er mer praktisk enn sikkerhetskopiering på filnivå med Velero-Restic. Jeg skrev , for å gjøre det enklere å administrere sikkerhetskopier og gjenopprettinger med denne plugin-modulen. Totalt sett liker jeg OpenEBS, men ytelsen...
Rook er også åpen kildekode og skiller seg fra resten av alternativene på listen ved at det er en lagringsorkestrator som utfører komplekse lagringsadministrasjonsoppgaver med ulike backends, f.eks. , og andre, noe som i stor grad forenkler arbeidet. Jeg hadde problemer med EfgeFS da jeg prøvde det for noen måneder siden, så jeg testet hovedsakelig med Ceph. Ceph tilbyr ikke bare blokklagring, men også objektlagring som er kompatibel med S3/Swift og distribuert filsystem. Det jeg liker med Ceph er muligheten til å spre volumdata over flere disker, slik at volumet kan bruke mer diskplass enn det som får plass på en enkelt disk. Det er behagelig. En annen kul funksjon er at når du legger til disker i en klynge, omdistribuerer den automatisk data på tvers av alle disker.
Ceph har snapshots, men så vidt jeg vet kan de ikke brukes direkte i Rook/Kubernetes. Riktignok gikk jeg ikke dypt inn i dette. Men det er ingen sikkerhetskopier utenfor stedet, så du må bruke noe med Velero/Restic, men det er bare sikkerhetskopier på filnivå, ikke øyeblikksbilder. Det jeg virkelig likte med Rook var hvor enkelt det er å jobbe med Ceph – den skjuler nesten alle de kompliserte tingene og tilbyr verktøy for å snakke med Ceph direkte for feilsøking. Dessverre, under stresstesten av Ceph-volumer, fortsatte jeg å ha problemer med , noe som gjør at Ceph blir ustabil. Det er ennå ikke klart om dette er en feil i selve Ceph eller et problem i måten Rook administrerer Ceph på. Jeg fiklet med minneinnstillingene, og det ble bedre, men problemet var ikke helt løst. Ceph har anstendig ytelse, som du kan se i benchmarkene nedenfor. Den har også et godt dashbord.
Jeg liker veldig godt Longhorn. Etter min mening er dette en lovende løsning. Riktignok innrømmer utviklerne selv (Rancher Labs) at det ennå ikke er egnet for arbeidsmiljøet, og dette viser. Den er åpen kildekode og har grei ytelse (selv om de ikke har optimalisert den ennå), men volumene tar veldig lang tid å koble til poden, og i verste fall tar det 15-16 minutter, spesielt etter gjenoppretting av en stor sikkerhetskopi eller oppgradering av arbeidsmengden. Den har øyeblikksbilder og sikkerhetskopier utenfor stedet av disse øyeblikksbildene, men de gjelder bare for volumer, så du vil fortsatt trenge noe som Velero for å sikkerhetskopiere andre ressurser. Sikkerhetskopiering og gjenoppretting er veldig pålitelig, men uanstendig sakte. Seriøst, bare utrolig sakte. CPU-bruk og systembelastning øker ofte når du arbeider med en middels mengde data i Longhorn. Det er et praktisk dashbord for å administrere Longhorn. Jeg har allerede sagt at jeg liker Longhorn, men den trenger litt arbeid.
StorageOS er det første betalte produktet på listen. Den har en utviklerversjon med en begrenset administrert lagringsstørrelse på 500 GB, men jeg tror ikke det er noen begrensning på antall noder. Salgsavdelingen fortalte meg at prisen starter på $125 per måned for 1 TB, hvis jeg ikke husker feil. Det er et grunnleggende dashbord og en praktisk CLI, men noe rart skjer med ytelsen: i noen benchmarks er det ganske anstendig, men i volumstresstesten likte jeg ikke hastigheten i det hele tatt. Generelt vet jeg ikke hva jeg skal si. Så jeg skjønte egentlig ikke så mye. Det er ingen sikkerhetskopiering utenfor stedet her, og du må også bruke Velero med Restic for å sikkerhetskopiere volumer. Det er rart, fordi produktet er betalt. Og utviklerne var ikke ivrige etter å kommunisere på Slack.
Jeg lærte om Robin på Reddit fra deres tekniske direktør. Jeg hadde aldri hørt om ham før. Kanskje fordi jeg lette etter gratisløsninger, men Robin får betalt. De har en ganske sjenerøs gratisversjon med 10 TB lagringsplass og tre noder. Totalt sett er produktet ganske anstendig og har fine funksjoner. Det er en flott CLI, men det kuleste er at du kan ta et øyeblikksbilde og sikkerhetskopiere hele applikasjonen (i ressursvelgeren kalles dette Helm-utgivelser eller "flex-apper"), inkludert volumer og andre ressurser, slik at du kan klare deg uten Velero. Og alt ville vært fantastisk hvis ikke for en liten detalj: hvis du gjenoppretter (eller "importerer", som det heter i Robin) en applikasjon på en ny klynge - for eksempel i tilfelle gjenoppretting fra en katastrofe - gjenopprettingen, selvfølgelig fungerer, men fortsett å sikkerhetskopiere applikasjonen er det forbudt. Dette er rett og slett ikke mulig i denne utgivelsen, som utviklerne har bekreftet. Dette er mildt sagt merkelig, spesielt med tanke på de andre fordelene (for eksempel utrolig rask sikkerhetskopiering og gjenoppretting). Utviklerne lover å fikse alt innen neste utgivelse. Ytelsen er generelt god, men jeg la merke til en merkelighet: hvis jeg kjører benchmark direkte på et volum som er koblet til verten, er lesehastigheten mye raskere enn å kjøre det samme volumet fra poden. Alle andre resultater er identiske, men i teorien skal det ikke være noen forskjell. Selv om de jobber med det, var jeg opprørt over problemet med gjenoppretting og sikkerhetskopiering - jeg trodde jeg endelig hadde funnet en passende løsning, og jeg var til og med villig til å betale for det når jeg trengte mer plass eller flere servere.
Jeg har ikke så mye å si her. Dette er et betalt produkt, like kult og dyrt. Prestasjonen er rett og slett fantastisk. Dette er den beste indikatoren så langt. Slack fortalte meg at prisen starter på $205 per måned per node, som oppført i Googles GKE Marketplace. Jeg vet ikke om det blir billigere om du kjøper direkte. Jeg har ikke råd til det uansett, så jeg var veldig, veldig skuffet over at utviklerlisensen (opptil 1 TB og 3 noder) er praktisk talt ubrukelig med Kubernetes med mindre du nøyer deg med statisk klargjøring. Jeg håpet at volumlisensen automatisk skulle nedgraderes til utvikler ved slutten av prøveperioden, men det skjedde ikke. Utviklerlisensen kan kun brukes direkte med Docker, og konfigurasjonen i Kubernetes er svært tungvint og begrenset. Jeg foretrekker selvfølgelig åpen kildekode, men hadde jeg hatt pengene ville jeg definitivt valgt Portworx. Så langt er ytelsen ganske enkelt ikke sammenlignet med andre alternativer.
Jeg la til denne delen etter at innlegget ble publisert, da en leser foreslo å prøve Linstor. Jeg prøvde det og likte det! Men jeg må undersøke litt mer. Foreløpig kan jeg si at ytelsen er ganske god (jeg har lagt til benchmark-resultatene nedenfor). Faktisk fikk jeg samme ytelse som med en direkte disk-benchmark, uten overhead. (Ikke spør hvorfor Portworx sine tall er bedre enn direkte disk-benchmarken. Jeg aner ikke. Magi, antar jeg.) Så Linstor virker veldig effektiv så langt. Det er ikke akkurat vanskelig å sette det opp, men det er ikke så enkelt som andre alternativer. Først måtte jeg installere Linstor (kjernemodul og verktøy/tjenester) og sette opp LVM for tynn provisjonering og snapshot-støtte utenfor Kubernetes, direkte på verten, og deretter opprette ressursene som trengs for å bruke lagringen fra Kubernetes. Jeg var ikke fornøyd med at det ikke fungerte på CentOS og måtte bruke UbuntuDet er selvfølgelig ikke noe stort problem, men det er litt irriterende fordi dokumentasjonen (som forresten er utmerket) nevner flere pakker som ikke er tilgjengelige i de spesifiserte Epel-repositoriene. Linstor har snapshots, men ingen eksterne sikkerhetskopier, så jeg måtte bruke Velero med Restic igjen for volumsikkerhetskopier. Jeg foretrekker snapshots fremfor sikkerhetskopier på filnivå, men det er akseptabelt hvis løsningen er effektiv og pålitelig. Linstor er åpen kildekode, men det finnes betalt støtte. Hvis jeg forstår det riktig, kan du bruke det uten begrensninger selv om du ikke har en supportkontrakt, men det må jeg sjekke ut. Jeg vet ikke hvor testet Linstor er for Kubernetes, men selve lagringslaget er utenfor Kubernetes, og det ser ut som det har eksistert en stund, så det har sannsynligvis allerede blitt testet under reelle forhold. Finnes det en løsning her som ville fått meg til å ombestemme meg og bytte tilbake til Kubernetes? Jeg vet ikke. Jeg må undersøke litt mer og lære om replikering. Vi får se. Men førsteinntrykket er godt. Jeg ville definitivt foretrukket å bruke mine egne Kubernetes-klynger i stedet for Heroku for mer frihet og for å lære nye ting. Siden Linstor ikke er like enkel å installere som andre, skal jeg skrive et innlegg om det snart.
Benchmarks
Dessverre tok jeg ikke så mange notater om sammenligningen fordi jeg ikke trodde jeg skulle skrive om den. Jeg har bare resultater fra de grunnleggende fio-benchmarkene og bare for enkeltnodeklynger, så jeg har ikke tall for replikerte konfigurasjoner ennå. Men fra disse resultatene kan du få en grov ide om hva du kan forvente av hvert alternativ, fordi jeg sammenlignet dem på de samme skyserverne, 4 kjerner, 16 GB RAM, med en ekstra 100 GB disk for de testede volumene. Jeg kjørte benchmarks tre ganger for hver løsning og beregnet gjennomsnittsresultatet, pluss at jeg tilbakestilte serverinnstillingene for hvert produkt. Alt dette er fullstendig uvitenskapelig, bare for å gi deg en generell idé. I andre tester kopierte jeg 38 GB med bilder og videoer fra volumet for å teste lesing og skriving, men dessverre lagret jeg ikke tallene. Kort sagt: Portworkx var mye raskere.
For volumbenchmark brukte jeg dette manifestet:
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: 4Jeg opprettet først et volum med passende lagringsklasse og kjørte deretter jobben med fio bak kulissene. Jeg brukte 1 GB for å beregne ytelsen og ikke vente for lenge. Her er resultatene:
Jeg har fremhevet den beste verdien for hver beregning i grønt og den dårligste i rødt.
Konklusjon
Som du kan se, presterte Portworx i de fleste tilfeller bedre enn andre. Men for meg er det dyrt. Jeg vet ikke hvor mye Robin koster, men de har en flott gratisversjon, så hvis du vil ha et betalt produkt, kan du prøve det (forhåpentligvis fikser de problemet med gjenoppretting og sikkerhetskopiering snart). Av de tre gratis, hadde jeg minst problemer med OpenEBS, men ytelsen er elendig. Det er synd at jeg ikke lagret flere resultater, men jeg håper tallene og kommentarene mine vil hjelpe deg.
Kilde: www.habr.com
