Kubernetes: I componenti

Nei precedenti articoli abbiamo visto alcuni dettagli di come è costruita l’architettura di Kubernetes.

Oggi verranno descritti i meccanismi di funzionamento del motore kubernetes indicando il nome di  ogni componente; per rimanere fedeli al paragone del motore dell’autovettura, parleremo degli alberi a camme, valvole, bronzine, … che afferiscono al Cloud Native

Nota1: Non verrà trattata l’installazione di k8s in Datacenter, Cloud e Laboratorio, la rete ha già messo a disposizione  esaustivi tutorial.

Per i familiarizzare con k8s vi consiglio di utilizzare Minikube (Piattaforma Linux)  Docker Desktop (piattaforma Windows & Mac).

Iniziamo!

Kubernetes Master:  E’ il nodo principale del cluster sul quale girano tre processi vitali per l’esistenza del cluster.

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler

Nel master node è inoltre presente il DataBase etcd, che memorizza tutte le configurazioni create nel cluster.

I nodi che si fanno carico di far girare le applicazioni e quindi i servizi sono detti worker node. I processi presenti sui worker node sono:

  • Kubelet
  • kube-proxy

kubelet :Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.

Kube-Proxy:  Ha la responsabilità di gestire il networking, dalle regole di Routing a quelle di di Load Balancing.

Nota 2: K8s cercherà di utilizzare tutte le librerie disponibili a livello di  sistema operativo.

kubectl: E’ Il client ufficiale di Kubernetes (CLI) attraverso il quale è possibile gestire il cluster (Kube-apiserver) utilizzando le API.

Alcuni semplici esempi di comandi kubectl sono:

  • kubectl version (indica la versione di k8s installata)
  • kubectl get nodes (scopre il numero di nodi del  cluster)
  • kubectl describe nodes nodes-1 (mostra lo stato di salute del nodo, la piattafoma sulla quale k8s sta girando (Google, AWS, ….) e le risorse assegnate (CPU,RAM)).

Container Runtime: E’ la base sulla quale poggia la tecnologia k8s.

kubernetes supporta diverse runtime tra le quali ricordiamo, container-d, cri-o, rktlet.

Nota 3: La runtime Docker è stata deprecata a favore di quelle che utilizzano le interfacce CRI; le immagini Docker continueranno comunque a funzionare nel  cluster.

Gli oggetti base di Kubernetes sono:

  • Pod
  • Servizi
  • Volumi
  • Namespace

I controller forniscono funzionalità aggiuntive e sono:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job

Tra i Deployment è indispensabile menzionare  Kube-DNS che fornisce i servizi di risoluzione dei nomi. Dalla versione kubernetes 1.2 la denominazione è cambiata in Core-dns.

Add-On: servono a configurare ulteriori funzionalità del cluster e sono collocati all’interno del name space kube-system (come Kube-Proxy, Kube-DNS, kube-Dashboard)

Gli Add-on sono categorizzati in base al loro utilizzo:

  • Add-on di Netwok policy. (Ad esempio l’add-on NSX-T si preoccupa della comunicazione tra l’ambiente K8s e VMware)
  • Add-on Infrastrutturali (Ad esempio KubeVirt che consente la connessione con le architetture virtuali)
  • Add-on di Visualizzazione e Controllo (Ad esempio Dashboard un’interfaccia web per  K8s).

Per la messa in esercizio, gli Add-on utilizzano i controller DaemonSetDeployment.

L’immagine di figura 1 riepiloga quanto appena esposto.

Figura 1

Kubernets: Conoscere i dettagli

Una buona modalità per descrivere gli ambient cloud-native è rifarsi all’immagine della vostra autovettura.

Il container è il motore, k8s è la centrale elettronica che gestisce il buon funzionamento del mezzo, i conducenti, indicando il percorso e la meta, selezionano il tipo di servizio che dovrà essere erogato.

L’articolo di oggi vi svelerà alcuni dettagli di architettura per comprendere come “l’automobile” riesce a giungere la destinazione in modalità efficente.

I Container sono di due tipologie:

Il primo è detto System Container. E’ la carrozzeria dell’autovettura (intendo dalle lamiere a sedili, volante, leva del cambio e accessori).

Spesso per semplicità di creazione è una Virtual Machine (VM) con sistema operativo Linux (può essere anche Windows).

I servizi più comuni presenti nella VM sono  ssh, cron e syslog, il File System è di tipo ext3, ext4, ecc.

La seconda tipologia è detta Application Container ed è il luogo dove l’immagine realizzerà le attività.

Nota1: L’immagine non è un singolo e grosso file. Di norma sono più file che attraverso un sistema interno di puntamento incrociato permettono all’applicazione di operare nel modo corretto.

L’application Container (d’ora in avanti solo container), ha una modalità di funzionamento basata su una rigida logica, dove tutti livelli (layers) hanno la peculiartità di comunicare tra loro e sono interdipendenti.

    Figura 1

