CKAD: un percorso verso Kubernetes che parte da zero

Come abbiamo organizzato gli incontri?

La gilda si è riunita tutti i lunedì pomeriggio per 4 mesi, in presenza.

Durante ogni appuntamento seguivamo il corso e al termine di ogni lezione discutevamo di eventuali dubbi e perplessità. Quando il corso proponeva esercitazioni, ci alternavamo alla tastiera in modo da poter dare a tutti la possibilità di mettersi alla prova.

Circa a metà percorso abbiamo deciso di fare una retrospettiva, per condividere considerazioni e migliorare quello che sarebbe stato il prosieguo della gilda.

Per concludere i nostri incontri abbiamo deciso di dedicare 10-15 minuti per la stesura del journal. Il journal è una pratica che prevede, solitamente al termine di una giornata lavorativa, la scrittura di una sorta di “diario di bordo” dove ciascun membro di un team ha la possibilità di raccontare ciò che è stato fatto durante il giorno. Uno dei principali vantaggi di questa pratica è di permettere a tutti di essere costantemente allineati su avvenimenti che altrimenti difficilmente sarebbero stati condivisi.
Nel journal può essere utile (anzi, talvolta è consigliato) entrare nei dettagli tecnici del lavoro che si sta svolgendo, in questo modo gli altri componenti hanno la possibilità di conoscere meglio un argomento!

Vorremo qui riportare il nostro journal (o parte di esso) per condividere il nostro percorso:

• 22/09/2021 – Pilot
• 27/09/2021 – When Harry met YAML
• 4/10/2021 – To deploy or not to deploy, that is the question
• 11/10/2021 – Cluster away
• 18/10/2021 – I Fantastic i3
• 25/10/2021 – Amarsi un po’(d)
• 05/11/2021 – V for Variables (Remember, remember, the ConfigMap of November)
• 08/11/2021 – The Hateful KubernEight
• 15/11/2021 – Avengers: Affinity war
• 22/11/2021 – Il mio grosso Ingress matriMonitoring greco
• 29/11/2021 – Ingress and the city
• 06/12/2021 – 308: Non esponete quell’ingress
• 13/12/2021 – Scuola di Policies – PersistentVolume II
• 20/12/2021 – Scavicchi ma non apra
• 28/12/2021 – Un pod per due
• 04/01/2022 – Prince of Kubernatis e le sabbie del tempo

Buona lettura e buon divertimento!

22/09/2021 – Pilot

Setup: Microsoft Teams per chiamata & condivisione schermo (con, se possibile, utilizzo di speaker più microfono esterno).

Durante la visione dei corsi: condivisione di schermo e audio; mentre guardiamo il corso, tenere il microfono mutato.

Ci siamo confrontati sulle nostre attuali competenze su k8s, poi abbiamo iniziato il corso CKAD avanzato sulla piattaforma Udemy curato da KodeKloud. Nell’introduzione ci siamo resi conto che, prima di completare questo corso, sarebbe stato opportuno fare il corso per “beginners” in modo da essere tutti allineati.

Delle 12 sezioni del corso abbiamo completato le prime 5 che coprono i seguenti argomenti:

• Introduzione e overview di Kubernetes
• Minikube
• Concetti fondamentali nel mondo k8s (nodi, container, pod, cluster)

Tutti noi abbiamo installato sulle nostre macchine Minikube e verificato il corretto funzionamento.

Curiosità e comandi

• Un pod può avere al suo interno più CONTAINER, anche se molto spesso se ne usa uno solo (eventuali altri container possono essere usati per servizi accessori, ad esempio per il controllo delle autorizzazioni e il logging).
• minikube start
• kubectl get pods
• kubectl get nodes [ -o wide ]
• kubectl get deployments
• kubectl run pod_name --image=image_name
• kubectx ⬅ mostra il contesto corrente
• kubens ⬅ mostra il namespace corrente

27/09/2021 – When Harry met YAML

Abbiamo continuato la visione il corso beginner iniziato la volta scorsa. Dopo una breve spiegazione sul funzionamento del formato YAML, abbiamo analizzato la struttura dei file YAML di: pod, replicaset e deployments (e relativi comandi kubectl).

Il corso offre sia lezioni in formato “quiz” sia l’accesso a una piattaforma chiamata Kodekloud.com dove è possibile accedere a un terminale ed eseguire comandi su un cluster k8s.

