Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Storage

Panoramica

Esistono scenari in cui è possibile eseguire applicazioni che richiedono la conservazione dei dati a breve o lungo termine. In questi casi d'uso, i volumi possono essere definiti e montati dai Pod in modo che i relativi contenitori possano attingere a diversi meccanismi di archiviazione. Kubernetes supporta diversi tipi di volumi per lo storage temporaneo e persistente. La scelta dello storage dipende in gran parte dai requisiti dell'applicazione. Per ogni approccio, esistono implicazioni in termini di costi e le pratiche descritte di seguito che consentono di ridurre i costi per i carichi di lavoro che richiedono una qualche forma di storage negli ambienti EKS.

Volumi effimeri

I volumi effimeri sono destinati ad applicazioni che richiedono volumi locali transitori ma non richiedono che i dati rimangano persistenti dopo il riavvio. Ne sono un esempio i requisiti per lo spazio di memoria virtuale, la memorizzazione nella cache e i dati di input di sola lettura come dati di configurazione e segreti. Puoi trovare maggiori dettagli sui volumi effimeri di Kubernetes qui. La maggior parte dei volumi temporanei (ad esempio emptyDir, ConfigMap, DownwardAPI, secret, hostpath) è supportata da dispositivi scrivibili collegati localmente (di solito il disco root) o RAM, quindi è importante scegliere il volume host più efficiente in termini di costi e prestazioni.

Utilizzo di volumi EBS

Consigliamo di iniziare con gp3 come volume root dell'host. È l'ultimo volume SSD generico offerto da Amazon EBS e offre anche un prezzo inferiore (fino al 20%) per GB rispetto ai volumi gp2.

Utilizzo di Amazon EC2 Instance Stores

Gli EC2 instance store di Amazon forniscono uno storage temporaneo a livello di blocco per le tue EC2 istanze. Lo storage fornito dagli EC2 instance store è accessibile tramite dischi fisicamente collegati agli host. A differenza di Amazon EBS, puoi collegare solo volumi di Instance Store all'avvio dell'istanza e questi volumi esistono solo per la durata dell'istanza. Non possono essere scollegati e ricollegati ad altre istanze. Puoi trovare ulteriori informazioni sugli Amazon EC2 Instance Store qui. Non sono previsti costi aggiuntivi associati al volume di un instance store. Ciò le rende (Instance Store Volume) più efficienti in termini di costi rispetto alle EC2 istanze generiche con grandi volumi EBS.

Per utilizzare i volumi di archiviazione locali in Kubernetes, devi partizionare, configurare e formattare i dischi utilizzando i dati utente di EC2 Amazon in modo che i volumi possano essere montati secondo le specifiche del pod. HostPath In alternativa, puoi sfruttare Local Persistent Volume Static Provisioner per semplificare la gestione dello storage locale. Il provisioner statico Local Persistent Volume consente di accedere ai volumi di archiviazione delle istanze locali tramite l'interfaccia PersistentVolumeClaim Kubernetes (PVC) standard. Inoltre, fornirà PersistentVolumes (PVs) che contiene informazioni sull'affinità dei nodi per pianificare i Pod sui nodi corretti. Sebbene utilizzi Kubernetes PersistentVolumes, i volumi di EC2 instance store sono di natura effimera. I dati scritti su dischi temporanei sono disponibili solo durante la vita dell'istanza. Quando l'istanza viene terminata, lo sono anche i dati. Consulta questo blog per maggiori dettagli.

Tieni presente che quando usi i volumi di Amazon EC2 Instance Store, il limite totale di IOPS viene condiviso con l'host e associa i Pod a un host specifico. È necessario esaminare attentamente i requisiti del carico di lavoro prima di adottare i volumi di Amazon EC2 Instance Store.

Volumi persistenti

