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

NUC upgrade to ESXi 7.0.1 – Part 2

Phase 2: Upgrading ESXi Host

In the previous article, I described how to prepare a customized ISO. If you lost it please click on this link.

Let’s continue!

Requirements: the task I performed before starting the procedure here described has been the vCenter upgrade to 7.0.1-c. I remind you that my starting point was Esxi 7.0.0.b that is fully supported by vCenter 7.0.1-c.

There are two main ways to upgrade the ESXi Hosts.

The first is related to the use of a VMware feature. It’s the vSphere Lifecycle Manager (vLCM) and you can taste part of its potential by watching this video guide.

Instead, I preferred to use an old approach working with a bootable USB pen with the custom ISO prepared in the previous article. The steps are:

1. Shutdown ESXi Hosts
2. Remove the USB-NIC
3. Insert the Pen Drive with custom ISO
4. Upgrade the host following the wizard (The main point is shown in Picture 1)

Picture 1

5. Reboot the host.

6. Now it’s time to install the USB-Nic Driver. It is available from “USB Network Native Driver for ESXi” web site and this article allows me to say thx to the excellent job of  Songtao Zheng and William Lam

Before proceeding please read the instruction carefully and DO NOT insert all the USB cards together. (I have got three USB-NIC cards)

Why? Because during the procedure, I have had more than one purple screen and after a deep analysis I discovered that it depended on the USB-NIC cards.

To get over this issue I created the following procedure.

Picture 2

7. Switch off the ESXi NUC and insert the first USB-NIC card in port-1 and the second in port-4 (please refer to picture 2 to know the nomenclature of the port)

8. Now switch on the NUC and check if it boots correctly.

9. Switch off the NUC and insert the third USB-NUC on port-2.

10. Reboot NUC and check if it works as aspected.

Before ending this article I suggest creating a map between vmks and the physical MAC Address of the USB NIC. The main advantage is that it allows maintaining the same vmkusb address after a reboot also.

Some useful commands:

To Identify the Mac Address:
# esxcli network nic list |grep vusb |awk ‘{print $1, $8}’

To Check persisting binding:
# esxcli system module parameters list -m vmkusb_nic_fling

NUC upgrade to ESXi 7.0.1- Part 1

Last weekend I upgraded all my Servers to the last VMware ESXi release (7.0.1 C) and this article is meant to describe all steps I performed.

Just a recommendation before starting. I worked in my lab that it’s not a production environment.

MyLAB before upgrade:

  1. NUC8i7beh2
  2. VMware ESXi 7.0.0 (Build 16324942)
  3. Every NUC has three more network cards added to the embedded standard NIC. They have been obtained through the USB ports leveraging three adapter USB/Ethernet and the flings driver.  Please refer to the FLINGS website to get all info.

The procedure is composed of two main phases and this article will cover the first part.

Phase 1: Creating a customize ISO

Is this step required?

Oh well, it depends if the Standard ESXi VMware ISO has already the driver of your embedded network card inside. The standard ISO, unfortunately, does not contain the NUC8i7BEH network drive (it is named ne1000)

If you upgrade the ESXi through the standard ISO, the process fails with the error shown in picture 1.

Picture 1

How to get over it?

Before upgrading it, it’s necessary to know the driver used by the embedded NIC Card. If you don’t know it, please read the next instructions carefully (they are command launched on host ESXi you are going to upgrade):

1.   lspci -v | grep -A1 -i ethernet
take a note of the string composed of 4:4 values ( xxxx:yyyy)

2.   lspci -n | grep xxx:yyy
take a note of how the nic is named (in my case [vmnic0])

The next step is getting the name of the driver directly from the VMware website (Matrix compatibility).

From that web page, filling up the empty field with the value yyyy and filtering the result by IO Devices, it’s possible to get the device driver name.

For my LAB the result is shown in picture 2 where I highlighted the device driver name in yellow.

Picture 2

The last command to check if the driver is already installed (It should be present) is:

3.   vmkload_mod -l | grep “Device Driver”

In my case: vmkload_mod -l | grep ne1000
                          ne1000          1          352

Optional: if you use the USB ports to add more NIC, please uninstall the fling drivers before proceeding.

4.   esxcli software vib remove  –vibname=vmkusb-nic-fling (before vibname two scores –   –  )

It’s time to create our custom ISO

a- Download the offline bundle from VMware Site, for example:

VMware- ESXi-7.0U1c-17325551-depot.zip

b- Download the NUC ethernet driver for your device (ne1000 in my case).

I found an useful PowerShell script to get it:

#add the software repository
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
#define as variable the name of the driver
$vib = Get-EsxSoftwarePackage ne1000
$vib | select Name,Version | ft -AutoSize
$vib[4] | fl
#Get the driver
Invoke-WebRequest $vib[4].SourceUrls[0] -OutFile d:\pkg\ne1000_0.8.4-10vmw.700.1.0.15843807.vib

c- The PowerShell script to create a custom ISO is available on VMware Front Experience Site.

This great script has a lot of options; please refer to the official documentation to see how to create the ISO.

In my case I just launched the following command:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v701 -izip D:\ISO\ESXi-7-0-1\VMware-ESXi-7.0U1c-17325551-depot.zip -pkgDir D:\pkg\ -OutDir D:\ISO\ESXi-7-0-1\ -nsc

d- The last step is creating a bootable USB pen using the just created custom ISO as a source.

I have chosen Rufus to perform this task.

In the next article, we are going to see the final step to upgrade the NUC