Ogni domanda presente neu quiz può avere fino a 6 risposte (o solo un tasto “Check”): dopo aver dato i comandi opportuni bisogna selezionare la risposta giusta, oppure premere il tasto Check per controllare l’esito delle operazioni.

Per quanto riguarda le lezioni “quiz” (in particolare quelle del corso, non quelle interattive su KodeKloud), E’ NECESSARIO PREMERE “CONTROLLA SOLUZIONE”, ALTRIMENTI NON VIENE CONTROLLATA!! (Imparato a nostre spese…)

Per accedere al “lab” della piattaforma KodeKloud bisogna creare un account e attivare il lab collegato al corso usando il codice che viene indicato (va aggiunto al carrello e il codice azzera il prezzo).

P.S.: Ma quanto è stato utile l’articolo del nostro CTO Alex Mufatti?

Curiosità e comandi

• Formato YAML Kubernetes:
  • apiVersion (es. v1, apps/v1)
  • kind (es.: pod, Service, ..)
  • metadata (un dictionary con chiavi fisse, fra cui name e label)
  • spec (un dictionary)
• Tricks & tips Bash (dall’articolo di Alex)
  • !! ⬅ ripeti ultimo comando
  • !-5 ⬅ ripeti il quintultimo comando
  • ^string1^string2 ⬅ ripeti il comando precedente rimpiazzando “string1” con “string2”
• Comandi
  • kubectl apply -f nomefile.yaml
  • kubectl get replicationcontroller
  • kubectl get replicasets
  • kubectl delete replicaset ilSuoNome
  • kubectl replace -f nomefile.yaml
  • kubectl scale --replicasB -f nomefile.yaml
  • kubectl scale replicaset --replicasB ilSuoNome
  • kubectl edit replicaset ilSuoNome
  • kubectl get all

4/10/2021 – To deploy or not to deploy, that is the question

In questo incontro abbiamo visto cos’è un deployment in Kubernetes, come funziona e in particolare come gestisce l’aggiornamento (default: “rolling update”, in alternativa “delete update” che però causa dei momenti di down dell’applicazione).

Dopo aver svolto un’esercitazione offerta dal corso siamo passati a trattare i networks e services, in particolare:

• Gestione indirizzi IP per nodi, pod ecc…
• Comunicazione tra i vari pod (attraverso i service).
• Non è necessario un service se il pod in questione non necessita di essere esposto.
• I pod possono comunicare tra di loro all’interno del nodo.
• I vari tipi di service (NodePort, ClusterIP, Load Balancer).
• Rolling update vs delete update.

Abbiamo anche visto una demo di utilizzo di Minikube per avere l’infrastruttura di un’applicazione in locale. L’applicazione in questione è disponibile su git, ed è possibile utilizzarne le immagini Docker già presenti su Docker Hub.

L’idea sarebbe quella di replicare la demo in locale per fissare meglio i concetti ed evitare di rifare le cose semplicemente copiando e incollando il codice.

Curiosità e comandi

• In Vim per cancellare n righe tutte insieme, si può precedere il comando dd con il numero n, eseguendo così dd per n volte.
• I sottotitoli del corso sono autogenerati, la qualità lascia a desiderare (ma alcuni strafalcioni sono divertenti).

11/10/2021 – Cluster away

Riviste alcune lezioni in modo da essere tutti allineati (tutta la sezione dei services e la demo con cui ci siamo lasciati l’incontro precedente).

Dopo aver visto l’episodio della demo abbiamo provato a replicare il tutto, cercando di “sbirciare” il meno possibile (abbiamo ottenuto ottimi risultati, addirittura alcune cose sono partite al primo colpo contro ogni pronostico!).

Tutto il lavoro pratico di oggi si trova su un nuovo repository che abbiamo creato sulla pagina GitHub di Intré.

L’idea è quella di eseguire in locale due applicazioni frontend: una tramite la quale viene effettuato un voto a un sondaggio e l’altra che semplicemente visualizza il risultato. Ecco un’immagine che spiega l’architettura dell’esercizio:

Purtroppo non abbiamo fatto in tempo a concludere la demo, ma l’obiettivo del prossimo incontro sarà proprio quello di portarla a termine!