Kubernetes è in genere associato all'esecuzione di applicazioni stateless. Tuttavia, esistono scenari in cui potresti voler eseguire microservizi che richiedono la conservazione di dati o informazioni persistenti da una richiesta all'altra. I database sono un esempio comune di questi casi d'uso. Tuttavia, i Pod e i contenitori o i processi al loro interno sono di natura effimera. Per conservare i dati oltre la durata di vita di un Pod, è possibile definire l' PVs accesso all'archiviazione in una posizione specifica indipendente dal Pod. I costi associati PVs dipendono in larga misura dal tipo di storage utilizzato e dal modo in cui le applicazioni lo utilizzano.

Di seguito sono elencati diversi tipi di opzioni di storage che supportano Kubernetes su PVs Amazon EKS. Le opzioni di storage descritte di seguito sono Amazon EBS, Amazon EFS, Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP.

Volumi Amazon Elastic Block Store (EBS)

I volumi Amazon EBS possono essere utilizzati come Kubernetes PVs per fornire volumi di storage a livello di blocco. Sono ideali per database che si basano su letture e scritture casuali e applicazioni ad alta velocità di trasmissione che eseguono letture e scritture lunghe e continue. Il driver Amazon Elastic Block Store Container Storage Interface (CSI) consente ai cluster Amazon EKS di gestire il ciclo di vita dei volumi Amazon EBS per volumi persistenti. La Container Storage Interface abilita e facilita l'interazione tra Kubernetes e un sistema di storage. Quando un driver CSI viene distribuito nel cluster EKS, è possibile accedere alle sue funzionalità tramite le risorse di storage Kubernetes native come Persistent Volumes (PVs), Persistent Volume Claims () e Storage Classes (). PVCs SCs Questo collegamento fornisce esempi pratici di come interagire con i volumi Amazon EBS con il driver Amazon EBS CSI.

Scelta del volume giusto

Consigliamo di utilizzare lo storage a blocchi di ultima generazione (gp3) in quanto offre il giusto equilibrio tra prezzo e prestazioni. Consente inoltre di scalare gli IOPS e la velocità effettiva del volume indipendentemente dalle dimensioni del volume senza dover fornire ulteriore capacità di storage a blocchi. Se attualmente utilizzi volumi gp2, ti consigliamo vivamente di migrare ai volumi gp3. Il post sul blog La migrazione dei cluster Amazon EKS dai volumi EBS gp2 a gp3 spiega come migrare da gp2 a gp3 su cluster Amazon EKScon backup e ripristino utilizzando la funzionalità CSI Volume Snapshots, che richiede tempi di inattività delle applicazioni.

Amazon EBS consente di modificare le caratteristiche del volume come dimensione del volume, IOPS e velocità effettiva online. Utilizzando questa funzionalità è possibile migrare da gp2 a gp3 senza tempi di inattività delle applicazioni utilizzando le annotazioni PVC come descritto in questo blog, che richiede il driver CSI EBS v1.19.0+, o iniziando con Amazon EKS v1.31 e il driver EBS CSI 1.35 utilizzando l'API come descritto qui. VolumeAttributesClass

Quando hai applicazioni che richiedono prestazioni più elevate e richiedono volumi più grandi di quelli che un singolo volume gp3 può supportare, dovresti prendere in considerazione l'utilizzo di io2 block express. Questo tipo di storage è ideale per le implementazioni più grandi, I/O intensive e mission critical come SAP HANA o altri database di grandi dimensioni con requisiti di bassa latenza. Tieni presente che le prestazioni EBS di un'istanza sono limitate dai limiti di prestazioni dell'istanza, quindi non tutte le istanze supportano i volumi io2 block express. Puoi controllare i tipi di istanza supportati e altre considerazioni in questo documento.

Un singolo volume gp3 può supportare fino a 16.000 IOPS massimi, 1.000 velocità effettiva massima, MiB/s massimo 16 TiB. Volume SSD Provisioned IOPS di ultima generazione che fornisce fino a 256.000 IOPS, 4.000 MiB/s, throughput e 64 TiB.

Tra queste opzioni, è consigliabile personalizzare al meglio le prestazioni e i costi di storage in base alle esigenze delle applicazioni.

Monitora e ottimizza nel tempo

