Aggiornamento!. Nei commenti, uno dei lettori ha suggerito di provare (forse sta lavorando a questo), così ho aggiunto una sezione su questa soluzione. Inoltre, ho scritto , perché il processo è molto diverso dagli altri.
A dire la verità, ho gettato la spugna e ho rinunciato a (perlomeno, per ora). Continuerò a usare . Perché? A causa dello storage! Chi avrebbe mai pensato che avrei passato più tempo a occuparmi degli storage che di Kubernetes stesso. Sto usando , perché è economico e le prestazioni sono buone, e fin dall'inizio ho distribuito i cluster usando . Non ho provato i servizi Kubernetes gestiti di Google/Amazon/Microsoft/DigitalOcean e così via, perché volevo imparare tutto da solo. E inoltre, sono piuttosto economico.
Quindi sì, ho speso molto tempo cercando di capire quale sistema di storage scegliere mentre valutavo il possibile stack su Kubernetes. Preferisco soluzioni open source, non solo per il prezzo, ma ho anche esplorato un paio di opzioni a pagamento per curiosità, poiché hanno versioni gratuite con limitazioni. Ho annotato alcuni dati degli ultimi test confrontando diverse opzioni, e potrebbero interessare coloro che studiano lo storage su Kubernetes. Personalmente, però, ho già chiuso con Kubernetes. Vorrei anche menzionare , che permette di preparare direttamente i volumi di Hetzner Cloud, ma non lo ho ancora provato. Ho esplorato gli storage definiti tramite software in cloud, poiché avevo bisogno di replica e della possibilità di connettere rapidamente volumi persistenti su qualsiasi nodo, specialmente in caso di guasti dei nodi o situazioni simili. Alcune soluzioni offrono snapshot a un certo punto nel tempo e backup off-site, il che è molto utile.
Ho testato 6–7 soluzioni per lo storage:
Come ho già detto , dopo aver testato la maggior parte delle opzioni della lista, inizialmente mi sono fermato su OpenEBS. OpenEBS è molto semplice da installare e utilizzare, ma, ad essere sincero, dopo i test con dati reali sotto carico, le sue prestazioni mi hanno deluso. È open source, e gli sviluppatori sul loro sono sempre stati molto d'aiuto quando avevo bisogno di supporto. Sfortunatamente, ha prestazioni molto inferiori rispetto ad altre opzioni, quindi ho dovuto ripetere i test. Attualmente OpenEBS ha 3 motori di storage, ma pubblico i risultati del benchmark per cStor. Non ho ancora dati per Jiva e LocalPV.
In breve, Jiva è leggermente più veloce, mentre LocalPV è davvero veloce, non peggio del benchmark del disco direttamente. Il problema con LocalPV è che l'accesso è possibile solo sul nodo in cui è stato preparato, e non c'è replicazione. Ho avuto alcuni problemi nel ripristinare un backup tramite su un nuovo cluster, perché i nomi dei nodi erano diversi. Parlando di backup, cStor ha un , con cui è possibile effettuare backup off-site di snapshot a un determinato punto nel tempo, il che è più comodo rispetto ai backup a livello di file con Velero-Restic. Ho scritto , per semplificare la gestione dei backup e dei ripristini con questo plugin. In generale, mi piace molto OpenEBS, ma le sue prestazioni...
Rook ha anche il codice sorgente aperto e si distingue dalle altre opzioni nella lista per essere un orchestratore di storage che gestisce compiti complessi di gestione dello storage con diversi backend, come , e altri, il che semplifica notevolmente il lavoro. Ho avuto problemi con EdgeFS quando l'ho provato qualche mese fa, quindi l'ho testato principalmente con Ceph. Ceph offre non solo uno storage a blocchi, ma anche uno storage a oggetti compatibile con S3/Swift e un file system distribuito. Ciò che mi piace di Ceph è la possibilità di suddividere i dati del volume su più dischi, in modo che il volume possa utilizzare più spazio su disco di quanto possa starci su un singolo disco. Questa è una funzionalità utile. Un'altra funzione interessante è che quando si aggiungono dischi al cluster, redistribuisce automaticamente i dati su tutti i dischi.
In Ceph ci sono snapshot, ma, per quanto ne so, non possono essere utilizzati direttamente in Rook/Kubernetes. Tuttavia, non ho approfondito molto. Non ci sono backup off-site, quindi dovrò usare qualcosa come Velero/Restic, ma questi supportano solo backup a livello di file, non snapshot nel momento del tempo. D'altra parte, mi è piaciuto molto lavorare con Ceph in Rook — nasconde quasi tutte le complessità e offre strumenti per interagire direttamente con Ceph per la risoluzione dei problemi. Purtroppo, nella stress test delle volume Ceph, ho riscontrato continuamente , che rende Ceph instabile. Non è chiaro se si tratta di un bug in Ceph stesso o di un problema nel modo in cui Rook gestisce Ceph. Ho giocato con le impostazioni della memoria e ci sono stati miglioramenti, ma il problema non è completamente risolto. Ceph ha ottime prestazioni, come si può vedere nei benchmark qui sotto. Inoltre, ha un buon pannello di monitoraggio.
Mi piace molto Longhorn. Penso che sia una soluzione promettente. Tuttavia, gli stessi sviluppatori (Rancher Labs) ammettono che al momento non è adatto per ambienti di produzione, e questo è evidente. Ha un codice sorgente aperto e buone prestazioni (anche se non si sono ancora occupati dell'ottimizzazione), ma i volumi si collegano molto lentamente al pod, e nei casi peggiori possono richiedere 15–16 minuti, specialmente dopo il ripristino di un grande backup o un aggiornamento del carico di lavoro. Ha snapshot e backup off-site di questi snapshot, ma si applicano solo ai volumi, quindi avrai comunque bisogno di qualcosa come Velero per il backup delle altre risorse. I backup e i ripristini sono molto affidabili, ma incredibilmente lenti. Sul serio, semplicemente lenti oltre ogni limite. L'uso delle risorse della CPU e il carico del sistema spesso aumentano durante la gestione di un volume medio di dati in Longhorn. C'è un'interfaccia di monitoraggio intuitiva per gestire Longhorn. Ho già detto che mi piace Longhorn, ma deve essere migliorato.
StorageOS è il primo prodotto a pagamento della lista. Esiste una versione per sviluppatori con una capacità di archiviazione gestita limitata a 500 GB, ma il numero di nodi, a quanto pare, non è limitato. Nel reparto vendite mi hanno detto che il costo parte da 125 $ al mese per 1 TB, se non ricordo male. C'è un pannello di monitoraggio di base e una CLI user-friendly, ma ci sono delle stranezze con le performance: in alcuni benchmark sono abbastanza buone, ma nei test di stress dei volumi non mi sono piaciute per niente. In generale, non so cosa dire. Perciò non mi sono nemmeno impegnato a capire bene. Qui non ci sono backup off-site e dovrò usare anche Velero con Restic per il backup dei volumi. È strano, considerando che il prodotto è a pagamento. Inoltre, gli sviluppatori non sembrano essere molto propensi a comunicare su Slack.
Ho scoperto Robin su Reddit grazie al loro CTO. Non ne avevo mai sentito parlare prima, forse perché stavo cercando soluzioni gratuite, mentre Robin è a pagamento. Hanno una versione gratuita piuttosto generosa con 10 TB di storage e tre nodi. In generale, il prodotto è veramente valido e offre funzionalità interessanti. C'è un'ottima interfaccia a riga di comando, ma la cosa migliore è la possibilità di creare snapshot e backup dell'intera applicazione (nella selezione delle risorse sono chiamati release di Helm o "flex apps"), inclusi volumi e altre risorse, quindi è possibile fare a meno di Velero. E tutto sarebbe perfetto se non fosse per un piccolo dettaglio: se si tenta di ripristinare (o "importare", come viene chiamato in Robin) l'applicazione su un nuovo cluster, ad esempio in caso di ripristino dopo un guasto, il ripristino funziona, ma non è possibile continuare il backup dell'applicazione. In questa release, è semplicemente impossibile, e gli sviluppatori lo hanno confermato. È, per così dire, strano, specialmente considerando gli altri vantaggi (come backup e ripristini incredibilmente rapidi). Gli sviluppatori promettono di risolvere tutto nella prossima release. Le prestazioni, in generale, sono buone, ma ho notato una stranezza: se eseguo un benchmark direttamente sul volume collegato all'host, la velocità di lettura è molto superiore a quella dello stesso volume dall'interno del pod. Tutti gli altri risultati sono identici, ma in teoria non ci dovrebbe essere differenza. Anche se stanno lavorando su questo, sono rimasto deluso per il problema con il ripristino e il backup: mi sembrava finalmente di aver trovato una soluzione adatta, e ero addirittura pronto a pagare per essa quando avessi avuto bisogno di più spazio o di più server.
Qui non ho molto da dire. Si tratta di un prodotto a pagamento, di alta qualità e costoso. Le prestazioni sono straordinarie. Finora è il miglior indicatore. In Slack mi hanno detto che il prezzo parte da 205 $ al mese per nodo, come indicato nel GKE Marketplace di Google. Non so se ci sarà un prezzo inferiore acquistando direttamente. In ogni caso, non posso permettermi una cosa del genere, quindi sono rimasto molto deluso dal fatto che la licenza per sviluppatori (fino a 1 TB e 3 nodi) risulti praticamente inutilizzabile con Kubernetes, a meno che tu non sia soddisfatto di una preparazione statica. Speravo che la licenza aziendale scendesse automaticamente a livello di sviluppatore alla fine del periodo di prova, ma così non è stato. La licenza per sviluppatori può essere utilizzata solo direttamente con Docker, e la configurazione in Kubernetes è molto ingombrante e limitata. Certo, preferisco l'open source, ma se avessi i soldi, sceglierei sicuramente Portworx. Fino ad ora, le sue prestazioni non hanno paragoni con 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! Tuttavia, c'è ancora da approfondire. Al momento posso dire che le prestazioni sono buone (i risultati del benchmark sono aggiunti qui sotto). Fondamentalmente, ho ottenuto le stesse prestazioni di un disco direttamente, senza costi aggiuntivi. (Non chiedete perché i numeri di Portworx siano migliori rispetto a quelli del disco diretto. Non ne ho idea. Magia, probabilmente.) Quindi, Linstor sembra essere molto efficace per ora. Non è difficile da installare, ma non è così facile come le altre opzioni. All'inizio ho dovuto installare Linstor (modulo del kernel e strumenti/servizi) e configurare LVM per il thin provisioning e supportare gli snapshot al di fuori di Kubernetes, direttamente sull'host, e poi creare le risorse necessarie per utilizzare lo storage da Kubernetes. Non mi è piaciuto che non funzionasse su CentOS e ho dovuto usare Ubuntu. Non è un grosso problema, ma è un po' fastidioso perché nella documentazione (che tra l'altro è eccellente) vengono menzionati alcuni pacchetti che non si trovano nei repository Epel indicati. In Linstor ci sono snapshot, ma non backup off-site, quindi qui ho dovuto usare di nuovo Velero con Restic per il backup dei volumi. Preferirei snapshot invece di backup a livello di file, ma si può tollerare se la soluzione è performante e affidabile. Linstor è open source, ma esiste anche supporto a pagamento. Se ho capito bene, può essere utilizzato senza restrizioni, anche se non si ha un contratto di supporto, ma è meglio chiarirlo. Non so quanto Linstor sia collaudato per Kubernetes, ma il livello di storage è al di fuori di Kubernetes e, a quanto pare, la soluzione non è recente, quindi probabilmente è già stata testata in condizioni reali. C’è una soluzione qui che mi convinca a tornare a Kubernetes? Non lo so, non lo so. È necessario esplorare ulteriormente e studiare la replica. Vedremo. Ma la prima impressione è positiva. Preferirei sicuramente utilizzare i miei cluster Kubernetes anziché Heroku per avere maggiore libertà e imparare cose nuove. Poiché Linstor non si installa così facilmente come gli altri, presto scriverò un post al riguardo.
Benchmark
Purtroppo, ho salvato poche registrazioni sulle comparazioni, perché non pensavo che avrei scritto a riguardo. Ho solo i risultati di benchmark di base fio e solo per cluster con un nodo, quindi per configurazioni replicate non ho dati al momento. Tuttavia, da questi risultati si può avere un'idea approssimativa di cosa aspettarsi da ciascuna opzione, poiché li ho confrontati su server cloud identici, 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 calcolato la media dei risultati, più ho ripristinato le impostazioni del server per ogni prodotto. Tutto ciò non è scientifico, ma è solo per darvi un'idea generale. In altri test ho copiato 38 GB di foto e video da e su un volume per testare la lettura e la scrittura, ma sfortunatamente non ho salvato i dati. In breve: Portworkx era molto più veloce.
Per il benchmark dei volumi ho usato questo manifesto:
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 avviato un job con fio in background. Ho scelto 1 GB per valutare le prestazioni senza dover aspettare troppo a lungo. Ecco i risultati:
Ho evidenziato il valore migliore per ogni metrica in verde e il peggiore in rosso.
Conclusione
Come potete vedere, nella maggior parte dei casi Portworx ha dimostrato di essere migliore degli altri. Ma per me è costoso. Non so quanto costi Robin, ma c'è un'ottima versione gratuita, quindi se avete bisogno di un prodotto a pagamento, potete provarlo (speriamo che risolvano presto il problema con il ripristino e i backup). Tra i tre gratuiti, ho avuto meno problemi con OpenEBS, ma le sue prestazioni sono scarse. Peccato che non abbia salvato più risultati, ma spero che i numeri e i miei commenti forniti vi siano utili.
Fonte: habr.com
