Home/manuali/Kubernetes
Laboratorio · Manuale di Kubernetes

Kubernetes

Il timoniere della flotta digitale.

28 esercizi6 Parti4 appendici
Il codice colore indica il livello:FondamentaleIntermedioAvanzatoCloud Architect
● In vendita su AmazonCartaceo →396 pagine · ISBN 9798181615397
scarica gli esercizi
git clone --filter=blob:none --sparse https://github.com/calmict/book_labs.git
cd book_labs
git sparse-checkout set kubernetes/ed1
calm@calmict:~$ cat kubernetes/argomenti
Parte 1

Le fondamenta Linux

  • 01Un container è solo un processoFondamentale
  • 02Un container a mano, senza DockerFondamentale
  • 03Limitare CPU e RAM a manoFondamentale
  • 04Smonta un'immagine a manoFondamentale
  • 05Risali la catena dei runtimeFondamentale
  • 06Collega due network namespace a manoFondamentale
Parte 2

Architettura del Control Plane

  • 07Il primo contatto: uccidi un Pod e guarda chi lo resuscitaFondamentale
  • 08Uccidi il leader: quorum ed elezioni in etcdFondamentale
  • 09Bussa alle quattro porte: l'API server a mani nudeFondamentale
  • 10Scrivi il tuo controller in venti righeFondamentale
  • 11Guida lo scheduler e poi scavalcaloFondamentale
  • 12Il medico di bordo: probe, riavvii e resurrezioneFondamentale
Parte 3

Gli oggetti core

  • 13L'indagine: chi ha toccato il mio Pod?Intermedio
  • 14Il condominio Pod: due coinquilini, un portiere invisibileIntermedio
  • 15Il rilascio, il disastro e il ritorno (rollout e rollback)Intermedio
  • 16L'anagrafe: nomi, ordine e dischi che sopravvivonoIntermedio
  • 17I tre mestieri: uno per nodo, fino in fondo, a orarioIntermedio
Parte 4

Rete e storage

  • 18L'indirizzo che non esiste (Service e kube-proxy)Intermedio
  • 19Il portone e il portiereIntermedio
  • 20Il matrimonio combinatoCloud Architect
Parte 5

Sicurezza

  • 21La stagista e il robotAvanzato
  • 22La cassaforte e il corridoioAvanzato
  • 23Il re di cartoneCloud Architect
Parte 6

Ecosistema e produzione

  • 24Lo stampo e le colateCloud Architect
  • 25Il lettore dei contatoriCloud Architect
  • 26Il libro mastro e il revisoreCloud Architect
  • 27La scortaCloud Architect
  • 28Il passaporto del portiereCloud Architect
calm@calmict:~$ ls kubernetes/esercizi/
01Un container è solo un processoFondamentale›

Cosa costruisci

Il viaggio parte sotto Kubernetes: osservi un processo reale attraverso le due finestre che fanno sembrare un container una macchina separata.

Obiettivi

  • Osservare lo stesso processo dall'host e dal container (1.2).
  • Confrontare PID, hostname ed elenco dei processi (1.2, 1.3).
  • Distinguere isolamento dei processi e virtualizzazione hardware (1.3).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap01/solution
./run.sh

Esito atteso

  • Il processo ha un PID ordinario sull'host e PID 1 nel container.
  • Hostname ed elenco processi mostrano viste isolate.
  • run.sh stampa OK 1..4 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
02Un container a mano, senza DockerFondamentale›

Cosa costruisci

Dopo le due viste del capitolo 1, costruisci tu l'illusione usando soltanto gli strumenti del kernel Linux.

Obiettivi

  • Creare namespace PID, mount, UTS, IPC, NET e USER con unshare (2.2, 2.3).
  • Ottenere PID 1, hostname privato e rete isolata (2.2, 2.4).
  • Confrontare gli inode esposti da /proc/[pid]/ns (2.5).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap02/solution
./run.sh