È importante comprendere le prestazioni di base dell'applicazione e monitorarla per determinati volumi per verificare se soddisfa i requisiti richiesti requirements/expectations o se il provisioning è eccessivo (ad esempio, uno scenario in cui gli IOPS assegnati non vengono utilizzati appieno).

Invece di allocare un volume elevato dall'inizio, è possibile aumentare gradualmente le dimensioni del volume man mano che si accumulano dati. Puoi ridimensionare dinamicamente i volumi utilizzando la funzionalità di ridimensionamento del volume nel driver CSI di Amazon Elastic Block Store (). aws-ebs-csi-driver Tieni presente che puoi solo aumentare la dimensione del volume EBS.

Per identificare e rimuovere eventuali volumi EBS sospesi, puoi utilizzare la categoria di ottimizzazione dei costi di AWS trusted advisor. Questa funzionalità consente di identificare volumi non collegati o volumi con un'attività di scrittura molto bassa per un periodo di tempo. Esiste uno strumento di sola lettura, open source e nativo del cloud, chiamato Popeye, che analizza i cluster Kubernetes attivi e segnala potenziali problemi con le risorse e le configurazioni distribuite. Ad esempio, può eseguire una scansione alla ricerca di elementi inutilizzati PVs e verificare se sono associati o se sono presenti errori di montaggio del PVCs volume.

Per un'analisi approfondita del monitoraggio, consulta la guida all'osservabilità dell'ottimizzazione dei costi di EKS.

Un'altra opzione da prendere in considerazione sono le raccomandazioni sul volume di AWS Compute Optimizer Amazon EBS. Questo strumento identifica automaticamente la configurazione ottimale del volume e il corretto livello di prestazioni richiesto. Ad esempio, può essere utilizzato per impostazioni ottimali relative agli IOPS assegnati, alle dimensioni dei volumi e ai tipi di volumi EBS in base all'utilizzo massimo negli ultimi 14 giorni. Quantifica inoltre i potenziali risparmi mensili sui costi derivanti dalle sue raccomandazioni. Puoi consultare questo blog per maggiori dettagli.

Politica di conservazione dei backup

Puoi eseguire il backup dei dati sui tuoi volumi Amazon EBS scattando point-in-time istantanee. Il driver Amazon EBS CSI supporta gli snapshot dei volumi. Puoi imparare a creare un'istantanea e ripristinare un PV EBS utilizzando i passaggi descritti qui.

Le istantanee successive sono backup incrementali, il che significa che vengono salvati solo i blocchi sul dispositivo che sono stati modificati dopo l'istantanea più recente. Ciò consente di ridurre il tempo necessario per creare lo snapshot e risparmiare sui costi di archiviazione in quanto i dati non vengono duplicati. Tuttavia, l'aumento del numero di vecchie istantanee EBS senza una politica di conservazione adeguata può causare costi imprevisti quando si opera su larga scala. Se esegui il backup diretto dei volumi Amazon EBS tramite l'API AWS, puoi sfruttare Amazon Data Lifecycle Manager (DLM) che fornisce una soluzione di gestione del ciclo di vita automatizzata e basata su policy per Amazon Elastic Block Store (EBS) Snapshots e Amazon Machine Images () con supporto EBS. AMIs La console semplifica l'automazione della creazione, della conservazione e dell'eliminazione di istantanee EBS e. AMIs

In un ambiente Kubernetes, puoi sfruttare uno strumento open source chiamato Velero per eseguire il backup dei tuoi EBS Persistent Volumes. È possibile impostare un flag TTL quando si pianifica la scadenza dei backup del processo. Ecco un esempio di guida di Velero.

Amazon Elastic File System (EFS)

Amazon Elastic File System (EFS) è un file system serverless e completamente elastico che consente di condividere i dati dei file utilizzando l'interfaccia di file system e la semantica del file system standard per un ampio spettro di carichi di lavoro e applicazioni. Esempi di carichi di lavoro e applicazioni includono Wordpress e Drupal, strumenti per sviluppatori come JIRA e Git e sistemi notebook condivisi come Jupyter e home directory.

