Categoria: Cloud

Cloud Modern Application

Pubblicato il

Snapshot e protezione dei dati

Con lo storage ormai integrato nel cluster, il passo successivo è  “salvare dati”, anche se preferisco la dizione proteggerli.
In questo capitolo il desiderio è stato quello di far passare il laboratorio da semplice piattaforma Kubernetes a sistema resiliente.

Perché gli snapshot sono fondamentali

In Kubernetes i dati vivono dentro volumi persistenti (PVC), ma senza snapshot:

  • non puoi fare rollback
  • non puoi fare restore veloci
  • non puoi garantire recovery point affidabili

Gli snapshot sono l’equivalente moderno dei checkpoint delle macchine virtuali, ma applicati ai volumi containerizzati.

Snapshot CSI: la base tecnologica

Tramite Il CSI driver di Synology, il cluster ha ottenuto una nuova capacità:

K8s può chiedere allo storage di creare snapshot dei volumi.

Questo introduce tre nuove entità:

  • VolumeSnapshotClass
  • VolumeSnapshot
  • VolumeSnapshotContent

Non sono file.
Sono oggetti Kubernetes che rappresentano snapshot reali creati sul NAS.

Il legame tra Kubernetes e Synology

Quando Kubernetes crea un VolumeSnapshot:

  • Il CSI driver invia la richiesta al Synology
  • Il NAS crea uno snapshot iSCSI nativo
  • Kubernetes riceve l’ID dello snapshot
  • Il VolumeSnapshot diventa ReadyToUse

A questo punto lo snapshot è:

  • consistente (non da un punto di vista applicativo)
  • puntuale
  • indipendente dal pod

Ed è pronto per essere usato per backup o restore.

Validazione degli snapshot

Nel laboratorio è stato creato un PVC di test con dati scritti da un pod.
Da lì sono stati generati snapshot CSI e verificato che:

  • esistono nel NAS
  • sono visibili come oggetti Kubernetes
  • possono essere usati per creare nuovi volumi

Questo ha dimostrato che lo storage era snapshot-aware, requisito essenziale per Kasten K10.

Perché questo passaggio è cruciale per il backup

Kasten K10 non lavora direttamente con i filesystem ma lavora con Snapshot CSI consistenti.

Senza questa aggiunta, Kasten avrebbe potuto solo fare backup “file based”, con gli snapshot, invece è possibile effettuare:

  • backup istantanei
  • consistenza applicativa
  • restore rapidi

È qui che nasce la vera data protection cloud-native.

Risultato

Alla fine di questo step il cluster possiede:

  • Storage persistente
  • Snapshot nativi
  • API Kubernetes per gestirli

Il laboratorio è pronto per introdurre un altro protagonista:
Kasten K10.

Pubblicato il

Storage e k8s cluster

Con il cluster Kubernetes operativo, il passo successivo è quello di gestire la cosa più critica di tutte i dati.

Un cluster senza storage persistente è solo una piattaforma di calcolo.
Un cluster con storage condiviso diventa invece una piattaforma applicativa reale 🙂

Il problema da risolvere

Le applicazioni Kubernetes non possono dipendere dai dischi locali dei nodi:

  • un pod può spostarsi da un nodo all’altro
  • un nodo può spegnersi
  • un container può essere ricreato

Quindi se i dati restano legati al nodo, vengono persi.

Serve quindi uno storage:

  • condiviso tra i nodi
  • persistente
  • gestito dinamicamente da Kubernetes

Lo storage esterno: Synology e WD

Nel laboratorio erano disponibili due sistemi di storage esterni:

  • Synology → usato come storage primario con supporto iSCSI e snapshot
  • WD NAS → usato come repository NFS per la seconda copia (backup)

Integrazione dello storage con Kubernetes

Per permettere a Kubernetes di usare lo storage Synology come se fosse nativo, è stato installato:

  • CSI Driver di Synology
  • Snapshot Controller CSI

Questi componenti trasformano lo storage fisico in risorse Kubernetes:

  • PersistentVolumes
  • PersistentVolumeClaims
  • VolumeSnapshots

In pratica, Kubernetes ha iniziato a parlare direttamente con il NAS, senza script o mount manuali.

Le StorageClass

Una volta installato il driver, sono state create le StorageClass, che definiscono:

  • tipo di storage (iSCSI)
  • policy di cancellazione
  • supporto snapshot