Questo approccio è molto utile poiché è in grado di gestire i cambiamenti che possono avvenire nel corso del tempo in modalità efficace perchè gerarchica.

Facciamo un esempio: Nel momento in cui avviene un cambio di configurazione del servizio, per il quale viene aggiornato il Layer C, il Layer A e B non ne sono impattati, il che significa che NON devono essere a loro volta modificati.

Visto i Developer hanno piacere nell’affinare le proprie immagini (program file) piuttosto che le dipendenze, ha senso impostare la logica di servizion nella modalità indicata in figura 2 dove le dipendenze non sono impattate da una nuova immagine.

    Figura 2

Nota2 : Il File system sul quale si appoggiano le immagini (nell’esempio del motore dell’auto parliamo di pistoni, bielle, alberi …) è principalmente di tre differenti tipologie:

  • Overlay
  • Overlay 2
  • AUFS

Nota3: Un buon consiglio lato sicurezza è quello do non costruire l’architettura in modo che le password siano contenute nelle immagini (Baked in – Cucinata)

Una delle splendide novità introdotte nel mondo containers è la gestione delle immagini:

In un ambiente classico di alta affidabilità, l’applicazione viene installata su ogni singolo nodo del cluster.

Nei container, l’applicazione viene scaricata e distribuita solo quando il carico di lavoro richiede maggiori risorse, quindi un nuovo nodo del cluster con una nuova immagine.

Per questo motivo le immagini sono salvate all’interno di magazzini  “virtuali”,  che possono essere locali oppure distribuiti su internet. Sono chiamati  “Register Server”.

I più famosi sono Docker Hub, Google Container Registry, Amazon Elastic Container Registry, Azure Container Registry.

Concludiamo il presente articolo parlando di gestione delle risorse associate ad un servizio.

La piattaforma container utilizza due funzionalità denominate Cgroup e NameSpace per assegnare le risorse che lavorano a livello di kernel.

Lo scopo del Cgroup è di assegnare allo specifico processo (PID) le corrette risorse (CPU&RAM).

I Name space hanno lo scopo di ragguppare i differenti processi e fare in modo che siano isolati tra loro (Multitenancy).

La tipologia di NameSpace puo interesare tutti i componenti del servizio come indicato nella lista qui sotto.

  • Cgroup
  • PID
  • Users
  • Mount
  • Network
  • IPC (Interprocess communication)
  • UTS (consente a un singolo sistema di apparire con nomi di host e domini diversi e con processi diversi, utile nel caso di migrazione)

Un esempio di limitare le risorse di un’applicazione è indicata nella figura 3 dove l’immagine thegable, scaricata dal Register Server grcgp,ha un limite di risorse RAM e CPU assegnate.

Figura 3

A presto

Cloud Native Kubernetes: Flusso e opportunità di lavoro

Questo nuovo articolo vuole indicare le nuove opportunità di lavoro create da un ambiente cloud-native.

L’immagine n°1 mostra i quattro livelli principali necessari all’architettura per funzionare correttamente (parte rettangolare sinistra).

Sul lato destro (cerchi) sono rappresentati le occupazioni dell’operatore rispetto ad ogni singolo livello.

Immagine 1

Dal basso verso l’alto:

1- Gli Storage and Network Operator (SNO) hanno la responsabilità di gestire l’architettura hardware.

Il numero dell’attività del ruolo può diminuire in caso di implementazione in un cloud pubblico o IaaS (Infrastructure as a Service)

2- L’Operatore del sistema operativo (OSO) lavora al livello del sistema operativo in cui viene eseguito il servizio k8s.

L’OSO ha bisogno di competenza in Linux e Windows. Sono spesso richieste competenze nell’architettura di virtualizzazione come VMware, RedHat, Nutanix, ecc.

Se l’architettura è stata affittata dal cloud pubblico o in generale in un IaaS, le competenze devono coprire questa nuova architettura.

3- L’operatore di orchestrazione (OO) lavora con il nucleo dell’ambiente di amministrazione cloud-native. Questo mondo ha bisogno di molte nuove abilità.

L’automazione è il figlio dell’orchestrazione.

Il concetto principale è che l’OO dovrebbe avere competenze sufficienti per riuscire a seguire tutti i processi di “Integrazione Continua” e “Consegna Continua” (spesso chiamata CI/CD).

L’immagine 2 dà un’idea a riguardo

Le frecce centrali mostrano il flusso per consentire l’erogazione di un servizio.

Per ogni singola freccia ci sono nuovi strumenti da conoscere per gestire l’intero rilascio del servizio.

Solo alcuni esempi: per testare l’ambiente è possibile lavorare con cetriolo o Cypress.io, per la distribuzione e la costruzione è possibile utilizzare Jenkins… e così via…

Immagine 2

Nota 1: ci sono così tante piattaforme disponibili che la scelta di quella giusta potrebbe essere molto impegnativa