Uno dei principali vantaggi di Amazon EFS è che può essere montato da più container distribuiti su più nodi e più zone di disponibilità. Un altro vantaggio è che paghi solo per lo storage che utilizzi. I file system EFS cresceranno e si ridurranno automaticamente man mano che si aggiungono e rimuovono file, eliminando la necessità di pianificare la capacità.

Per utilizzare Amazon EFS in Kubernetes, devi utilizzare il driver Amazon Elastic File System Container Storage Interface (CSI),. aws-efs-csi-driver Attualmente, il driver può creare punti di accesso in modo dinamico. Tuttavia, il file system Amazon EFS deve essere prima fornito e fornito come input per il parametro della classe di storage Kubernetes.

Scelta della classe di storage EFS giusta

Amazon EFS offre quattro classi di storage.

Due classi di storage standard:

Due classi di storage a zona singola:

Le classi di storage Infrequent Access (IA) sono ottimizzate in termini di costi per i file a cui non si accede tutti i giorni. Con la gestione del ciclo di vita di Amazon EFS, puoi spostare file a cui non è stato effettuato l'accesso per la durata della politica del ciclo di vita (7, 14, 30, 60 o 90 giorni) nelle classi di storage IA, il che può ridurre i costi di storage fino al 92 percento rispetto rispettivamente alle classi di storage EFS Standard ed EFS One Zone.

Con EFS Intelligent-Tiering, la gestione del ciclo di vita monitora i modelli di accesso del file system e sposta automaticamente i file nella classe di storage più ottimale.

Amazon FSx per Lustre

Lustre è un file system parallelo ad alte prestazioni comunemente utilizzato nei carichi di lavoro che richiedono un throughput fino a centinaia GB/s e latenze inferiori al millisecondo per operazione. Viene utilizzato per scenari come la formazione sull'apprendimento automatico, la modellazione finanziaria, l'HPC e l'elaborazione video. Amazon FSx for Lustre offre uno storage condiviso completamente gestito con scalabilità e prestazioni, perfettamente integrato con Amazon S3.

Puoi utilizzare i volumi di storage persistente Kubernetes supportati da FSx for Lustre utilizzando il driver CSI for Lustre di Amazon EKS o il FSx tuo cluster Kubernetes autogestito su AWS. Consulta la documentazione di Amazon EKS per ulteriori dettagli ed esempi.

Collegamento ad Amazon S3

Si consiglia di collegare un repository di dati a lungo termine altamente durevole che risiede su Amazon S3 al file system for FSx Lustre. Una volta collegati, i set di dati di grandi dimensioni vengono caricati lentamente in base alle esigenze da Amazon S3 ai file system for Lustre. FSx Puoi anche eseguire le analisi e i risultati su S3 e quindi eliminare il file system Lustre.

Scelta delle opzioni di implementazione e archiviazione corrette

FSx for Lustre offre diverse opzioni di implementazione. La prima opzione si chiama scratch e non replica i dati, mentre la seconda opzione è chiamata persistent e, come suggerisce il nome, persiste i dati.

La prima opzione (scratch) può essere utilizzata per ridurre il costo dell'elaborazione temporanea dei dati a breve termine. L'opzione di distribuzione persistente è progettata per lo storage a lungo termine che replica automaticamente i dati all'interno di una zona di disponibilità AWS. Supporta anche lo storage SSD e HDD.

Puoi configurare il tipo di implementazione desiderato in base ai parametri di Kubernetes del filesystem FSx for lustre. StorageClass Ecco un link che fornisce modelli di esempio.

Abilita la compressione dei dati

È inoltre possibile abilitare la compressione dei dati sul file system specificando "LZ4" come tipo di compressione dei dati. Una volta abilitata, tutti i file appena scritti verranno automaticamente compressi su Lustre prima FSx di essere scritti su disco e decompressi quando vengono letti. LZ4 l'algoritmo di compressione dei dati è senza perdite, quindi i dati originali possono essere completamente ricostruiti dai dati compressi.

