24 Settembre 202124 Settembre 2021 di gabriele pelizzari

Persistent Data & Resource Management

Persistent Data

Nei precedenti articoli, abbiamo visto che se un POD viene dismesso o il container viene riavviato, tutti i dati presenti sul file system del POD vengono cancellati.

E’ un approccio vincente per tutte quelle applicazioni stateless (ad esempio un front-end web) ma non lo è per le applicazioni stateful dove ad esempio non registrare anche un record di un DataBase significa perdere informazioni vitali per il servizio erogato.

Kubernetes supera brillantemente l’ ostacolo attraverso l’utilizzo della tecnologia Persistent Data.

E’ il file yaml che definisce nel POD i Persisten Data attraverso le voci:

Volumes che descrive i volumi disponibili per il POD.
VolumeMounts che descrive il percorso per l’utilizzo del volume (ad esempio /mydata/)

I Volumi sono categorizzati in tre principali categorie create in base al loro utilizzo:

1- Comunicazione/sincronizzazione

E’ il volume condiviso per realizzare la sincronizzazzione con le immagini di una Git remota.

La vita del volume è limitata all’esistenza del POD ed il volume può essere condiviso tra più container.

2- Dati Persistenti

Per garantire l’alta affidabilità e le migliori performance, i POD devono potersi spostarsi liberamente tra i nodi del cluster kubernetes.

Di conseguenza i volumi che contengono informazioni persistenti e vitali dell’applicazione devono essere sempre raggiungibili dal POD.

Kubernetes per garantire la visibilità supporta molte tipologie di volumi ad esempio NFS, iSCSI, Elastic Block Store di Amazon, File e Disk Storage Azure, nonché Google Persistent Disk.

Nota1: In caso di spostamento del POD, Kubernetes in automatico è in grado di smontare il volume dal vecchio host e renderlo disponibile sul nuovo.

3- Filesystem host

Alcune applicazioni non hanno bisogno solo di un volume persistente, ma anche di un filesystem disponibile a livello di host. La necessità è indirizzata attraverso il volume hostPath (Ad esempio /var/mygp/).

Resource Management

Il costo di funzionamento di una macchina in un datacenter, è indipendente dalla quantità di CPU & RAM che utilizza la singola VM in esercizio.
Garantire invece che all’interno dell’infrastruttura, le risorse CPU & RAM siano distribuite al meglio, impatta l’efficenza dell’ambiente.

Esempio:

Immaginiamo due servizi. Il primo utilizza il 20% della memoria di una VM configurata con 5GB di RAM, il secondo utilizza il 50% di una seconda VM configurata con 4GB RAM.

L’utilizzo totale di memoria RAM è di 1+2=3GB delle 9GB totale assegnate.

La metrica di utilizzo (MU) è definita come il valore percentuale tra il rapporto della quantità di risorse attivamente utilizzate e la quantità di risorse acquistate.

Nel nostro esempio MU=3/9= 33%

Al fine di controllare l’uso delle risorse, Kubernetes consente agli utenti di specificare due diverse metriche a livello di POD.

Resource Request specifica la quantità minima assegnabile alla risorsa.
Resource limits specifica la quantità massima assegnabile all’applicazione.

L’esempio di figura 1 mostra l’iun esempio di limite di risorse

Figura 1

Lascia un commento Annulla risposta

24 Settembre 20215 Ottobre 2021 di gabriele pelizzari

Persistent Data & Resource Management

Persistent Data

In previous articles, we have seen that if a POD is decommissioned or the container is restarted, all data on the POD file system is erased.

It is a winning approach for all those stateless applications (for example a web front-end ) but it is not for stateful applications where, for example, not registering a record of a DataBase means losing vital information for the service provided.

Kubernetes brilliantly overcomes the obstacle through the use of Persistent Data technology.

It is the yaml file that defines the Persisten Data in the POD through the entries:

Volumes describing the volumes available for the POD.
VolumeMounts describing the path or usage of the volume (e.g. / mydata /)

Volumes are categorized into three main categories created based on their use:

1- Communication / synchronization

It is the shared volume to synchronize with the images of a remote Git.

The life of the volume is limited to the existence of the POD and the volume can be shared between multiple containers.

2- Persistent Data

To ensure high reliability and best performance, the PODs must be able to move freely between the nodes of the kubernetes cluster.

As a result, volumes that contain persistent and vital application information must always be reachable by the POD.

Kubernetes to ensure visibility supports many types of volumes such as NFS, iSCSI , Amazon’s Elastic Block Store, Azure File and Disk Storage, as well as Google Persistent Disk.

Note1: If you move your POD , Kubernetes can automatically unmount the volume from the old host and make it available on the new one.

3- Host filesystem

Some applications not only need a persistent volume, but also a file system available at the host level. The need is addressed through the hostPath volume (e.g. /var/mygp/).

Resource Management

The cost of operating a machine in a data center is independent of the amount of CPU & RAM that the single VM in operation uses.
On the other hand, ensuring that CPU & RAM resources are distributed in the best possible way within the infrastructure impacts the efficiency of the environment.

Example:

Let’s imagine two services. The former uses 20% of the memory of a VM configured with 5GB of RAM, the latter uses 50% of a second VM configured with 4GB RAM.

The total use of RAM memory is 1 + 2 = 3GB of the total 9GB allocated.

Utilization metric ( MU ) is defined as the percentage value between the ratio of the amount of actively used resources and the number of purchased resources.

In our example MU = 3/9 = 33%

In order to control resource usage, Kubernetes allows users to specify two different metrics at the POD level.

Resource Request specifies the minimum amount that can be assigned to the resource.
Resource limits specify the maximum amount that can be assigned to the application.

The example of Figure 1 shows an example of a resource limit

Figure 1