Sgomberiamo il campo da ogni tipo di equivoco: Kubernetes è una tecnologia complessa. Non è solo un’impressione che gli utenti alle prime armi avvertono, è un sentimento condiviso anche da chi Kubernetes lo conosce bene, come Tim Hockin, che il progetto lo ha fondato.

È inutile pensare che con 4 click su una qualsiasi delle piattaforme fornite dai più comuni provider è possibile avere un cluster Kubernetes perfettamente funzionante, tutto vero e nulla da eccepire, ma per capire questa tecnologia non si può prescindere dallo sporcarsi le mani. Di nuovo, questa non è un’impressione, è cosa risaputa, almeno se si è sentito parlare di Kubernetes The Hard Way.

Lungi da questo articolo il voler in alcuna maniera avvicinarsi al mirabile lavoro di Kelsey Hightower, ma perseguendo il nostro mantra e l’hashtag che identifica la costante battaglia #abbassoilcomplesso, ecco Kubelab, un progetto open-source di un ruolo Ansible per installare e gestire un cluster Kubernetes.

Perché Kubelab

Esistono decine, se non centinaia di ruoli Ansible che permettono di raggiungere gli stessi risultati di Kubelab, su tutti Kubespray che è parte del progetto Kubernetes stesso ed è un insieme di playbook Ansible per installare e gestire un cluster K8s, quindi perché Kubelab?

Kubelab nasce da un’esigenza didattica. Precisamente per fare sì che gli studenti che partecipano al corso Kubernetes From Scratch possano capire cosa comporta l’installazione di Kubernetes in maniera rapida e comprensibile.

Il corso è stato sviluppato in Kiratech, l’azienda per cui lavoro ed in cui mi occupo di dirigere, sviluppare ed erogare i training, ed è ormai più di un anno che clienti da tutta Italia ci stanno dando feedback molto positivi.

In cosa consiste Kubelab

Kubelab è un ruolo Ansible che consente, una volta debitamente compilato l’inventario delle macchine di destinazione, di automatizzare mediante l’utilizzo del comando ansible-playbook l’installazione di un cluster Kubernetes con una serie di caratteristiche decise dall’utente.

Il progetto è composto da due principali elementi:

• Il repository GitHub: https://github.com/mmul-it/kubelab
• Il ruolo Ansible Galaxy: https://galaxy.ansible.com/ui/standalone/roles/mmul/kubelab/

Così come KPA – Knowledge Pods Approach, il progetto per la generazione e la gestione del materiale relativo ai corsi di cui avevamo parlato qualche tempo fa, anche Kubelab è un progetto totalmente open-source al quale è possibile collaborare e contribuire liberamente.

Come si usa Kubelab

Preparazione dell’ambiente operativo

Kubelab è un ruolo Ansible, ed il modo più rapido per configurare il proprio ambiente in modo da poter utilizzare Ansible è quello di creare un ambiente virtuale Python, che quindi lascerà immutato il proprio sistema, lavorando su una directory locale:

user@lab ~ # python3 -m venv ansible

user@lab ~ # source ansible/bin/activate

(ansible) user@lab ~ # pip3 install ansible
Collecting ansible
  Using cached ansible-7.5.0-py3-none-any.whl (43.6 MB)
...
...
Installing collected packages: MarkupSafe, jinja2, PyYAML, pycparser, cffi, cryptography, resolvelib, packaging, ansible-core, ansible
Successfully installed MarkupSafe-2.1.3 PyYAML-6.0.1 ansible-6.7.0 ansible-core-2.13.13 cffi-1.16.0 cryptography-41.0.7 jinja2-3.1.2 packaging-23.2 pycparser-2.21 resolvelib-0.8.1

Nell’esempio qui sopra, una volta che l’ambiente virtual Python è stato creato nella cartella ansible, viene attivato mediante source e da quel momento, come si nota dal prompt (ansible) user@lab ~ #, quanto verrà installato mediante pip3 rimarrà nella cartella locale.

Nel momento in cui il pacchetto ansible è stato installato con successo, è possibile utilizzare il comando ansible-galaxy, per scaricare il ruolo mmul.kubelab, il cuore operativo che consentirà di raggiungere lo scopo prefissato:

(ansible) user@lab ~ # ansible-galaxy install mmul.kubelab -p ansible/roles/
Starting galaxy role install process
- downloading role 'kubelab', owned by mmul
- downloading role from https://github.com/mmul-it/kubelab/archive/main.tar.gz
- extracting mmul.kubelab to /home/rasca/ansible/roles/mmul.kubelab
- mmul.kubelab (main) was installed successfully

Kubelab porta con se alcuni requisiti tanto per i moduli Python utilizzati, quanto per le collection Ansible.

A livello di Python questi sono racchiusi all’interno del file ansible/roles/mmul.kubelab/requirements.txt mentre a livello di collezioni Ansible si trovano in ansible/roles/mmul.kubelab/collections/requirements.yml. Sfruttando i comandi appositi:

(ansible) [user@lab ~]$ pip3 install -r ansible/roles/mmul.kubelab/requirements.txt 
...
...
Installing collected packages: ansible-vault, certifi, pyasn1, pyasn1-modules, rsa, cachetools, google-auth, websocket-client, six, python-dateutil, urllib3, oauthlib, idna, charset-normalizer, requests, requests-oauthlib, kubernetes, jmespath
Successfully installed ansible-vault-2.1.0 cachetools-5.3.2 certifi-2023.11.17 charset-normalizer-3.3.2 google-auth-2.25.2 idna-3.6 jmespath-1.0.1 kubernetes-28.1.0 oauthlib-3.2.2 pyasn1-0.5.1 pyasn1-modules-0.3.0 python-dateutil-2.8.2 requests-2.31.0 requests-oauthlib-1.3.1 rsa-4.9 six-1.16.0 urllib3-1.26.18 websocket-client-1.7.0

(ansible) [user@lab ~]$ ansible-galaxy collection install -r ansible/roles/mmul.kubelab/collections/requirements.yml 
Starting galaxy collection install process
Process install dependency map
Starting collection install process
...
...
kubernetes.core:2.4.0 was installed successfully
...
community.general:8.1.0 was installed successfully

Generazione di un inventario

Per lanciare il playbook Kubelab è necessario venga definito l’insieme delle macchine che comporranno il cluster Kubernetes, nella pratica quindi è necessario definire un inventario Ansible che risiederà in una cartella accessibile dai playbook, chiamata ad esempio inventory al cui interno verrà creata la sotto cartella group_vars:

(ansible) [user@lab ~]$ mkdir -pv inventory/group_vars
mkdir: created directory 'inventory'
mkdir: created directory 'inventory/group_vars'

Il laboratorio su cui questo articolo si basa è composto da quattro macchine, tre che serviranno da control-plane ed una che servirà da worker, per ottimizzare la potenza di erogazione del cluster questo verrà configurato affinché le macchine control-plane possano erogare anche Pod non infrastrutturali, generalmente infatti i nodi control-plane sono dedicati unicamente a svolgere la funzione di gestione del cluster erogando solo Pod che sono appunto definiti infrastrutturali.

Quanto descritto si traduce nel file inventory/hosts in questo contenuto:

# Kubernetes hosts
[kubelab]
training-kfs-kubelab-1 k8s_role=master run_non_infra_pods=true
training-kfs-kubelab-2 k8s_role=master run_non_infra_pods=true
training-kfs-kubelab-3 k8s_role=master run_non_infra_pods=true
training-kfs-kubelab-4 k8s_role=worker

Allo stesso tempo, le specifiche effettive del cluster saranno inventory/group_vars/kubelab.yml:

k8s_local_workdir: "~/training-kfs-kubelab"

k8s_cluster_name: training-kfs-kubelab
k8s_master_node: training-kfs-kubelab-1

k8s_multi_master: true
k8s_balancer_VIP: 192.168.99.199
k8s_balancer_port: 8443
k8s_balancer_password: "training-kfs-kubelab"

k8s_wait_timeout: 1200

k8s_master_ports:
  - 2379-2380/tcp
  - 6443/tcp
  - 8443/tcp
  - 10250/tcp
  - 10257/tcp
  - 10259/tcp

# Flannel addon
k8s_network_addon: flannel
k8s_network_addon_ports:
  - 8285/udp
  - 8472/udp

Sono molte in questo caso le opzioni dichiarate, e dipendono dalla conformazione che avrà il cluster una volta installato, ma in sintesi il cluster avrà un VIP (Virtual IP) che sarà 192.168.99.199 e che bilancerà sulla porta 8443 l’accesso ai tre nodi control-plane. L’add-on di rete sarà Flannel, ma Calico, così come potenzialmente qualsiasi network add-on, è supportato.