Dopodiché ipotizziamo di iniziare il corso Kubernetes avanzato, che dovrebbe prepararci per davvero alla certificazione!

Curiosità e comandi

• Si può usare il comando kubectl anche su intere folder: kubectl apply -f <folder>
  • L’apply non funziona su tutto ma solo su alcuni campi. Per esempio non è possibile cambiare il nome del container di riferimento di un pod.
• Il formato dei selector è diverso tra services e deployments (nei replica set c’è il matchLabels).
  • Gli elementi di k8s più recenti, come i deployments, utilizzano un’alberatura più completa (e complessa), con la key matchLabels.
• Nonostante il titolo di questo incontro, nessun pod chiamato “Wilson” è stato maltrattato!

18/10/2021 – I Fantastic i3

Riscontrata qualche difficoltà nel concludere la demo iniziata la volta precedente: il problema era nel codice del pod worker il quale necessitava di connettersi a redis attraverso un preciso nome (il nome è “redis”, ma noi il servizio l’avevamo chiamato redis-svc).

Dopodiché abbiamo iniziato il corso k8s avanzato: le prime lezioni sono dei recap di quanto visto nel corso appena concluso.

Al termine di questo incontro siamo riusciti a concludere il primo lab del corso, relativo ancora ai pod, che dà per assodati molti concetti visti nel primo corso…abbiamo fatto bene a non sottovalutarlo!

Nel prossimo incontro procederemo con la visione delle lezioni. Ci siamo posti l’obiettivo di “includere” di più le persone che partecipano da remoto alla gilda: l’idea sarebbe quella di dare maggior priorità a chi è da remoto quando bisogna fare esercizi.

Curiosità e comandi

• Avere più informazioni quando si fa la get dei pod ➡ kubectl get pod -o wide
• Creare un pod senza yaml ➡ kubectl run<nome-pod> --image=<nome-immagine>
• Al posto di scrivere pod nei comandi kubectl, si potrebbe anche scrivere pods e funziona tutto! (feature valida per tutte le risorse).
  • Inoltre: service=services=svc, replicaset=replicasets=rs
• Settare label da comando: kubectl label pod <nome> "nomelabel=valore"
• Eliminare la label: kubectl label pod <nome> nomelabel- (sì, senza apici col ‘meno’ alla fine del nome).

25/10/2021 – Amarsi un po’(d)

Siamo andati avanti con il corso: abbiamo affrontato i comandi imperativi per la creazione di vari oggetti, scoprendo che è possibile fare generare i file per poi eventualmente modificarli.

Abbiamo visto anche i namespaces e command + args in Docker e k8s.

Per il prossimo incontro l’idea è di iniziare con una breve retrospettiva: ipotizziamo una durata di circa mezz’ora. Dopodiché procederemo con il corso.

In presenza, inoltre, è tutta un’altra cosa!

Curiosità e comandi

• Esportare un replica set su file: kubectl get rs new-replica-set -o yaml > nome-file.yaml
  • Lo si può fare anche per tutti gli altri oggetti di k8s.
• Altro modo per scalare replica set: kubectl scale --replicas=<N> rs/<nome-rs&gt;
  • <tipo-elemento>/<nome-elemento> è una sintassi valida per tutti i comandi.
• Ctrl + L (o cmd + L per Mac) fa il clear del terminale, ma in modo più figo!
• kubectl get pods -n [namespace name] (-n sta per namespace)
• kubectl get pods --all-namespaces
  • Ti permette di recuperare la lista di tutti i pod e del relativo namespace.
• I service creano in automatico un dns formato così:
  [nome service].[nome namespace].svc.cluster.local =dbservice.dev.svc.cluster.local
• --dry-run
  • Permette di testare il comando senza eseguirlo veramente.
  • kubectl run nginx --image=inx --dry-run=ient -o yaml (crea lo yaml di come creare un pod senza crearlo veramente).
• Link a kubectl Cheat Sheet ➡ https://kubernetes.io/docs/reference/kubectl/cheatsheet/

05/11/2021 – V for Variables (Remember, remember, the ConfigMap of November)

Oggi abbiamo svolto una retrospettiva sulle situazioni incontrate finora come gilda. Dopo un utilissimo confronto sono risultati aspetti positivi e negativi, e abbiamo deciso alcune azioni S.M.A.R.T. a riguardo, come mostrato nell’immagine sottostante (a sinistra il problema, a destra la soluzione).

