Aggiornare!. Nei commenti, uno dei lettori ha suggerito di provare (forse ci sta lavorando lui stesso) quindi ho aggiunto una sezione su questa soluzione. Ho anche scritto , perché il processo è molto diverso dal resto.
Ad essere sincero, mi sono arreso e mi sono arreso (almeno per ora). userò . Perché? A causa dello stoccaggio! Chi avrebbe mai pensato che avrei armeggiato più con lo storage che con Kubernetes stesso. Io uso perché è poco costoso e le prestazioni sono buone e fin dall'inizio ho distribuito cluster utilizzando . Non ho provato i servizi gestiti Kubernetes di Google/Amazon/Microsoft/DigitalOcean, ecc. ecc., perché volevo imparare tutto da solo. Sono anche frugale.
Quindi sì, ho passato molto tempo cercando di decidere quale storage scegliere quando valutavo un possibile stack Kubernetes. Preferisco le soluzioni open source, non solo per il prezzo, ma ho esaminato un paio di opzioni a pagamento per curiosità perché hanno versioni gratuite con limitazioni. Ho annotato alcuni numeri provenienti da test recenti quando ho confrontato diverse opzioni e potrebbero essere interessanti per coloro che stanno imparando a conoscere lo storage Kubernetes. Anche se personalmente per ora ho detto addio a Kubernetes. Voglio anche menzionare , che può eseguire direttamente il provisioning dei volumi Hetzner Cloud, ma non l'ho ancora provato. Ho esaminato lo storage cloud definito dal software perché avevo bisogno della replica e della possibilità di montare rapidamente volumi persistenti su qualsiasi nodo, soprattutto in caso di guasti del nodo e altre situazioni simili. Alcune soluzioni offrono istantanee temporizzate e backup off-site, il che è conveniente.
Ho testato 6-7 soluzioni di archiviazione:
Come ho già detto Dopo aver testato la maggior parte delle opzioni dell'elenco, inizialmente ho optato per OpenEBS. OpenEBS è molto facile da installare e utilizzare, ma a dire il vero, dopo aver testato con dati reali sotto carico, sono rimasto deluso dalle sue prestazioni. Questo è open source e gli sviluppatori sono soli sempre molto disponibile quando avevo bisogno di aiuto. Sfortunatamente, ha prestazioni molto scarse rispetto ad altre opzioni, quindi i test hanno dovuto essere rieseguiti. OpenEBS ha attualmente 3 motori di archiviazione, ma sto pubblicando i risultati dei benchmark per cStor. Non ho ancora i numeri per Jiva e LocalPV.
In poche parole, Jiva è un po' più veloce e LocalPV è generalmente veloce, non peggiore del benchmark diretto del disco. Il problema con LocalPV è che è possibile accedere al volume solo sul nodo in cui è stato preparato e non vi è alcuna replica. Ho avuto alcuni problemi nel ripristinare un backup tramite su un nuovo cluster perché i nomi dei nodi erano diversi. Se parliamo di backup, cStor ha , con il quale è possibile eseguire backup off-site di istantanee in un determinato momento, il che è più conveniente dei backup a livello di file con Velero-Restic. scrissi , per semplificare la gestione di backup e ripristini con questo plugin. Nel complesso, mi piace molto OpenEBS, ma le sue prestazioni...
Anche Rook è open source e differisce dal resto delle opzioni nell'elenco in quanto è un orchestratore di archiviazione che esegue attività complesse di gestione dello storage con diversi backend, ad es. , e altri, il che semplifica notevolmente il lavoro. Ho avuto problemi con EfgeFS quando l'ho provato qualche mese fa, quindi ho provato principalmente con Ceph. Ceph non offre solo storage a blocchi, ma anche storage di oggetti compatibile con S3/Swift e file system distribuito. Ciò che mi piace di Ceph è la capacità di distribuire i dati del volume su più dischi in modo che il volume possa utilizzare più spazio su disco di quello che può stare su un singolo disco. È comodo. Un'altra caratteristica interessante è che quando aggiungi dischi a un cluster, ridistribuisce automaticamente i dati su tutti i dischi.
Ceph dispone di istantanee, ma per quanto ne so non possono essere utilizzate direttamente in Rook/Kubernetes. È vero, non sono andato in profondità in questo. Ma non ci sono backup off-site, quindi dovrai usare qualcosa con Velero/Restic, ma ci sono solo backup a livello di file, non istantanee point-in-time. Ciò che mi è davvero piaciuto di Rook è stata la facilità con cui è possibile lavorare con Ceph: nasconde quasi tutte le cose complicate e offre strumenti per parlare direttamente con Ceph per la risoluzione dei problemi. Purtroppo, durante lo stress test dei volumi Ceph, ho continuato ad avere problemi con , il che rende Ceph instabile. Non è ancora chiaro se si tratti di un bug di Ceph stesso o di un problema nel modo in cui Rook gestisce Ceph. Ho armeggiato con le impostazioni della memoria e la situazione è migliorata, ma il problema non è stato completamente risolto. Ceph ha prestazioni decenti, come puoi vedere nei benchmark seguenti. Ha anche un buon cruscotto.
Mi piace molto Longhorn. A mio parere, questa è una soluzione promettente. È vero, gli stessi sviluppatori (Rancher Labs) ammettono che non è ancora adatto all'ambiente di lavoro, e questo dimostra. È open source e ha prestazioni decenti (anche se non l'hanno ancora ottimizzato), ma i volumi impiegano molto tempo per connettersi al pod e, nel peggiore dei casi, ci vogliono 15-16 minuti, soprattutto dopo aver ripristinato un backup di grandi dimensioni o potenziamento del carico di lavoro. Dispone di istantanee e backup off-site di queste istantanee, ma si applicano solo ai volumi, quindi avrai comunque bisogno di qualcosa come Velero per eseguire il backup di altre risorse. I backup e i ripristini sono molto affidabili, ma indecentemente lenti. Sul serio, semplicemente incredibilmente lento. L'utilizzo della CPU e il carico del sistema spesso aumentano quando si lavora con una quantità media di dati in Longhorn. C'è una comoda dashboard per gestire Longhorn. Ho già detto che mi piace Longhorn, ma ha bisogno di un po' di lavoro.
StorageOS è il primo prodotto a pagamento nell'elenco. Ha una versione per sviluppatori con una dimensione di archiviazione gestita limitata di 500 GB, ma non credo che ci sia un limite al numero di nodi. Il reparto vendite mi ha detto che il costo parte da $ 125 al mese per 1 TB, se ricordo bene. C'è una dashboard di base e una comoda CLI, ma sta succedendo qualcosa di strano con le prestazioni: in alcuni benchmark è abbastanza decente, ma nello stress test del volume non mi è piaciuta affatto la velocità. In generale, non so cosa dire. Quindi non ho capito molto. Non ci sono backup fuori sede qui e dovrai anche utilizzare Velero con Restic per eseguire il backup dei volumi. È strano, perché il prodotto è pagato. E gli sviluppatori non erano ansiosi di comunicare su Slack.
Ho saputo di Robin su Reddit dal loro direttore tecnico. Non ne avevo mai sentito parlare prima. Forse perché cercavo soluzioni gratuite, ma Robin è a pagamento. Hanno una versione gratuita piuttosto generosa con 10 TB di spazio di archiviazione e tre nodi. Nel complesso, il prodotto è abbastanza decente e ha caratteristiche interessanti. C'è un'ottima CLI, ma la cosa più interessante è che puoi eseguire lo snapshot e il backup dell'intera applicazione (nel selettore delle risorse si chiama versioni Helm o "app flessibili"), inclusi volumi e altre risorse, così puoi fare a meno di Velero. E tutto sarebbe meraviglioso se non fosse per un piccolo dettaglio: se ripristini (o “importi”, come dice Robin) un'applicazione su un nuovo cluster - ad esempio, in caso di ripristino da un disastro - il ripristino, ovviamente funziona, ma è vietato continuare a eseguire il backup dell'applicazione. Ciò semplicemente non è possibile in questa versione, come hanno confermato gli sviluppatori. Questo è, per usare un eufemismo, strano, soprattutto considerando gli altri vantaggi (ad esempio, backup e ripristini incredibilmente veloci). Gli sviluppatori promettono di sistemare tutto entro la prossima versione. Le prestazioni sono generalmente buone, ma ho notato una stranezza: se eseguo il benchmark direttamente su un volume collegato all'host, la velocità di lettura è molto più veloce rispetto all'esecuzione dello stesso volume dall'interno del pod. Tutti gli altri risultati sono identici, ma in teoria non dovrebbero esserci differenze. Anche se ci stanno lavorando, ero sconvolto dal problema con il ripristino e il backup: pensavo di aver finalmente trovato una soluzione adeguata ed ero persino disposto a pagare per questo quando avevo bisogno di più spazio o più server.
Non ho molto da dire qui. Questo è un prodotto a pagamento, altrettanto interessante e costoso. La performance è semplicemente fantastica. Questo è il miglior indicatore finora. Slack mi ha detto che i prezzi partono da $ 205 al mese per nodo, come indicato nel GKE Marketplace di Google. Non so se costerà meno acquistando direttamente. In ogni caso non posso permettermelo, quindi sono rimasto molto, molto deluso dal fatto che la licenza per sviluppatore (fino a 1 TB e 3 nodi) sia praticamente inutile con Kubernetes a meno che non ti accontenti del provisioning statico. Speravo che la licenza a volume venisse automaticamente retrocessa a sviluppatore al termine del periodo di prova, ma ciò non è accaduto. La licenza per sviluppatore può essere utilizzata solo direttamente con Docker e la configurazione in Kubernetes è molto macchinosa e limitata. Ovviamente preferisco l'open source, ma se avessi i soldi sceglierei sicuramente Portworx. Finora, le sue prestazioni semplicemente non sono paragonabili ad altre opzioni.
Ho aggiunto questa sezione dopo la pubblicazione del post, quando un lettore ha suggerito di provare Linstor. L'ho provato e mi è piaciuto! Ma dobbiamo ancora scavare più a fondo. Ora posso dire che le prestazioni non sono male (ho aggiunto i risultati del benchmark qui sotto). In sostanza, ho ottenuto direttamente le stesse prestazioni del disco, senza alcun sovraccarico. (Non chiedere perché Portworx abbia numeri migliori rispetto al benchmark diretto dell'unità. Non ne ho idea. Magia, immagino.) Quindi Linstor sembra molto efficace finora. Non è così difficile da installare, ma non è facile come altre opzioni. Per prima cosa ho dovuto installare Linstor (modulo kernel e strumenti/servizi) e configurare LVM per il thin provisioning e il supporto degli snapshot all'esterno di Kubernetes, direttamente sull'host, quindi creare le risorse necessarie per utilizzare lo storage da Kubernetes. Non mi piaceva il fatto che non funzionasse su CentOS e dovevo usare Ubuntu. Non terribile, ovviamente, ma un po' fastidioso, perché la documentazione (che tra l'altro è eccellente) menziona diversi pacchetti che non possono essere trovati nei repository Epel specificati. Linstor dispone di istantanee, ma non di backup fuori sede, quindi anche in questo caso ho dovuto utilizzare Velero con Restic per eseguire il backup dei volumi. Preferirei le istantanee invece dei backup a livello di file, ma questo può essere tollerato se la soluzione è performante e affidabile. Linstor è open source ma ha il supporto a pagamento. Se ho capito bene può essere utilizzato senza restrizioni, anche se non si ha un contratto di assistenza, ma questo è da chiarire. Non so quanto sia testato Linstor per Kubernetes, ma il livello di archiviazione stesso è esterno a Kubernetes e, a quanto pare, la soluzione non è apparsa ieri, quindi probabilmente è già stata testata in condizioni reali. Esiste una soluzione qui che mi farà cambiare idea e tornare a Kubernetes? Non lo so. Dobbiamo ancora scavare più a fondo e studiare la replicazione. Vediamo. Ma la prima impressione è buona. Preferirei sicuramente utilizzare i miei cluster Kubernetes invece di Heroku per avere più libertà e imparare cose nuove. Poiché Linstor non è facile da installare come gli altri, scriverò presto un post a riguardo.
Punti di riferimenti
Purtroppo non ho tenuto molti appunti sul confronto perché non pensavo di scriverne. Ho solo risultati dai benchmark fio di base e solo per cluster a nodo singolo, quindi non dispongo ancora di numeri per le configurazioni replicate. Ma da questi risultati puoi avere un'idea approssimativa di cosa aspettarti da ciascuna opzione, perché le ho confrontate sugli stessi server cloud, 4 core, 16 GB di RAM, con un disco aggiuntivo da 100 GB per i volumi testati. Ho eseguito i benchmark tre volte per ciascuna soluzione e ho calcolato il risultato medio, inoltre ho ripristinato le impostazioni del server per ciascun prodotto. Tutto questo è completamente antiscientifico, solo per darti un'idea generale. In altri test ho copiato 38 GB di foto e video dal volume per testare la lettura e la scrittura, ma ahimè non ho salvato i numeri. In breve: Portworkx era molto più veloce.
Per il benchmark del volume ho usato questo 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: 4Per prima cosa ho creato un volume con la classe di archiviazione appropriata e poi ho eseguito il lavoro con fio dietro le quinte. Ho preso 1 GB per stimare le prestazioni e non aspettare troppo a lungo. Ecco i risultati:
Ho evidenziato il valore migliore per ciascuna metrica in verde e il peggiore in rosso.
conclusione
Come puoi vedere, nella maggior parte dei casi Portworx ha funzionato meglio di altri. Ma per me è caro. Non so quanto costa Robin, ma hanno un'ottima versione gratuita, quindi se vuoi un prodotto a pagamento, puoi provarlo (speriamo che risolvano presto il problema con il ripristino e i backup). Dei tre gratuiti, ho avuto meno problemi con OpenEBS, ma le sue prestazioni sono pessime. È un peccato non aver salvato più risultati, ma spero che i numeri e i miei commenti ti possano aiutare.
Fonte: habr.com