Ciascuna sezione, così come il supporto a componenti aggiuntivi è consultabile dalla pagina del progetto. Nello specifico:

• Creazione dell’Inventario
• Configurazione del Cluster
• Gestione dei Network Add-on
• Abilitazione Dashboard
• Gestione degli Utenti
• Configurazione dello storage Ceph CSI
• Abilitazione di MetalLB
• Abilitazione di Ingress NGINX
• Abilitazione di Cert Manager

Esecuzione del playbook

Una volta predisposto l’ambiente e definito l’inventario, il lancio del playbook è la cosa più semplice in assoluto:

(ansible) [user@lab ~]$ ansible-playbook -i inventory ansible/roles/mmul.kubelab/tests/kubelab.yml 

PLAY [Create a Kubernetes cluster using kubelab Ansible role] ********************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************
ok: [training-kfs-kubelab-3]
ok: [training-kfs-kubelab-1]
ok: [training-kfs-kubelab-2]
ok: [training-kfs-kubelab-4]

...
...

PLAY RECAP ***********************************************************************************************************************************************
training-kfs-kubelab-1     : ok=52   changed=37   unreachable=0    failed=0    skipped=31   rescued=0    ignored=0   
training-kfs-kubelab-2     : ok=39   changed=30   unreachable=0    failed=0    skipped=37   rescued=0    ignored=0   
training-kfs-kubelab-3     : ok=39   changed=30   unreachable=0    failed=0    skipped=37   rescued=0    ignored=0   
training-kfs-kubelab-4     : ok=31   changed=23   unreachable=0    failed=0    skipped=45   rescued=0    ignored=0

Chiaramente tutte le macchine remote dovranno essere raggiungibili via SSH dall’host presso cui si è avviato il playbook, mediante chiave e con possibilità di innalzamento dei privilegi dell’utente a root mediante sudo.

Accesso al cluster

Per accedere al cluster appena installato sarà necessario installare lo strumento kubectl:

user@lab ~ $ curl -s -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

user@lab ~ $ chmod +x kubectl && sudo mv kubectl /usr/local/bin

E puntare poi al cluster appena installato mediante il file creato dal playbook Ansible training-kfs-kubelab/admin.conf (la directory è stata definita nella variabile k8s_local_workdir del file inventory/group_vars/kubelab.yml) che contiene le informazione dell’utente kubeadmin, l’amministratore:

user@lab ~ $ export KUBECONFIG=~/training-kfs-kubelab/admin.conf

Da qui in poi, la palestra potrà dirsi aperta:

user@lab ~ $ kubectl cluster-info
Kubernetes control plane is running at https://192.168.99.199:8443
CoreDNS is running at https://192.168.99.199:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

user@lab ~ $ kubectl get nodes
NAME                     STATUS   ROLES           AGE   VERSION
training-kfs-kubelab-1   Ready    control-plane   14m   v1.28.2
training-kfs-kubelab-2   Ready    control-plane   13m   v1.28.2
training-kfs-kubelab-3   Ready    control-plane   12m   v1.28.2
training-kfs-kubelab-4   Ready    <none>          12m   v1.28.2

Come Kubelab aiuta gli studenti

Raccontare o fare dimostrazioni per un istruttore è molto utile, ma la vera differenza in termini di apprendimento avviene quando uno studente può mettere mano per conto proprio ai sistemi, vedere cosa succede e provare a capire come risolvere i problemi, se ce ne sono stati.

Il ruolo Kubelab consente di isolare in maniera chiara quelle che sono le fasi dell’installazione di Kubernetes, le azioni cioè che vengono eseguite su tutti i nodi, quelle che riguardano solamente i nodi control-plane, e quelle che invece riguardano solo i nodi worker.

L’idea è quella di partire con una visione aerea, per poi abbassarsi il più possibile verso quello che è il dettaglio, fino ad arrivare ad isolare le singole operazioni che avvengono durante l’installazione di Kubernetes.

Conclusioni

Kubelab è un modo veloce, ripetibile, affidabile e comprensibile per acquisire competenze su una tecnologia che è sì complessa, ma domabile.

Da sempre infatti, si tratti del lavoro in Mia Mamma Usa Linux o di quello in Kiratech, la missione è sempre quella: abbattere la complessità.

Farlo utilizzando l’open-source, beh ha tutto un altro sapore.

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.