Aggiornamento!. Nei commenti uno dei lettori ha suggerito di provare (forse ci sta lavorando da solo), quindi ho aggiunto una sezione su questa soluzione. Ho anche scritto , perché il processo è molto diverso rispetto agli altri.
Se devo essere onesto, ho gettato la spugna e ho rinunciato a (almeno per ora). Utilizzerò . Perché? A causa dello storage! Chi l'avrebbe mai detto che avrei trascorso più tempo a gestire lo storage piuttosto che Kubernetes stesso. Sto utilizzando , perché è economico e le prestazioni sono buone, e sin dall'inizio ho dispiegato cluster usando . Non ho provato i servizi Kubernetes gestiti di Google/Amazon/Microsoft/DigitalOcean e simili, perché volevo imparare tutto da solo. Inoltre, sono parsimonioso.
Quindi, sì, ho speso molto tempo cercando di decidere quale storage scegliere mentre valutavo il possibile stack su Kubernetes. Preferisco soluzioni open source, non solo per il prezzo, ma ho esplorato un paio di opzioni a pagamento per curiosità, poiché hanno versioni gratuite con limitazioni. Ho annotato alcuni dati dai miei ultimi test mentre confrontavo diverse opzioni, e potrebbero interessare chi studia lo storage in Kubernetes. Anche se personalmente, per ora, ho detto addio a Kubernetes. Vorrei anche menzionare , con cui è possibile preparare direttamente i volumi di Hetzner Cloud, ma non l'ho ancora provato. Ho studiato soluzioni di storage cloud-defined, perché avevo bisogno di replica e della possibilità di connettere rapidamente volumi persistenti su qualsiasi nodo, soprattutto in caso di guasti dei nodi e situazioni simili. Alcune soluzioni offrono snapshot di momenti specifici e backup off-site, ed è molto comodo.
Ho testato 6-7 soluzioni di 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, per essere onesto, 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 assistenza. Purtroppo, ha prestazioni molto basse rispetto ad altre opzioni, quindi ho dovuto ripetere i test. Attualmente OpenEBS ha 3 motori di archiviazione, ma pubblico i risultati del benchmark per cStor. Al momento non ho dati per Jiva e LocalPV.
In breve, Jiva è un po' più veloce, mentre LocalPV è davvero veloce, non peggio di un benchmark diretto del disco. Il problema con LocalPV è che l'accesso è possibile solo sul nodo in cui è stato preparato, e non c'è replicazione. Ho avuto alcuni problemi con il ripristino del backup tramite sul nuovo cluster, perché i nomi dei nodi erano diversi. Parlando di backup, cStor ha , che consente di effettuare backup off-site degli snapshot a un preciso momento, cosa più comoda 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 codice sorgente aperto, e si differenzia dagli altri opzioni nella lista per il fatto che è un orchestratore di archiviazione, in grado di gestire compiti complessi di gestione dello storage con diversi backend, come ad esempio , e altri, semplificando notevolmente il lavoro. Ho avuto problemi con EdgeFS quando l'ho provato alcuni mesi fa, quindi ho testato principalmente con Ceph. Ceph offre non solo archiviazione di blocchi, ma anche archiviazione di oggetti compatibile con S3/Swift e un file system distribuito. Ciò che mi piace di Ceph è la possibilità di distribuire i dati del volume su più dischi, in modo che il volume possa utilizzare più spazio di archiviazione di quanto possa contenere un singolo disco. È molto comodo. Un'altra funzione utile è che, quando aggiungi dischi al cluster, i dati vengono automaticamente ridistribuiti su tutti i dischi.
In Ceph ci sono snapshot, ma, per quanto ne so, non possono essere utilizzati direttamente in Rook/Kubernetes. In realtà, non mi sono approfondito. Non ci sono backup off-site, quindi dovrò usare qualcosa come Velero/Restic, ma lì ci sono solo backup a livello di file e non snapshot a un certo punto nel tempo. Tuttavia, in Rook mi è piaciuto molto il lavoro semplice con Ceph: nasconde quasi tutte le cose complesse e offre strumenti per comunicare direttamente con Ceph per la risoluzione dei problemi. Purtroppo, nei test di stress sui volumi Ceph ho sempre avuto , che rende Ceph instabile. Non è chiaro se sia un bug in Ceph stesso o se sia un problema di come Rook gestisce Ceph. Ho giocato con le impostazioni della memoria e ho notato un miglioramento, ma il problema non è completamente risolto. Ceph offre buone prestazioni, come si vede nei benchmark qui sotto. Ha anche un buon pannello di monitoraggio.
Mi piace molto Longhorn. Penso sia una soluzione promettente. Tuttavia, gli stessi sviluppatori (Rancher Labs) ammettono che attualmente non è adatto per un ambiente di produzione, e questo è evidente. Ha codice sorgente aperto e buone prestazioni (anche se non si sono ancora occupati dell'ottimizzazione), ma i volumi impiegano molto tempo per collegarsi al pod, e nei casi peggiori ci vogliono dai 15 ai 16 minuti, specialmente dopo il ripristino di un grande backup o l'aggiornamento di un 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 ridicolmente lenti. L'uso delle risorse della CPU e il carico di sistema spesso aumentano durante il lavoro con volume di dati medio in Longhorn. C'è un comodo pannello di monitoraggio per gestire Longhorn. Ho già detto che mi piace Longhorn, ma c'è bisogno di lavorarci seriamente.
StorageOS è il primo prodotto a pagamento della lista. Ha una versione per sviluppatori con un limite di capacità di archiviazione gestita di 500 GB, ma, a quanto pare, il numero di nodi non è limitato. Nel reparto vendite mi hanno detto che il costo parte da $125 al mese per 1 TB, se ho ricordato bene. C'è un pannello di controllo di base e un'interfaccia CLI comoda, ma la prestazione ha qualcosa di strano: in alcuni benchmark è piuttosto buona, ma nel test di stress dei volumi la velocità non mi è piaciuta affatto. Insomma, non so cosa dire. Perciò non mi sono approfondito particolarmente. Non ci sono backup off site e dovrò utilizzare Velero con Restic per il backup dei volumi. È strano, visto che il prodotto è a pagamento. Inoltre, gli sviluppatori non sembrano molto desiderosi di comunicare su Slack.
Ho scoperto Robin su Reddit dal loro direttore tecnico. Prima non ne avevo mai sentito parlare. Forse perché cercavo soluzioni gratuite, mentre Robin è a pagamento. Hanno una versione gratuita piuttosto generosa con 10 TB di spazio di archiviazione e tre nodi. Nel complesso, il prodotto è abbastanza valido e con funzionalità piacevoli. Hanno un ottimo CLI, ma la cosa più interessante è che si può creare snapshot e backup dell'intera applicazione (nel selettore delle risorse è chiamato release Helm o "flex apps"), inclusi volumi e altre risorse, quindi si può fare a meno di Velero. E tutto sarebbe fantastico, se non fosse per un piccolo particolare: se si ripristina (o "importa", come si dice in Robin) l'applicazione su un nuovo cluster — ad esempio in caso di ripristino dopo un guasto — il ripristino funziona, ovviamente, ma non si può continuare a fare backup dell'applicazione. In questa release è semplicemente impossibile, e gli sviluppatori lo hanno confermato. È, per dirla in modo gentile, strano, soprattutto considerando gli altri vantaggi (ad esempio, backup e ripristini incredibilmente veloci). Gli sviluppatori promettono di risolvere tutto per la prossima release. Le prestazioni, in generale, sono buone, ma ho notato una stranezza: se si esegue un benchmark direttamente su un volume collegato all'host, la velocità di lettura è molto più alta rispetto allo stesso volume, ma dall'interno del pod. Tutti gli altri risultati sono identici, ma in teoria non dovrebbe esserci differenza. Anche se ci stanno lavorando, sono rimasto deluso per il problema con il ripristino e il backup — mi sembrava di aver finalmente trovato una soluzione adeguata, e ero anche pronto a pagare per essa quando avrei avuto bisogno di più spazio o più server.
Qui non ho molto da dire. È un prodotto a pagamento, altrettanto fantastico e costoso. Le prestazioni sono semplicemente straordinarie. Finora è il miglior risultato. In Slack mi hanno detto che il prezzo parte da $205 al mese per nodo, come indicato nel Google GKE Marketplace. Non so se sarà più economico se acquisto direttamente. In ogni caso, non posso permettermi una spesa del genere, quindi sono rimasto molto deluso che la licenza sviluppatore (fino a 1 TB e 3 nodi) sia praticamente inutile con Kubernetes, a meno che non ti accontenti di una preparazione statica. Speravo che la licenza aziendale si riducesse automaticamente al livello sviluppatore alla fine del periodo di prova, ma non è successo. La licenza sviluppatore può essere utilizzata solo direttamente con Docker, mentre la configurazione in Kubernetes è molto ingombrante e limitata. Certo, preferisco l'open source, ma se avessi i soldi, sceglierei sicuramente Portworx. Finora le sue prestazioni non possono competere 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! Ma c'è ancora del lavoro da fare. Adesso posso dire che le prestazioni non sono male (ho aggiunto i risultati del benchmark qui sotto). In sostanza, ho ottenuto le stesse prestazioni che avrei avuto con un disco direttamente, senza perdite. (Non chiedetemi perché i numeri di Portworx siano migliori rispetto al benchmark del disco direttamente. Non ne ho idea. Magia, suppongo.) Quindi, Linstor sembra molto efficace. Installarlo non è proprio difficile, ma non è facile come altre opzioni. All'inizio ho dovuto installare Linstor (modulo del kernel e strumenti/servizi) e configurare LVM per thin provisioning e supporto agli 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 è ottima) vengono menzionati diversi pacchetti che non si possono trovare nei repository Epel indicati. In Linstor ci sono snapshot, ma non backup off-site, quindi 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 c'è supporto a pagamento. Se ho capito bene, può essere utilizzato senza limitazioni, anche se non si ha un contratto di supporto, ma questo va verificato. Non so quanto Linstor sia stato testato per Kubernetes, ma il livello di storage è esterno a Kubernetes e, a quanto pare, la soluzione non è arrivata ieri, quindi probabilmente è già stata testata in ambienti reali. C'è una soluzione qui che mi farà cambiare idea e tornare a Kubernetes? Non lo so, non lo so. C'è ancora bisogno di esplorare, studiare la replicazione. Vedremo. Ma la prima impressione è buona. Sicuramente preferirei usare i miei cluster Kubernetes invece di Heroku, per avere più libertà e imparare cose nuove. Dato che l'installazione di Linstor non è così semplice come le altre, presto scriverò un post su questo.
Benchmark
Sfortunatamente, ho registrato poche annotazioni sul confronto, perché non ho pensato di scriverne. Ho solo i risultati dei benchmark di base fio e solo per i cluster con un nodo, quindi per le configurazioni replicate non ho ancora numeri. Ma da questi risultati è possibile farsi un'idea di cosa aspettarsi da ogni 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 ogni soluzione e ho calcolato il risultato medio, oltre a ripristinare le impostazioni del server per ogni prodotto. Tutto ciò non è affatto scientifico, serve solo per darvi un'idea generale. In altri test ho copiato 38 GB di foto e video da e su un volume per testare lettura e scrittura, ma sfortunatamente non ho salvato i numeri. In breve: Portworx è stato 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: 4Prima ho creato un volume con la classe di archiviazione appropriata, poi ho avviato il job con fio in background. Ho scelto 1 GB per stimare le prestazioni e non dover aspettare troppo a lungo. Ecco i risultati:
Ho evidenziato il miglior valore per ciascun indicatore in verde e il peggiore in rosso.
Conclusione
Come potete vedere, nella maggior parte dei casi Portworx si è comportato meglio degli altri. Ma per me è costoso. Non so quanto costi Robin, ma hanno una grande versione gratuita, quindi se avete bisogno di un prodotto a pagamento, potete provare (spero che risolvano presto il problema del ripristino e dei backup). Tra i tre gratuiti, ho avuto meno problemi con OpenEBS, anche se le sue prestazioni sono scarse. Peccato non aver salvato più risultati, ma spero che i numeri forniti e i miei commenti vi possano aiutare.
Fonte: habr.com