Esito atteso

  • La shell è PID 1, l'hostname è privato e la rete mostra solo loopback.
  • Gli inode pid, uts, net e user differiscono da quelli dell'host.
  • run.sh stampa OK 1..5 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
03Limitare CPU e RAM a manoFondamentale›

Cosa costruisci

I namespace decidono che cosa un processo vede; ora osservi direttamente i contatori che decidono quanto può consumare.

Obiettivi

  • Creare un cgroup v2 e leggerne i controller disponibili (3.1, 3.2).
  • Osservare il diverso destino di CPU e memoria: throttling e OOM kill (3.3).
  • Verificare il limite al numero di processi e collegare i controller ai limits di Kubernetes (3.3, 3.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap03/solution
./run.sh

Esito atteso

  • Il cgroup delegato viene creato e dichiara memory e pids.
  • Il processo limitato muore con exit 137, mentre la stessa allocazione senza limite riesce.
  • TasksMax respinge realmente un fork oltre il limite.
  • run.sh stampa OK 1, SKIP 2, OK 3, OK 4 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
04Smonta un'immagine a manoFondamentale›

Cosa costruisci

Dopo namespaces e cgroup manca l'ultimo pezzo dell'anatomia: il filesystem. In questo laboratorio apri un'immagine, segui i riferimenti tra i suoi oggetti e misuri quanto — e in che senso — il root del container è diverso dal root dell'host: i poteri sì, l'identità no.

Obiettivi

  • Riconoscere manifest, config e layer di un'immagine OCI (4.2).
  • Osservare copy-up, whiteout e immutabilità del layer inferiore con OverlayFS (4.1).
  • Confrontare capabilities e kernel dentro e fuori dal container (4.3, 4.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap04/solution
./run.sh

Esito atteso

  • I tre TODO sono completati e i file prodotti identificano oggetti reali.
  • Il layer inferiore resta invariato dopo modifica e cancellazione nella vista merged.
  • Il tentativo di cambiare l'ora è rifiutato e il kernel coincide.
  • L'uid visto dal nodo è coerente con la uid_map del container.
  • run.sh stampa OK 1..6 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
05Risali la catena dei runtimeFondamentale›

Cosa costruisci

Hai costruito a mano i pezzi di un container; ora segui chi li assembla. Parti dal processo vivo, risali fino allo shim, interroghi containerd e infine consegni un bundle direttamente a runc.

Obiettivi

  • Risalire la catena reale tra workload, shim e init (5.2).
  • Interrogare containerd senza passare dalla CLI Docker (5.1, 5.3).
  • Leggere namespaces, cgroup, capabilities e rootfs nel bundle OCI (5.3).
  • Avviare un processo con il solo runc (5.2, 5.3).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap05/solution
./run.sh

Esito atteso

  • La catena mostra workload, containerd-shim e poi init.
  • ctr elenca lo stesso ID e config.json contiene gli ingredienti dei capitoli 2-4.
  • Il processo avviato dal solo runc si vede come PID 1.
  • run.sh stampa OK 1..5 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
06Collega due network namespace a manoFondamentale›

Cosa costruisci

I namespace del capitolo 2 erano stanze chiuse. Ora posi i cavi: due veth e un bridge trasformano due viste di rete isolate in una piccola rete, senza mai modificare quella dell'host.

Obiettivi

  • Creare namespace, veth pair e un bridge come farebbe un runtime (6.1).
  • Seguire un ping e leggere la risoluzione ARP nella tabella dei vicini (6.1).
  • Leggere nella FDB il forwarding appreso dal bridge (6.1).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap06/solution
./run.sh

Esito atteso

  • Il ping attraversa il bridge senza perdita finale.
  • La tabella dei vicini e la FDB contengono il MAC di red.
  • Entrambi i peer esterni sono porte di br-lab.
  • run.sh stampa OK 1..5 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
07Il primo contatto: uccidi un Pod e guarda chi lo resuscitaFondamentale›

Cosa costruisci

I container ora entrano nel cluster. In questo laboratorio distingui il cervello dalle braccia e guardi il modello dichiarativo correggere un sabotaggio reale.

Obiettivi

  • Riconoscere i componenti del control plane e il ruolo dei worker (7.1).
  • Dichiarare due repliche e osservare il reconciliation loop (7.2).
  • Leggere spec e status nello stesso oggetto API (7.3).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap07/solution
./run.sh

Esito atteso

  • Hai identificato i quattro componenti del control plane.
  • Spec e status convergono a due repliche e il Pod cancellato viene sostituito.
  • run.sh stampa OK 1..5 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
08Uccidi il leader: quorum ed elezioni in etcdFondamentale›

Cosa costruisci

Il desiderio del capitolo 7 deve sopravvivere ai guasti. Qui lo ritrovi come chiave replicata e misuri la differenza tra perdere un leader e perdere la maggioranza.

Obiettivi

  • Interrogare tre membri etcd e ritrovare un oggetto come chiave (8.1).
  • Forzare un'elezione Raft senza cambiare gli indirizzi dei membri (8.2).
  • Perdere e ripristinare il quorum di un cluster a tre membri (8.3-8.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap08/solution
./run.sh

Esito atteso

  • Hai visto tre membri, un leader e la chiave del namespace.
  • Dopo la prima pausa l'API risponde con un nuovo leader; dopo la seconda non può leggere.
  • run.sh stampa OK 1..6 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
09Bussa alle quattro porte: l'API server a mani nudeFondamentale›

Cosa costruisci

Etcd custodisce la verità, ma solo l'API server può toccarla. Qui usi curl per vedere le porte che una richiesta attraversa e lo stream che notifica ogni cambiamento.

Obiettivi

  • Esplorare gruppi, versioni e risorse REST senza l'interpretazione di kubectl (9.1).
  • Distinguere autenticazione, autorizzazione e admission dalle loro risposte (9.2-9.3).
  • Osservare eventi ADDED e DELETED su una connessione watch (9.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap09/solution
./run.sh

Esito atteso

  • Hai esplorato /api e /apis con curl.
  • Hai distinto 401 di autenticazione, accesso certificato, Forbidden RBAC e quota superata.
  • run.sh stampa OK 1..7 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
10Scrivi il tuo controller in venti righeFondamentale›

Cosa costruisci

Dopo LIST e WATCH, costruisci il loop che riceve lo stato, misura lo scarto e agisce.

Obiettivi

  • Riconoscere nelle Lease il battito della leader election (10.4).
  • Scrivere un controller observe-diff-act e vederlo riparare e potare Pod (10.1).
  • Collegare polling, informer, cache e duello tra copie (10.3-10.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap10/solution
./run.sh

Esito atteso

  • Hai letto il rinnovo della Lease, oppure lo SKIP motivato della distribuzione.
  • Il controller ripara una cancellazione e pota un eccesso.
  • run.sh stampa OK 1..7, o SKIP 1 motivato, e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
11Guida lo scheduler e poi scavalcaloFondamentale›

Cosa costruisci

Il loop ora ha un compito preciso: scegliere il nodo, senza eseguire il Pod.

Obiettivi

  • Distinguere la decisione dello scheduler dall'esecuzione del kubelet (11.1).
  • Vedere filtering e scoring attraverso un Pod Pending e i suoi eventi (11.2).
  • Guidare le scelte con nodeSelector, anti-affinity, taint e toleration (11.3-11.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap11/solution
./run.sh

Esito atteso

  • Hai confrontato il Pod schedulato col Pod assegnato direttamente.
  • Hai osservato i due Pending e i motivi FailedScheduling.
  • run.sh stampa OK 1..9 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
12Il medico di bordo: probe, riavvii e resurrezioneFondamentale›

Cosa costruisci

Dopo la scelta dello scheduler, osservi il kubelet che mantiene il Pod sano e pronto sul nodo.

Obiettivi

  • Vedere una liveness fallita riavviare il container e produrre back-off (12.2).
  • Vedere la readiness togliere e restituire traffico senza riavvio (12.2).
  • Creare uno static Pod e provarne la resurrezione tramite kubelet (12.1).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap12/solution
./run.sh

Esito atteso

  • Hai distinto riavvio liveness e rimozione dal traffico readiness.
  • Hai visto lo static Pod risorgere con un nuovo UID.
  • run.sh stampa OK 1..9 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
13L'indagine: chi ha toccato il mio Pod?Intermedio›

Cosa costruisci

> Esercizio del Capitolo 13 — La vita di un Pod: da kubectl apply al container attivo del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • ricostruire l'intera staffetta di un kubectl apply dalle prove: quattro firme diverse sugli eventi (deployment-controller, replicaset-controller, default-scheduler, kubelet);
  • seguire la catena di proprietà Deployment → ReplicaSet → Pod scritta negli ownerReferences, e scendere sotto l'API fino al processo Linux — ritrovando namespace e cgroup delle Fasi 1-2;
  • distinguere le due guarigioni: il kubelet che riavvia un container morto (stesso Pod, RESTARTS che sale) e il controller che rimpiazza un Pod cancellato (nome nuovo).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap13/solution
./run.sh

Esito atteso

  • [ ] Hai la timeline con le quattro firme e l'ordine logico ricostruito.
  • [ ] Hai la catena Pod → ReplicaSet → Deployment letta dagli ownerReferences.
  • [ ] Hai trovato il PID sul nodo e il suo cgroup kubepods con la QoS class nel percorso.
  • [ ] Hai osservato entrambe le guarigioni: RESTARTS a 1 dopo il kill -9, nome nuovo dopo il delete.
  • [ ] answers.md risponde alle tre domande e il Deployment è stato rimosso.
Cartella su GitHub ↗README completo ↗
14Il condominio Pod: due coinquilini, un portiere invisibileIntermedio›

Cosa costruisci

> Esercizio del Capitolo 14 — Il Pod in profondità del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • dimostrare perché l'unità è il Pod e non il container: due container che si parlano via localhost e si passano file su un volume condiviso;
  • smascherare il pause container: prima dagli inode dei namespace sul nodo, poi — rendendo il condominio "di vetro" — vedendolo comparire come PID 1 dentro il Pod;
  • osservare un init container fare il portiere (la fase Init:0/1 dal vivo) e leggere la classe QoS di tre Pod dalle loro resources — ritrovandola nella gerarchia cgroup del cap. 3.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap14/solution
./run.sh

Esito atteso

  • [ ] Il wget dal writer restituisce la data scritta dall'altro container (localhost + volume condivisi).
  • [ ] Hai gli inode: net identico tra i due container, pid diversi, e hai trovato il processo /pause sul nodo.
  • [ ] In condo-glass hai visto /pause come PID 1 da dentro il Pod.
  • [ ] Hai osservato la fase Init:0/1 e i tre verdetti QoS (BestEffort, Burstable, Guaranteed).
  • [ ] answers.md risponde alle tre domande e i sei Pod sono stati rimossi.
Cartella su GitHub ↗README completo ↗
15Il rilascio, il disastro e il ritorno (rollout e rollback)Intermedio›

Cosa costruisci

> Esercizio del Capitolo 15 — ReplicaSet e Deployment del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • leggere la divisione dei compiti: il ReplicaSet guardiano del numero, il Deployment orchestratore dei ReplicaSet — e i vecchi ReplicaSet a zero repliche come memoria storica;
  • eseguire un rolling update senza downtime e osservarlo pod per pod (maxSurge 1, maxUnavailable 0);
  • sopravvivere a un rilascio rotto: il rollout si blocca ma il servizio resta su, e kubectl rollout undo riporta indietro in un istante — capendo che non è magia, è ancora il reconciliation loop.

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap15/solution
./run.sh

Esito atteso

  • [ ] Hai visto il rolling update pod per pod, mai sotto 3 attivi.
  • [ ] Dopo il rilascio hai due ReplicaSet (3 e 0) e la history con le change-cause.
  • [ ] Nel disastro: rollout bloccato in ImagePullBackOff ma i 3 pod della versione precedente Running.
  • [ ] Dopo l'undo l'immagine è tornata alpine:3.20 e la revisione è rinata con numero nuovo.
  • [ ] answers.md risponde alle tre domande e il Deployment è stato rimosso.
Cartella su GitHub ↗README completo ↗
16L'anagrafe: nomi, ordine e dischi che sopravvivonoIntermedio›

Cosa costruisci

> Esercizio del Capitolo 16 — StatefulSet e la gestione dello stato del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • distinguere Pod fungibili e identità stabili (§16.1);
  • osservare ordinali, ordinamento e DNS prevedibile via headless Service (§16.2);
  • verificare un disco personale per replica e il suo ciclo di vita (§16.3).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap16/solution
./run.sh

Esito atteso

  • [ ] Hai il confronto dei nomi: casuali nella folla, diary-N nell'anagrafe, con la nascita in ordine 0→1→2.
  • [ ] diary-1 è rinato come diary-1 e il suo diario aveva la riga della vita precedente.
  • [ ] Hai visto i 3 PVC personali, ancora vivi dopo la cancellazione dello StatefulSet, e il diario completo dopo la ricreazione.
  • [ ] La nslookup del nome stabile risolve dall'interno.
  • [ ] answers.md risponde alle tre domande e la pulizia include i PVC.
Cartella su GitHub ↗README completo ↗
17I tre mestieri: uno per nodo, fino in fondo, a orarioIntermedio›

Cosa costruisci

> Esercizio del Capitolo 17 — DaemonSet, Job e CronJob del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • leggere il DaemonSet come contratto geografico (§17.1);
  • distinguere completamento, riavvio e nuovi tentativi di un Job (§17.2);
  • seguire la catena CronJob → Job → Pod (§17.3).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap17/solution
./run.sh

Esito atteso

  • [ ] watchman: 2 guardiani prima della toleration, 3 dopo, e la rinascita sullo stesso nodo.
  • [ ] countdown Completed con i log della conta; flaky Failed con BackoffLimitExceeded dopo 3 pod.
  • [ ] Il primo timbro del CronJob: un Job tick-<timestamp> coi log della data.
  • [ ] answers.md risponde alle tre domande (tabella dei mestieri inclusa).
  • [ ] Il cluster book-labs-crew è stato cancellato.
Cartella su GitHub ↗README completo ↗
18L'indirizzo che non esiste (Service e kube-proxy)Intermedio›

Cosa costruisci

> Esercizio del Capitolo 18 — I Servizi e la magia di kube-proxy del > *Manuale di Kubernetes* (collana Calm ICT — [calmict.com](https://calmict.com)).

Obiettivi

  • osservare il cambio di IP dei Pod effimeri (§18.1);
  • usare un ClusterIP e riconoscerne la realizzazione nel dataplane (§18.2–18.3);
  • seguire EndpointSlice e la risoluzione stabile di CoreDNS (§18.4–18.5).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap18/solution
./run.sh

Esito atteso

  • [ ] Hai provato sulla tua pelle la morte del numero diretto (IP del pod cambiato dopo la rinascita).
  • [ ] Il centralino risponde con entrambe le voci (bilanciamento visto con wget ripetuti).
  • [ ] Hai la prova che il ClusterIP non esiste su nessuna interfaccia e hai osservato le firme del backend rilevato.
  • [ ] Hai visto gli EndpointSlice inseguire lo scale, e il DNS risolvere il nome sul ClusterIP.
  • [ ] answers.md risponde alle tre domande e il laboratorio è smontato.
Cartella su GitHub ↗README completo ↗
19Il portone e il portiereIntermedio›

Cosa costruisci

Dopo i Service del capitolo 18, il palazzo ha molti ingressi ma non sa ancora leggere il nome scritto sulla richiesta HTTP. Qui separi le regole dichiarative da chi le realizza e osservi il routing L7.

Obiettivi

  • Distinguere il bilanciamento L4 dei Service dal routing per host e path dell'Ingress (19.1).
  • Dichiarare due regole Ingress e constatare che senza controller restano inerti (19.2, 19.3).
  • Installare Traefik e seguire una richiesta fino al Service e al Pod corretti (19.3, 19.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap19/solution
./run.sh

Esito atteso

  • [ ] start/ingress.yaml contiene i tre TODO completati.
  • [ ] Senza controller la regola è inerte; con il controller i due host raggiungono app diverse.
  • [ ] run.sh stampa OK 1..6 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
20Il matrimonio combinatoCloud Architect›

Cosa costruisci

Dopo aver instradato le richieste, assegni storage senza legare l'applicazione a un disco preciso: il PVC chiede, il PV offre e il binder combina il matrimonio.

Obiettivi

  • Legare un PVC a un PV statico compatibile e osservare il vincolo uno-a-uno (20.1).
  • Innescare il provisioning dinamico tramite la StorageClass predefinita (20.2).
  • Confrontare nei fatti le reclaim policy Retain e Delete (20.3).
  • Riconoscere il provisioner come controller e collegarlo all'interfaccia CSI (20.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap20/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completati e i manifest descrivono entrambe le forme di provisioning.
  • [ ] spinster resta Pending mentre bride occupa il PV statico.
  • [ ] run.sh stampa OK 1..6 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
21La stagista e il robotAvanzato›

Cosa costruisci

Lo storage ha separato richiesta e implementazione; ora separi autenticazione e autorizzazione. Assumi una persona con un certificato e dai a un workload un'identità propria.

Obiettivi

  • Creare un'identità utente mediante chiave, CSR, certificato e kubeconfig dedicato (21.1).
  • Dare a un Pod un ServiceAccount e usare il token montato per chiamare l'API (21.2).
  • Applicare Role e RoleBinding col minimo privilegio e verificarne i confini (21.3, 21.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap21/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completati.
  • [ ] La stagista è riconosciuta e resta confinata alla job description.
  • [ ] Il robot passa da 403 a PodList soltanto dopo il binding.
  • [ ] run.sh stampa OK 1..6 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
22La cassaforte e il corridoioAvanzato›

Cosa costruisci

RBAC ha chiuso il confine dell'API; ora chiudi i percorsi tra i workload con un contratto di rete.

Obiettivi

  • Osservare il default allow e invertirlo con un default deny (22.1, 22.2).
  • Ammettere solo un client etichettato sulla porta TCP 8080 (22.3).
  • Negare l'egress e verificare che il CNI applichi la policy (22.3, 22.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap22/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi.
  • [ ] Default allow, deny ingress, allow per label e deny egress si comportano come descritto.
  • [ ] run.sh stampa OK 1..4 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
23Il re di cartoneCloud Architect›

Cosa costruisci

Il confine di rete è chiuso; ora riduci ciò che un processo può fare attraverso il kernel condiviso con l'host.

Obiettivi

  • Ispezionare uid, capabilities, modalità seccomp e scrivibilità del filesystem (23.1, 23.2).
  • Applicare un SecurityContext restricted e verificare ogni difesa (23.2, 23.3).
  • Applicare i Pod Security Standards a un intero namespace (23.5).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap23/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi.
  • [ ] Ogni difesa sul processo è osservata nel Pod in esecuzione.
  • [ ] run.sh stampa OK 1..5 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
24Lo stampo e le colateCloud Architect›

Cosa costruisci

Hai coordinato a mano gli oggetti Kubernetes; ora un chart trasforma la loro forma comune in una release versionata.

Obiettivi

  • Confrontare manifest statici ripetuti con un chart riutilizzabile (24.1).
  • Renderizzare template con dati della release e values (24.2).
  • Installare, aggiornare, ispezionare e ripristinare una release (24.3, 24.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap24/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi e il chart viene renderizzato senza errori.
  • [ ] L'upgrade cambia repliche e messaggio attraverso un rollout deterministico dei Pod.
  • [ ] Il rollback ripristina la revisione uno e conserva tre voci di cronologia.
  • [ ] run.sh stampa OK 1..4 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
25Il lettore dei contatoriCloud Architect›

Cosa costruisci

Dopo aver impacchettato la piattaforma con Helm, le dai occhi: un lettore visita i contatori e trasforma misure grezze in domande verificabili.

Obiettivi

  • Osservare il modello pull e le metriche esposte da node-exporter (25.1, 25.2).
  • Dichiarare uno scrape statico e il suo equivalente ServiceMonitor (25.3).
  • Interrogare gauge e counter con PromQL e collegarli ad alert e Grafana (25.4, 25.5).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap25/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi.
  • [ ] node-exporter espone metriche reali e Prometheus vede entrambi i target.
  • [ ] Le tre query PromQL restituiscono risultati.
  • [ ] run.sh stampa OK 1..4 e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
26Il libro mastro e il revisoreCloud Architect›

Cosa costruisci

Hai imparato a osservare il cluster; ora consegni ad ArgoCD un libro mastro e gli chiedi di correggere ogni divergenza.

Obiettivi

  • Usare Git come unica fonte di verità dichiarativa (26.1).
  • Definire sorgente, destinazione e politica di una Application ArgoCD (26.2).
  • Osservare sync, drift, self-heal e rollback con git revert (26.3, 26.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap26/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi e la Application è Synced e Healthy.
  • [ ] Il drift manuale viene annullato.
  • [ ] Il commit e il revert producono cinque e poi una replica.
  • [ ] run.sh stampa OK 1..4 — o SKIP 1 motivato — e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
27La scortaCloud Architect›

Cosa costruisci

Dopo aver affidato lo stato a un revisore, affidi ogni chiamata a una scorta che applica identità, cifratura e rotta senza cambiare l'applicazione.

Obiettivi

  • Osservare sidecar, data plane e control plane (27.1, 27.2).
  • Imporre mTLS automatico e identità workload (27.3).
  • Dirigere un canary 80/20 e collegare il mesh all'osservabilità (27.4, 27.5).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap27/solution
./run.sh

Esito atteso

  • [ ] I tre TODO sono completi e tutti i workload hanno il sidecar.
  • [ ] STRICT rifiuta plaintext ma consente il traffico nel mesh.
  • [ ] Il canary raggiunge entrambe le versioni.
  • [ ] run.sh stampa OK 1..4 — o SKIP 1 motivato — e ALL CHECKS PASSED.
Cartella su GitHub ↗README completo ↗
28Il passaporto del portiereCloud Architect›

Cosa costruisci

Il viaggio si chiude dando al portiere assunto nel capitolo 19 un'identità verificabile. In questo laboratorio costruisci una CA locale, chiedi a Cert-Manager di emettere il certificato e dimostri che Traefik serve il negozio in HTTPS senza chiavi o certificati creati a mano.

Obiettivi

  • Inquadrare acquisizione, scadenza e rinnovo dei certificati TLS (28.2).
  • Osservare la catena SelfSigned, CA e certificato foglia gestita da Cert-Manager (28.3).
  • Ottenere HTTPS automatico con annotazione e sezione tls dell'Ingress (28.4).
  • Verificare autorità emittente, SAN e risposta applicativa attraverso Traefik (28.1, 28.4).

Come testarlo

Completa i TODO nei file di partenza, poi lancia il test della soluzione:

cd kubernetes/ed1/cap28/solution
./run.sh

Esito atteso

  • I TODO 1..3 descrivono autorità, hostname TLS e Secret.
  • La CA locale e il Certificate shop-tls risultano Ready.
  • La chiamata HTTPS validata contro la CA locale restituisce secure shop.
  • run.sh stampa OK 1..5 e ALL CHECKS PASSED, compresa la controprova senza annotazione e sezione tls.
Cartella su GitHub ↗README completo ↗