Ogni applicazione che richiede storage non chiede più “un disco”, ma chiede una Storage Class con determinate caratteristiche.

Ed è K8s, tramite il CSI driver, che crea automaticamente i volumi sul NAS.

Verifica con PV, PVC e Pod

Per validare l’integrazione sono stati creati:

  • un PVC (PersistentVolumeClaim)
  • un PV (creato dinamicamente dal NAS)
  • un Pod di test che scrive dati sul volume

In quel momento è stato verificato che:

  • il volume esiste realmente sul Synology
  • il pod può scrivere dati
  • i dati sopravvivono al riavvio del pod

Questo è stato il primo vero test di persistenza reale del cluster.

Risultato

Il cluster è diventato un cluster Kubernetes con storage condiviso.

Ora il sistema era pronto per:

  • snapshot
  • backup
  • restore
  • disaster recovery

Prossimo capitolo, usare Kasten K10 per proteggere l’ambiente.

Pubblicato il

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

Pubblicato il

Kubernets: Health-Check & Port-Forwarding

HEALTH-CHECK

One of the advanced and most important features of kubernetes is the health-check which allows you to check the integrity of the services.

It is an additional layer that adds to the standard controls that guarantee that the application processes are always running ( livenessProbe ), the application integrity controls ( ReadinessProbe )

The advantage of the health check is that:

  • It is specific for each container.
  • It uses the same logic as the application (for example, loading a web page, pinging a DB ).
  • The livenessProbe determines if the application is running correctly. Otherwise, the application is restarted.
  • The ReadinessProbe describes when the container is ready to satisfy the requests of the users (and therefore of the service)

The configuration of the health -check is done by adding the livenessProbe and ReadinessProbe items to the POD configuration yaml file (see figure 1)

Figure 1

PORT-FORWARDING

Port forwarding authorizes the service (configured at the POD level) to communicate both with other PODs and with the outside world. Without Port Forwarding, the service is totally isolated.

The simplest example is that of a website. As long as port-forwarding is not started, the pages of the site are not available to users.

In our example ( some-mysql ), after POD has started, the command to enable application port-forwarding on port 8000 is:

kubectl port forward some-mysql 8000: 8000

An article is available on the website www.gable.it that explores the networking issue of Container environments. To read it click here.

In a future article, we will talk about load balancers that help networking management.

Soon

 

Pubblicato il

Kubernetes: Pods

In previous articles, we have seen that containers are ” abstract ” places where applications run in the form of images.

PODs are the aggregation of multiple containers .

A service is the aggregation of several PODs .

The image in figure 1 shows the concept just explained.

Figure 1

 

All applications (images) present within the same POD will have the same (shared) IP address and the same Hostname (UTS NameSpace).

Communication between containers within the same HOST occurs through POSIX or System V IPCs

Now imagine you want to provide the ” the-gable-svc ” service, built with two images (containers): a Database and a Front-End.

During the design phase, is it better to design a single POD that contains the two containers ( figure 2 ) or two PODs with a container each ( figure 3 )? ( 1POD x 2 CONTAINER or 2 POD x 1 CONTAINER )

Figure 2

Figure 3

To answer accurately, you need to understand which application needs the most scalability and flexibility.

In our example it is the DB that could require more resources (RAM & CPU) to manage access peaks.

If I had designed a single POD, the increase in resources would involve both applications, effectively not optimizing energy expenditure.

Note 1: CPU & RAM resources are allocated during POD creation.

Is it always better to create more PODs?

This latter statement does not align with K8s’ resilience policy, where PODs should run on different physical hosts ( k8s is a cluster).

To resolve the demise, there is a good rule :

If the service works fine even though the PODs are spread across multiple hosts, then it is better to use multiple PODs (Figure 2).

Figure 4 shows the contents of the mysql-pod.yaml file that creates the POD for the mySQL application.

Figure 4

Let’s see the basic POD management syntax:

  • To start it just run the command: kubectl apply -f mysql-pod.yaml
  • To check its status: kubectl get pods
  • To get all the details: kubectl describe pods some-mysql
  • If we wanted to delete it: kubectl delete -f mysql-pod.yaml

For today it’s all in a little bit where we will talk about Access to the POD, how to copy files and much more.

Soon