Puoi configurare il tipo di compressione dei dati come indicato nei parametri LZ4 di Kubernetes del file system FSx for lustre. StorageClass La compressione è disabilitata quando il valore è impostato su NONE, che è l'impostazione predefinita. Questo collegamento fornisce modelli di esempio.

Amazon FSx per NetApp ONTAP

Amazon FSx for NetApp ONTAP è uno storage condiviso completamente gestito basato sul NetApp file system ONTAP. FSx for ONTAP offre uno storage di file condiviso ricco di funzionalità, veloce e flessibile, ampiamente accessibile dalle istanze di calcolo Linux, Windows e macOS in esecuzione in AWS o in locale.

Amazon FSx for NetApp ONTAP supporta due livelli di storage: 1/livello primario e 2/livello di pool di capacità.

Il livello principale è un livello predisposto basato su SSD ad alte prestazioni per dati attivi e sensibili alla latenza. Il livello di pool di capacità completamente elastico è ottimizzato in termini di costi per i dati a cui si accede raramente, si ridimensiona automaticamente man mano che i dati vengono suddivisi su più livelli e offre petabyte di capacità praticamente illimitati. È possibile abilitare la compressione e la deduplicazione dei dati sullo storage con pool di capacità e ridurre ulteriormente la quantità di capacità di storage consumata dai dati. NetAppla FabricPool funzionalità nativa basata su policy monitora continuamente i modelli di accesso ai dati, trasferendo automaticamente i dati in modo bidirezionale tra i livelli di storage per ottimizzare prestazioni e costi.

NetAppAstra Trident fornisce un'orchestrazione dinamica dello storage utilizzando un driver CSI che consente ai cluster Amazon EKS di gestire il ciclo di vita dei volumi persistenti supportati PVs da Amazon per i file system ONTAP. FSx NetApp Per iniziare, consulta Use Astra Trident with Amazon FSx for NetApp ONTAP nella documentazione di Astra Trident.

Altre considerazioni

Riduci al minimo le dimensioni dell'immagine del contenitore

Una volta implementati i contenitori, le immagini dei contenitori vengono memorizzate nella cache dell'host come livelli multipli. Riducendo le dimensioni delle immagini, è possibile ridurre la quantità di storage richiesta sull'host.

Utilizzando fin dall'inizio immagini di base ridotte, come immagini scratch o immagini di container senza distribuzione (che contengono solo l'applicazione e le relative dipendenze di runtime), è possibile ridurre i costi di storage oltre ad altri vantaggi accessori, come la riduzione della superficie di attacco e tempi di recupero delle immagini più brevi.

È inoltre consigliabile prendere in considerazione l'utilizzo di strumenti open source, come Slim.ai, che offre un modo semplice e sicuro per creare immagini minime.

Più livelli di pacchetti, strumenti, dipendenze delle applicazioni e librerie possono facilmente aumentare le dimensioni dell'immagine del contenitore. Utilizzando build in più fasi, potete copiare selettivamente gli artefatti da una fase all'altra, escludendo tutto ciò che non è necessario dall'immagine finale. Puoi consultare altre best practice per la creazione di immagini qui.

Un'altra cosa da considerare è per quanto tempo conservare le immagini memorizzate nella cache. Potresti voler pulire le immagini obsolete dalla cache delle immagini quando viene utilizzata una certa quantità di disco. In questo modo sarà possibile assicurarsi di disporre di spazio sufficiente per il funzionamento dell'host. Per impostazione predefinita, il kubelet esegue la raccolta dei rifiuti sulle immagini non utilizzate ogni cinque minuti e sui contenitori inutilizzati ogni minuto.

Per configurare le opzioni per il contenitore inutilizzato e la raccolta dei rifiuti di immagini, ottimizza il kubelet utilizzando un file di configurazione e modifica i parametri relativi alla raccolta dei rifiuti utilizzando il tipo di risorsa. KubeletConfiguration

Puoi saperne di più nella documentazione di Kubernetes.