kubernetes volumi considerazioni

in Architetture Software, Informatica

Kubernetes – Considerazioni sui Volumi – parte2

Reading Time: 2 minutes

Riprendendo il post precedente, in cui ho riportato alcune considerazioni sulla mia esperienza personale sull’utilizzo dei volumi all’interno di un cluster Kubernetes. In particolar modo, l’impostazione di uno scenario che fa uso di un sistema persistente di memorizzazione è spesso associato ad un servizio cloud esistente.

Ma in che modo Kubernetes comunica con un servizio esterno cloud per la creazione e l’utilizzo dei volumi? Tipicamente tramite alcune api / interfacce messe a disposizione dalla stessa terza parte. Queste soluzioni vengono spesso chiamati storage-plugin. Questi plugin consentono di astrarre il concetto di archiviazione (e di volume) rendendo il servizio trasparente per l’utente e soprattutto portabile verso altre architetture.

All’inizio questo tipo di plugin doveva essere creato, compilato, installato ed eseguito all’interno del codice sorgente di kubernetes. L’aggiunta di questi plugin poteva comportare un effort piuttosto alto per lo sviluppatore e per eventuali manutenzioni future. L’aggiunta di un nuovo sistema di archiviazione richiedeva l’integrazione con il codice sorgente di Kubernetes stesso.

Con l’introduzione di CSI (Container Storage Interface) e Flexvolume, i plug-in di volume possono essere distribuiti su un cluster senza particolari modifiche.

Kubernetes e lo storage nativo

Ovviamente Kubernetes consente di utilizzare nativamente i volumi, utilizzando i Persistent Volume e i Persistent Volume Claims, come abbiamo già trattato nel post precedente. In pratica i Persistent Volume (PV) vengono definiti all’interno del cluster dall’amminstratore e sono indipendenti dal normale ciclo di vita dei pods. Per poter utilizzare un PV è necessario utilizzare un Persistent Volume Claims (PVC) che di fatto è una richiesta di utilizzo di un PV. Definendo un PVC è possibile associare l’archiviazione ad un nodo particolare, rendendolo disponibile.

Esistono due modi per gestire l’archiviazione:

  • Statica
  • Dinamica

Con il provisioning statico, l’amministatore definisce quali possono essere i PV da allocare e li alloca. In pratica, prima che effettivamente siano state fatte le richieste da parte dei singoli POD. In un secondo momento l’associazione tra POD e PVC viene effettuata manualmente utilizzando i PVC.

Il vero problema di questo tipo di configurazione è la mancanza di flessibilità: il binding avviene modificando il file YAML di configurazione ed ogni modifica richiede il deploy di un nuovo file. Inoltre lo storage utilizzato può essere dipendente dalla tipologia di storage utilizzato.

Tutto questo è in netto contrasto con la flessibilità offerta da Kubernetes: le risorse (CPU, Memoria, ecc… ) non vengono allocate in anticipo e vincolate ad un pod/container, ma devono seguire il funzionamento dell’applicazione in maniera dinamica.

Il provisioning dinamico

In alternativa all’utilizzo del provisioning statico, è possibile utilizzare il provisioning dinamico, utilizzando le classi di archiviazione. In questo scenario l’amministratore non ha la necessità di creare a priori i PV.

Vengono invece creati dei modelli: al momento della creazione del PVC viene creato un modello corrispondente alla richiesta del PVC ed allegato al POD.