Successivamente abbiamo ripreso il corso su Udemy, seguendo le lezioni relative a:

• Variabili d’ambiente.
• ConfigMaps e Secrets, ovvero modalità per passaggio criptato di variabili d’ambiente.

P.S.: Provando a modificare Secrets e ConfigMaps con la metodologia fornita dal comando kubectl edit non ha portato a risultati positivi (“Inabilità del comando nella modifica dei file?” o semplicemente “Interferenze con l’ambiente ospitante di KodeKloud?”)

Per il prossimo incontro vorremmo riprendere con il corso, ma anche indagare il funzionamento del comando edit e valutarne il potenziale rispetto ad altre metodologie di modifica.

Curiosità e comandi

• Fare la retrospettiva ha permesso di fare conoscere a tutti alcune buone pratiche, per esempio la “Agile Prime Directive“.
• Seguendo il corso abbiamo appreso un metodo veloce per definire in codifica differita dati e valori, il comando base64.

REMINDER: utilizzare kubectl create secret generic !!! Non dimenticare generic.

08/11/2021 – The Hateful KubernEight

Dopo qualche difficoltà tecnica (“Rete? Quale rete?”) e mnemonica (“Ma qual è l’account?”), abbiamo iniziato l’incontro vedendo la soluzione all’ultimo problema del corso che avevamo visto nella lezione precedente.

Tre nuove lezioni viste:

• Security Contexts ➡ far girare processi sul pod con utenti specificati.
• Resource Requests & Limits ➡ quanta CPU / Memoria / Disco possono usare i pod.
• Taint & Tolerations ➡ rendere “allergici” i pod ai nodi, e “vaccinarne” alcuni.

La prossima volta vedremo le soluzioni agli ultimi esercizi (perché abbiamo scoperto che a volte nei video delle soluzioni ci sono comandi utili non spiegati nel resto del corso).

Curiosità e comandi

• kubectl explain pods --recursive | less
  • Mostra la documentazione della risorsa (es.: pod), in termini della struttura YAML che supporta.
• kubectl edit ➡ solo se cambi l’immagine del pod e nient’altro.
• Far girare i processi sul pod con un altro utente (non root).
• Process visualization
  • Usa comando top per visualizzare tutti i processi in esecuzione sul kernel.
  • ps -ef | grep stringa_da_cercare per indagare nella lista processi in base al comando che stanno eseguendo, ad esempio ps -ef | grep sleep
• 1 megabyte è un po’ meno di un mebibyte (MB vs MiB).

15/11/2021 – Avengers: Affinity war

Dopo aver ripreso gli argomenti trattati la volta precedente, siamo passati a vedere lezioni sui seguenti nuovi argomenti:

• Multi-container pods ➡ pod che hanno più container.
• Liveness e Readiness probes
  • Liveness: Verificano che il pod sia davvero “live”.
  • Readiness: Verifica che il container sia “ready”.
• Node Affinity

In una esercitazione abbiamo creato un pod multi-container con Elastic Search ed Elastic Kibana.

Curiosità e comandi

• Non è possibile creare pod multi-container con comandi imperativi.
• Vim: (:set numbers) ➡ aggiunge la numerazione di riga.
• Dentro un pod multi-container, i container condividono la network, quindi localhost è uguale per tutti.
• Tips da utenti che hanno conseguito la certificazione:
  • https://medium.com/@harioverhere/ckad-certified-kubernetes-application-developer-my-journey-3afb0901014
  • https://www.linkedin.com/pulse/my-ckad-exam-experience-atharva-chauthaiwale/
  • https://github.com/lucassha/CKAD-resources

22/11/2021 – Il mio grosso Ingress matriMonitoring greco

Oggi abbiamo visto dal corso le lezioni relative a: logs & monitoring; labels; deployments; jobs & cronJobs; services; ingress.

Alcune differenze fra i vari file YAML che ci causano emicranie:

• yaml –> apiVersion: batch/v1 ; kind: Job
• yaml –> apiVersion: batch/v1beta1 ; kind: CronJob
• yaml –> apiVersion: extensions/v1beta1 ; kind: Ingress

  Curiosità e comandi

• kubectl logs [-f] <pod-name> [<container-name>]
  • Mostra i log (-f per “follow”).
