Kubernetes, OpenShift e GCP · 16 min
Corso · lezione 6 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
Job, CronJob, quante repliche
Un Deployment non deve finire. Un Job sì. Lo scaler cambia N, non il mestiere.
Il disegno
Stesso Pod sotto, contratto diverso.
| Deployment | Job / CronJob | |
|---|---|---|
| Fine | Non deve finire | Deve arrivare a Complete |
| Pod morto | Ne rinasce uno | Retry, poi Failed |
| Quanti | replicas / HPA | parallelism, completions |
| Uso | API, worker, sito | migrazione, report, cron |
In poche righe
Job: lancia Pod finché completions è raggiunto (o backoffLimit). parallelism = quanti insieme. Un Pod di Job che esce 0 è successo; 1 è retry.
CronJob: schedule tipo crontab, concurrencyPolicy (Forbid, Replace). History dei Job vecchi: imposta i limiti o riempi l’API di spazzatura.
HPA guarda CPU/memoria (o metriche tue) e scrive spec.replicas sul Deployment. Affinity e taint dicono *dove*, non *quanti*. Cluster Autoscaler / Autopilot aggiungono nodi se i Pod restano Pending per risorse.
Disegna questo
Tre orologi: Deployment sempre acceso; Job che si spegne; CronJob che si sveglia. Una slitta “repliche” sull’HPA.
Un foglio, non un software. Se lo sai ridisegnare senza guardare, la lezione è tua.