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.
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.
Lascia un commento