PDF 3 · 3_Architettura.pdf

Un cluster è un’azienda: c’è chi decide e c’è chi esegue.

Approfondimento visivo del cluster: chi decide, chi esegue, cosa succede a un apply. Fa parte del corso nostro su Kubernetes, non è una slide da lasciare aperta.

Torna al corso Kubernetes

Il disegno del cluster

Control plane — i cervelli

Decidono. Su GKE questa scatola è gestita da Google.

Worker node — le braccia

Una VM. Puoi averne 3 o 300. Ognuna ha gli stessi tre agenti.

Workload — quello che serve a te

Le tue app. Kubernetes le sposta; tu non ti affezionare al singolo Pod.

Control plane

kube-apiserver

L’unica porta d’ingresso del cluster.

È la reception dell’azienda: ogni richiesta (kubectl, dashboard, controller) passa da qui. Autentica, autorizza, valida, poi scrive.

Da ricordare

Non parli mai “direttamente” con etcd o con un nodo. Parli con l’API. kubectl get pods = HTTP GET all’API server.

Se si rompe

Nessuno può cambiare lo stato. I Pod già in esecuzione continuano, ma non comandi più il cluster.

Nel PDF 3_Architettura cerca

diagramma “clients → API server”
autenticazione e autorizzazione
oggetto API / risorsa / versione (apps/v1)

Cosa succede quando fai apply

Quasi tutte le slide successive (Deployment, Service, GKE) sono varianti di questa catena. Se la sai a memoria, i PDF nuovi si agganciano da soli.

Dal comando al container acceso

Passo 1 di 6

kubectl apply → Running

Tu dichiari lo stato

`kubectl apply -f app.yaml` manda un manifesto all’API server. Non stai “accendendo un server”: stai dicendo come vuoi che sia il mondo.

Kubernetes “nudo”

Installi e patchi tu control plane, etcd, nodi, certificati. Massima libertà, massima fatica.

GKE

Google gestisce API server ed etcd. Tu crei il cluster, i node pool e i carichi. In Autopilot spariscono anche i nodi da amministrare.

OpenShift

È Kubernetes + opinioni da fabbrica: Project (namespace con quota), Route, ImageStream, OperatorHub, console e policy più strette. Può girare su GCP.

Cosa cercare nel tuo PDF

Non ho accesso alle slide autenticate di Moodle. Questa è la checklist di quello che un modulo “Architettura” di questo percorso (GKE + Kubernetes) mostra quasi sempre. Aprilo e spunta.

Uno schema con control plane a sinistra e worker node a destra
I nomi API server, etcd, scheduler, controller manager
kubelet e container runtime sul nodo
Il Pod disegnato come riquadro che contiene uno o più container
La freccia kubectl / REST verso l’API server — e nessuna freccia diretta verso etcd
Eventuale slide “GKE gestisce il control plane per te”
Eventuale confronto master/control plane (termine vecchio: master)

Errori tipici su questo modulo

Verifica se è chiaro Vedi cosa viene dopo