Kubernetes, OpenShift e GCP · 16 min
Corso · lezione 9 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
Chi può fare cosa
kubectl usa un utente. Il Pod usa un ServiceAccount. IAM Google è un altro cancello, davanti.
Il disegno
Tre identità diverse. Non mescolarle.
Umano
kubectl, console.
Carico
Il processo nel Pod.
In poche righe
RBAC: soggetto + verbo + risorsa (get pods, create deployments). Role nel namespace, ClusterRole sul cluster. Un 403 in apply è quasi sempre qui.
Il Pod non “è te”. Ha un ServiceAccount. Su GKE, Workload Identity collega quel SA a un account Google, senza chiavi nel Secret. Pod Security (PSS/PSA) limita privileged, hostNetwork, root.
NetworkPolicy è un altro disegno: chi parla con chi in rete, non chi chiama l’API. Default: tutto aperto, finché non chiudi.
Disegna questo
Due cancelli. Reception (API + RBAC). Corridoi tra Pod (NetworkPolicy). Un badge SA sul Pod. Davanti, IAM GCP.
Un foglio, non un software. Se lo sai ridisegnare senza guardare, la lezione è tua.