14 Settembre 202116 Settembre 2021 di gabriele pelizzari

Kubernetes: Pods

Nei precedenti articoli, abbiamo visto che i container sono dei luoghi “astratti” dove girano le applicazioni sotto forma di immagini.

I POD sono l’aggregazione di più container.

Un servizio è l’aggragazione di più POD.

L’immagine di figura 1 mostra il concetto appena esposto.

Figura 1

Tutte le applicazioni (immagini) presenti all’interno dello stesso POD, avranno lo stesso indirizzo IP (condiviso) e lo stesso Hostname (UTS NameSpace).

La comunicazione tra i container all’interno dello stesso HOST avviene attraverso POSIX o le IPC di System V

Immaginate ora di voler erogare il servizio “the-gable-svc“, costruito con due immagini (container): un Database e un Front-End.

In fase di progetto è meglio disegnare un unico POD che contenga i due contanier (figura 2) oppure due POD con ognuno un container (figura 3)? (1POD x 2 CONTAINER oppure 2 POD x 1 CONTAINER)

Figura 2

Figura 3

Per rispondere accuratamente è necessario comprendere quale applicazione ha la necessita di maggiore scalabilità e flessibilità.

Nel nostro esempio è il DB che per gestire picchi di accesso, potrebbe richiedere maggiori risorse (RAM & CPU).

Se avessi disegnato un unico POD, l’aumento delle risorse coinvolgerebbe entrambe le applicazioni, andando di fatto a non ottimizzare il dispendio energetico.

Nota 1: Le risorse CPU & RAM sono assegnate durante la creazione del POD.

E’ sempre meglio creare più POD?

Quest’ultima affermazione non è allineata con la politica di resilienza di K8s, dove i POD dovrebbero girare su host fisici differenti (k8s è un cluster).

Per risolvere la dipartita, esista una buona regola:

Se il servizio funziona correttamente anche se i POD sono distribuiti su più host, allora è meglio utilizzare più POD (figura 2).

La Figura 4 mostra il contenuto del file mysql-pod.yaml che crea il POD per l’applicazione mySQL.

Figura 4

Vediamo la sintassi di base di gestione del POD:

Per avviarlo è sufficiente lanciare il comando: kubectl apply -f mysql-pod.yaml
Per verificarne lo stato: kubectl get pods
Per ottenere tutti i dettagli: kubectl describe pods some-mysql
Se volessimo cancellarlo: kubectl delete -f mysql-pod.yaml

Per oggi è tutto a tra poco dove parleremo di Accesso al POD, come copiare files e tanto altro ancora.

A presto

Lascia un commento Annulla risposta

14 Settembre 20215 Ottobre 2021 di gabriele pelizzari

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