• kubectl get pods --selector <name>=t;value>
kubectl get all -l <name>=t;value>,<name>!=t;value>,<name>=lt;value>
  • Filtra in base alle labels.
• kubectl rollout status <deployment/name>
kubectl rollout history deployment <name> --revision=br /> kubectl rollout undo <deployment/name>
  • Controlla il rollout di un deployment.
• kubectl get jobs
• kubectl delete job <name>
• Linux: watch [opzioni] <comando>
  • Ripete l’esecuzione del comando fino a che lo si termina.
    • -d– Highlights differences between iterations.
    • -n secs – Specifies the interval between executions of the command in seconds.
• Nomi corti in kubectl:

29/11/2021 – Ingress and the city

Abbiamo continuato con il corso: la volta precedente avevamo concluso vedendo la spiegazione di Ingress, dunque abbiamo ripreso quella lezione e svolto la prima di due esercitazioni inerenti proprio a questo argomento.

In particolare riteniamo importante scrivere che un Ingress controller (che, ricordiamo, è un deployment e quindi un pod) di default vede “out-of-the-box” tutti gli oggetti Ingress (e quindi tutte le regole) creati all’interno di tutti i namespace.

La prossima volta faremo la seconda esercitazione e procederemo con il corso.

Curiosità e comandi

• kubectl get all -A
  • flag -A : su tutti i namespace.
• kubectl edit ingress <name>
  • Stavolta “edit” funziona! (Almeno per cambiare path o aggiungerne altri).

06/12/2021 – 308: Non esponete quell’ingress

Nell’incontro di oggi abbiamo proseguito da dove eravamo rimasti, ovvero svolgere la seconda esercitazione relativa agli Ingress.

Questa esercitazione ci ha portato via molto tempo. Dopo vari tentativi, quando provavamo ad accedere ai pod da browser ricevevamo un redirect error 308.

Dopo circa due ore, in cui abbiamo provato a ripetere l’esercitazione almeno tre volte, guardando i commenti question & answers del video ci imbattiamo in questa riga che sarebbe stata da aggiungere allo yaml dell’ingress service: nginx.ingress.kubernetes.io/ssl-redirect: "false".

Alla fine avrebbe funzionato tutto già dalla prima esecuzione dell’esercizio, inutile dire l’abbattimento morale del gruppo.

In compenso abbiamo sperimentato un bel po’ di cose che sicuramente torneranno utili.

Curiosità e comandi

• nginx.ingress.kubernetes.io/ssl-redirect: "false" è la prima cosa da aggiungere a un service se si ha un errore “too many redirect”.
• In VIM, per entrare in modalità insert creando una riga nuova sotto a dove si trova il puntatore, basta premere “o” (è come digitare “i” -> per andare alla fine della riga attuale e premere “invio”).
• Utilizzare comando kubectl expose deployment <nome-deployment> <options> per creare il servizio che espone il pod definito nel deployment risulta più efficace del creare il servizio con kubectl create svc <nome-servizio> <options> perchè l’expose aggiunge automaticamente anche la sezione selector correttamente compilata con le label del deployment esposto.

13/12/2021 – Scuola di Policies – PersistentVolume II

Abbiamo concluso il corso (esclusi aggiornamenti per il 2022), incluse alcune lezioni su argomenti non oggetto di certificazione.

Sono stati affrontati in particolare i seguenti topic:

• Volumes (Un volume persistente sul container, non è un object di k8s ma un elemento legato al pod).
• Persistent Volumes (Un volume persistente, che è un oggetto di k8s).
• Persistent Volumes Claims (Permettono ai pod di farsi assegnare un persistent volume).
• Storage Classes (Quando i volumi vengono messi a disposizione da servizi esterni come GCP oppure AWS).
• Networking policies (come mettere in comunicazione i pod tra di loro, regolando il traffico).

Il prossimo incontro inizieremo la sezione del corso contenente gli aggiornamenti relativi all’ultima versione della CKAD.

Curiosità e comandi

• Ingress = traffico in ingresso (più la risposta inviata in uscita sulla stessa porta).
• Egress = traffico in uscita (più la risposta ricevuta in ingresso sulla stessa porta).
• kubectl get pods --show-labels ➡ mostra le label che si possono usare nei selector.

20/12/2021 – Scavicchi ma non apra