4- L’operatore di sviluppo è il ruolo delle persone che sono scritte righe di codice. Spesso usano software per gestire attività come Jira Core e Trello.

Nota 2: A mio parere personale, il fornitore che crea un livello software in grado di gestire centralmente tutte queste 6 attività principali avrà un vantaggio competitivo rispetto ai concorrenti.

I grandi fornitori stanno già giocando: RedHat sta lavorando dall’inizio con la sua piattaforma (OpenStack), VMware ha rilasciato Tanzu, Nutanix con Carbonite e Microsoft giocherà il suo ruolo con la nuova versione di Windows 2022.

L’unico buon suggerimento che posso darti è quello di studiare questo nuovo e fantastico mondo.

A presto e abbi cura di te

Modern Applications – Episod 4: Docker Compose – YAML

The topic of this article is understanding how to automatize the delivery of a micro-service.

In the previous one, I showed the flow process of a service. This flow requires typing a lot of commands to launch any single container.

Is there a way to automatize the entire process making it easier?

Yes, Docker-compose is a tool for defining and running an environment multi-container.

Docker-compose works with a describing file that includes all the configurations. The file has the extension YAML (human-readable data-serialization language).

After writing the YAML file (in this example it is named mypersonalfile.yaml), the syntax of the command is:

docker-compose -f mypersonalfile.yaml

Let’s see an easy example using the article I wrote in the last episode as a source.

I had to type all these commands to implement the service:

a. Mongo DB commands

b. Mongo Express commands

In their place,  it’s possible to use the following yaml file.

mypersonalfile.yaml

We will find yaml files again when writing about Kubernetes architecture and its protection.

That’s all for now, take care guys

Modern Applications – Episod 3: Service workflow

The first two articles explained what a container is (article 1) and how they can talk to each other (article 2).

In this third article, I’m going to show how to deploy a service through this new and amazing container technology.

Note 1: I won’t cover the image flow deployment part (Git – Jenkins, Docker repository, and so on) because my goal is to explain how to implement a service, not how to write lines code.

Main Point:

  • As many of you already know, a service is a logical group of applications that talk to each other
  • Every single application can run as an image
  • Any image can run to a container
  • Conclusion: Deploying container technology is possible to build up any service

An example could clarify the concept.

Example: Web application

A classical web application is composed of a Front-End, a Back-End, and a DB.

In the traditional world, every single application runs on a single server (virtual or physical it doesn’t matter).

This old scenario required to work with every single brick of the wall. It means that to design correctly the service the deployers and engineers have to pay attention to all the objects of the stack, starting from OS, drivers, networks, firewall, and so on.

Why?

Because they are a separate group of objects that need a compatibility and feasibility study to work properly together and they require great security competencies also.

Furthermore, when the service is deployed and every single application is going to be installed, it often happens that remote support from the developer team is required. The reason is that some deployment steps are not clear enough just because they are not well documented (developers are not as good at writing documentation as they are at writing codes). The result is that opening a ticket to customer service is quite normal.

Someone could object and ask to deploy a service just using one server. Unfortunately, it doesn’t solve the issue, actually, it amplifies it up just because in that scenario, it’s common to meet scalability problems.

Let’s continue our example by talking about the architecture design and the components needed (Picture 1)

Picture 1

Note 2: In the next rows, I will skip how to deploy the front and backend architecture as well as the docker technology because:

  • Writing HTML and Javascript files for creating a website is quite easy. On Internet, you can find a lot of examples that will meet your needs.
  • Node.js is a very powerful open-source product downloadable from the following website where it’s possible to get all the documentation needed to work with it.
  • Docker is open-source software; it can also be downloaded from the official open-source website. The installation is a piece of cake.

My focus here is explaining how to deploy and work with docker images. Today’s example is the Mongo DB and Mongo Express applications.

I wrapped up the steps in 4 main stages:

a. First point: Creating a Network

It allows communication from and to the images.

In our example, the network will be named “thegable-network”.

From the console (terminal, putty….) just run the following commands:

b. Download from docker hub the images needed

c) Running the mongo DB image with the correct settings:

d) Run the mongo-Express image with the correct settings:

Note 3: The configurable settings are available directly from the docker images.

For example, to mongo-express, picture 2  shows the common settings. (https://hub.docker.com/_/mongo-express)

Picture 2

Connecting to the main web page of mongo-express (localhost: port), have to appear the mongo default Databases  as shown in picture 3

Picture 2

Now creating new Mongo DBs (through the Mongo-Express web interface just for example create the DB named “my-GPDB“) and managing your javascript file, it’s possible to build up your own web application.

In the javascript file (normally is named server.js) the main points to connect to the DB are:

(Please refer to a javascript specialist to get all details needed)

Is it easy? Yes, and this approach allows having a fast and secure deployment.

In just a word, it is amazing!

That’s all folks for now.

The last article of this first series on modern applications is Docker Compose

See you soon and take care