Kubernetes, OpenShift e GCP · 16 min
Corso · lezione 4 di 14
Kubernetes, OpenShift e GCP
0/14 viste
- 01Progetti, regioni, perché GKE
- 02Immagine, container, Pod
- 03Il cluster è un’azienda
- 04Cosa succede a un apply
- 05Pod, ReplicaSet, Deployment
- 06Job, CronJob, quante repliche
- 07Service, Ingress, DNS del cluster
- 08Volumi, Secret, StatefulSet
- 09Chi può fare cosa
- 10Quando un Pod si rompe
- 11GKE: node pool e Autopilot
- 12OpenShift sopra Kubernetes
- 13Build, registry, apply
- 14GKE e OpenShift, stesso Kubernetes
Cosa succede a un apply
Un YAML è una lettera alla reception, non un comando al nodo.
Il disegno
Clicca un anello. Se si rompe lì, i sintomi sono diversi.
In poche righe
kubectl spedisce l’oggetto. L’API lo valida (schema, admission, RBAC). etcd lo tiene. I controller creano ReplicaSet e Pod. Lo scheduler mette un nodo. kubelet tira l’immagine.
Imperativo (`kubectl run`, `create`) vs dichiarativo (`apply -f`, kustomize, Helm). In produzione vince il file versionato. Il server-side apply evita di pestarsi i field tra controller e umani.
Quasi ogni lezione dopo (Deployment, Job, HPA) è una variante di questa catena.
Disegna questo
Freccia unica: YAML → API → etcd → controller → scheduler → kubelet → container runtime.
Un foglio, non un software. Se lo sai ridisegnare senza guardare, la lezione è tua.