Nell’incontro odierno abbiamo ripreso il corso CKAD dalla sezione degli “aggiornamenti 2022”, contenente gli argomenti:

• Immagini docker
• Authentication
• Authorization (role, roleBinding)
• Authorization on cluster level (per risorse estese…roleCluster, roleClusterBinding)
• Kube config
• API groups

Nello specifico abbiamo estrapolato comandi del tipo:

• docker build .  -t <NOME IMMAGINE DOCKERFILE> (if no tag to be specified) nella cartella contente il DockerFile per buildare l’immagine Docker (rivedere la sintassi per la creazione di un docker file).
• Per rinominare il nome di una dockerfile…docker image tag <IMAGE ID> <Nuovo nome Imagine>. docker run -p 8282:8080 <nome dockerfile> (combinazione <hostport : containerport>).
• Vedere le specifiche di un’immagine: docker image inspect <id immagine>
• Per creare un’istanza di un’immagine: docker run -it <nome immagine> bash
• Vedere le immagini in locale: docker images
• Differenze tra ABAC RBAC:
  • ABAC permette di creare permessi per ogni signolo utente o gruppo di utenti.
  • RBAC permette invece di creare dei ruoli e poi collegare gli utenti che ricopriranno quel ruolo, il che è più efficiente.
• Per RBAC va creato un role (API VERSION: rbac.authorization.k8s.io/v1, kind: Role); successivamente, dopo aver definito nel file yaml i role, andiamo poi a creare uno yaml di kind: RoleBinding (kubectl get roles - kubectl get rolebinding). Questi ruoli e binding sono definiti al livello di namespace.
• Check Access:
  kubectl auth can-i delete nodes per vedere se abbiamo i permessi per eseguire quell’azione.
  kubectl auth can-i delete nodes --as a user per impersonare un utente specifico.
  • Il comando --as user funziona appunta solo per impersonare user e role.
  • Per specificare un’ “istanza” di un particolare tipo di entità allora devo scrivere pod/<nome pod che sto cercando>.
• Cluster Roles
  Questo tipo di ruoli non sono “agganciati” a un namespace ma piuttosto a un gruppo di cluster (contenenti anche nodi e risorse estese in generale).
  ClusterRole yaml (kind: ClusterRole) e poi come per i role dei namespace creiamo uno yaml per fare il binding (kind: ClusterRoleBinding).
  Quando associamo un utente a un cluster role, ha accesso a tutti i namespace dei pod su cui il role dà accesso.
• kube-system è definito come pod (che esegue l’API server).

28/12/2021 – Un pod per due

(Gilda poco partecipata causa vacanze natalizie).

Oggi abbiamo visto che esiste un fantastico gioco chiamato “Game of pod”. Proponiamo per l’appuntamento del 10/01 di svolgere l’attività tutti insieme.

Durante la gilda abbiamo provato a svolgere l’esercitazione LIGHTNING LABS, LIGHTNING LAB – 1, durante la quale abbiamo cercato di risolvere una simulazione d’esame composta da 5 esercizi. Siamo riusciti a completare solo i primi tre (perché poi è crashato tutto):

• Creare un Persistent Volume ed un Persistent Volume Claim da agganciare a un pod.
• Abilitare i pod per ricevere del traffico in ingress.
• Creare un pod che eseguisse un comando.

Durante il prossimo appuntamento suggeriamo di riprovare la simulazione d’esame e di procedere con la seconda.

Reputiamo particolarmente difficile riuscire a eseguire tutti gli esercizi in 30 minuti!

04/01/2022 – Prince of Kubernatis e le sabbie del tempo

(Gilda poco partecipata causa vacanze natalizie).

Oggi abbiamo visto il secondo lab di KodeKloud (LIGHTNING LABS, LIGHTNING LAB – 2) per testare le nostre conoscenze con degli esercizi ex-novo. Abbiamo notato la difficoltà nel rispettare il tempo concesso / consigliato di mezz’ora per il completamento degli esercizi; ipotizziamo la possibilità di aumentare la velocity abituandoci a usare shortcut e la documentazione in modo più efficente (P.S.: continui crash del terminale KodeKloude non aiutano).

Il risultato della sessione di oggi sono i seguenti suggerimenti e note per i prossimi incontri:

• Gestione dei log e salvataggio degli stessi.
• Differenze fra taints e selettore nodi.