Kubernetes, OpenShift e GCP · 16 min
Corso · lezione 13 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
Build, registry, apply
Il lab finale è un ciclo: codice → immagine → manifesto → cluster. Non un bottone “deploy” magico.
Il disegno
Il ciclo che i PDF chiamano laboratorio. Clicca una stazione.
In poche righe
CI (Cloud Build, GitHub Actions, GitLab): test, docker build, push sul registry con digest. Tag latest da solo è un rollback impossibile.
CD: kubectl apply, Helm, kustomize, o GitOps (Argo/Flux che applicano ciò che è nel repo). Il cluster non dovrebbe “essere aggiornato a mano dal laptop”.
Promuovi ambiente: stesso digest, overlay diversi (env, replica, Ingress). Se “in prod è un altro Dockerfile”, non hai una pipeline: hai due prodotti.
Disegna questo
Repo → build → registry (digest) → YAML/Helm → API del cluster. Una freccia di rollback sullo stesso digest precedente.
Un foglio, non un software. Se lo sai ridisegnare senza guardare, la lezione è tua.