Kubernets cluster e Helm charts

Kubernets cluster e Helm charts

1) Architettura cluster - vista in alto

Control Plane: «kube-apiserver», «etcd», «kube-scheduler», «kube-controller-manager», (nelle nuvole controllate la parte è nascosta).
Worker: «kubelet», CRI-Rent (containerd/CRI-O), CNI-plugin, kube-proxy/ebpf-proxy.
Rete interna: Pod-to-Pod, Service-VIP/ClusterIP, DNS CoreDNS.
I driver CSI, il provider dinamico PVC PV ( ).
Limite di guasto: sito/AZ/regione. Posizionare le repliche per zona (TopologySpreadConstraints/anti-affinity).

Ruoli tipici

Comando piattaforma: crea/upgrade cluster, CNI/CSI/Ingress, criteri e GitOps.
Team di alimentari: rilascia liste/release, segue regole di sicurezza e risorse.

2) Ciclo di vita cluster

Creazione: kOps, kubeadm, Rancher, EKS/AKS/GKE. Attivare immediatamente l'autenticazione e il controllo OIDC.
Upgrade: versione minor a turno (control plane nodi), controllo , test di stage.
Add-ons (tutto attraverso il Helm/GitOps): CNI (Calico/Cilium), driver CSI, Controller di Ingress (NGINX/Gateway API/Contour/Traefik), Metrics-Server, Cluster-Autocaler, Nane DNS locale, logica/metriche/trace.
Bacap: etcd snapshot (se self-managed), Velero per namespace/PVC.

3) Reti, servizi e ingress

CNI: Calico (NetworkPolicy), Cilium (eBPF/servicemesh-фичи).
Servizio: «ClusterIP», «NodePort», «LoadBalancer» (L4 bilanciamento della nuvola), «ExternalName».
Ingress/Gateway API: routing L7, TLS, anamnesi rate-limit/WAF sul perimetro.
NetworkPolicy: per impostazione predefinita deny-all + allow esplicito per namespace/label.
Headless-service (« : None») per i discovery e i servizi.

4) Storage (CSI) e stato

: « », « ».
StatefulSet: nomi/volumi stabili («volumeClaimTemplates»), «podManagementPolicy: Parallel» per le rotazioni veloci.
ReadWriteMany: utilizzare i file distribuiti (EFS/Filestore) con cautela - valutare la latitanza.
Foto dì VolumeSnapshotClass "+ cron-backap.

5) Multiforme e policy

Namespace per prodotti/ambienti.
RBAC: ruoli minimi, account di servizio separati, "Rolle "/" RoleBinding" al posto dì ClusterRole ", ove possibile.
PSA (Pod Security Adoption) - Modalità «baseline »/« restringted» (sostituzione PSP).
ResourceQuota / LimitRange: потолки CPU/Memory/PVC/LoadBalancer.
OPA Gatekeeper/Kyverno: criterio di tolleranza (ad esempio: latest, resources, readOnlyRootFilesystem).
© Policy/webhook - Verifica la firma delle immagini (cosign/policy-controller).

6) Osservabilità e funzionamento

Metriche: Prometheus-stack, kube-state-metrics, node-esportatori.
Loghi: Fluent Bit/Vector, oggetto/ES/OpenSearch, rotazione su nodi.
OpenTelemetry Collector.
SLO-dashboard: modello RED su ingress e servizi chiave.
Scale automatico: HPA (per metriche di applicazione), VPA per background, Cluster-Autocaler per nodi.

7) Cartelli di manifesti (parete)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: api, labels: { app: api } }
spec:
replicas: 3 strategy: { type: RollingUpdate, rollingUpdate: { maxUnavailable: 0, maxSurge: 1 } }
selector: { matchLabels: { app: api } }
template:
metadata:
labels: { app: api }
spec:
serviceAccountName: api-sa securityContext: { runAsNonRoot: true, fsGroup: 2000 }
containers:
- name: api image: registry. example. com/api:1. 2. 3 ports: [{ containerPort: 8080 }]
resources: { requests: { cpu: "200m", memory: "256Mi" }, limits: { cpu: "1", memory: "512Mi" } }
readinessProbe: { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez,  port: 8080 }, initialDelaySeconds: 20 }

yaml apiVersion: apps/v1 kind: StatefulSet metadata: { name: db }
spec:
serviceName: db replicas: 3 podManagementPolicy: Parallel selector: { matchLabels: { app: db } }
template:
metadata: { labels: { app: db } }
spec:
containers:
- name: db image: postgres:16-alpine volumeMounts: [{ name: data, mountPath: /var/lib/postgresql/data }]
volumeClaimTemplates:
- metadata: { name: data }
spec:
accessModes: ["ReadWriteOnce"]
resources: { requests: { storage: 100Gi } }
storageClassName: fast-ssd

yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: { name: api-pdb }
spec:
minAvailable: 2 selector: { matchLabels: { app: api } }

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api annotations:
nginx. ingress. kubernetes. io/proxy-read-timeout: "30"
spec:
tls: [{ hosts: ["api. example. com"], secretName: api-tls }]
rules:
- host: api. example. com http:
paths:
- path: /
pathType: Prefix backend: { service: { name: api, port: { number: 80 } } }

8) Helm v3 - basi e struttura

Elenco = modelli + valori + metadati.

mychart/
Chart. yaml     # name, version (semver), type (application/library), dependencies values. yaml # default values. schema. json # (recommended) validation values templates/# .yaml. gotmpl (Deployment, Service, Ingress, …)
templates/tests/  # helm tests (smoke)
charts/# local dependencies (or OCI dependencies)

yaml apiVersion: v2 name: api description: API service type: application version: 1. 4. 0 # chart version (semver)
appVersion: "1. 2. 3" # dependencies application version:
- name: redis version: 17. x.x repository: "oci://registry. example. com/charts"

9) Modelli di applicazioni Helm

Usa gli helpers in' _ helpers. tpl per nomi/etichette/annotazioni.
Dappertutto indicare «resources», «securityContext», «readì/liveness».
Generare labels secondo uno schema standard ('app. kubernetes. io/`).
Rendi opzionali i files attraverso «values» (ingress/hpa/pdb/servicemonitor).
Accendete «values». schema. json - stop da configure sbagliate.
Per i dati sensibili - Segreti da operatori esterni (Extrannal Secret, SOPS), invece di memorizzare in values.

gotmpl
{{- define "api. fullname" -}}
{{- printf "%s-%s".Chart. Name. Release. Name      trunc 63      trimSuffix "-" -}}
{{- end -}}

gotmpl apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "api. fullname". }}
labels: {{- include "api. labels". nindent 4 }}
spec:
replicas: {{.Values. replicaCount }}
strategy:
rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{- include "api. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{- include "api. selectorLabels". nindent 8 }}
spec:
serviceAccountName: {{ include "api. serviceAccountName". }}
securityContext: {{- toYaml. Values. podSecurityContext      nindent 8 }}
containers:
- name: {{.Chart. Name }}
image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports: [{ containerPort: {{.Values. service. port }} }]
resources: {{- toYaml. Values. resources      nindent 10 }}
envFrom:
- secretRef: { name: {{.Values. secretsRef }} }

10) Dipendenze, repository e OCI

Helm v3 supporta i registri OCI: 'oci ://registry/org/charts'.
Elabora le versioni delle dipendenze ('^ 1. 2. 0`, `~1. 2 ') e cacciare «helm dipendency build».
Firmare un elenco (prov), memorizzare gli artefatti nel repository ICI.
Library charts - Modelli condivisi (ingress/servicemonitor) da riutilizzare.

11) Hooks, CRD e ordine delle operazioni

Hooks: `pre-install`, `post-install`, `pre-upgrade`, `post-upgrade`, `test`. Aggiungi policies («before-hook-creation», «hook-succeeded»).
CRD: posa in «crds/» (installato prima dei templi), evita gli update CRD« al volo »- fare migrazioni separate.
Migrazioni database/inizializzazione - job-hook con idempotency e timeout.

12) Test di scaletta e CI

«helm lint» + convalida dello schema.
Helm unittest (unit), chart-testing (ct) - assemblaggio/installazione in kind/minikube in CI.
Test snapshot dei modelli ('helm template') confrontato con il riferimento.
Test smoke «helm test» (sollevato «Pod» con controlli).

13) GitOps (Argo CD/Flux)

La fonte della verità è il repository. La scaletta viene memorizzata come HelmRelease/HelmChart (Flux) o Applicazione (Argo).
Criteri sink: auto-sync con prune/self-heal, states e health-checks.
Promozione versione tag-bot/semver-range, flow PR.
Dividere i repo in apps (classifiche) e env (overrides/values).
Gestione segreta: SOPS (age/KMS), Esternal Secret.

14) Sicurezza: minimo necessario

PSA restrited: senza privilegi, senza hostPath, con capabilities limitate, read-only rootfs.
ImagePolicy: solo immagini firmate/affidate.
NetworkPolicy: «Il valore predefinito è chiuso».
RBAC: account per-app, «Rolle »/« RoleBinding» in namespace.
Controllo admissi: Gatekeeper/Kyverno regole (resources/limits, labels, no latest).
Segreti: SOPS/Esternal Secret; non mettere segreti in values/plain git.

15) Anti-pattern

«: latest» in liste e immagini; l'assenza dì values. schema. json`.
Una grande scaletta per tutto, invece di una modulare.
I CRD vengono aggiornati con i modelli in «templates/» per il caos sugli upgrade.
Nomi fissi/porta/namespace nei modelli.
La mancanza di risorse/limiti e di campioni è una deriva di latitanza e instabilità.
Nessun PDB di downtime zero è possibile con drain/upgrade.
Segreti in Git senza crittografia; manifesti senza criteri-checks.

16) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Crea scheletro base con '_ helpers. tpl ', labels, probes, resources, PDB/Ingress opzionale.
Включить PSA restricted, NetworkPolicy deny-all, ResourceQuota/LimitRange.
Configura GitOps (Argo/Flux), minuscolo privato, firma immagine/elenco.

11-25 giorni

Dividere la lista in moduli/dipendenze, aggiungere'values. schema. json', test ('helm lint', unit, ct).
Connetti osservabilità (ServiceMonitor/PodMonitor), agenti loghi, OTel.
Immettere il processo di upgrade: staging → canary → prod, migrazione hook da rollback.

26-45 giorni

Automatizza gli aggiornamenti delle dipendenze (bot/semver-ranges + PR).
Aggiungi criteri Gatekeeper/Kyverno e reperti policy a CI.
Documentare runbook upgrade cluster, procedure DR (Velero/etcd snapshot).

17) Metriche di maturità

Il 100% delle applicazioni viene scaricato manualmente, senza «kubectl apply».
Tutte le classifiche hanno «values». schema. json, test, firma e versioni registrate delle dipendenze.
PSA è incluso in tutti i namespace.
PDB e HPA sono presenti in tutti i servizi critici.
Segreti sicuri (SOPS/Esternal Secret), no latest, firma delle immagini.
Gli upgrade del cluster e della scaletta si svolgono senza downtime (canary/blue-green), i test di restore sono regolari.

18) Conclusione

Forte Kubernets Fondamenta = solida architettura cluster + rigida politica + Helm charts di qualità industriale gestiti da GitOps. Standardizzare i modelli, proteggere l'ambiente, convalidare i valori e automatizzare i test, la firma e la promozione. Gli upgrade e le release diventeranno prevedibili e la piattaforma sarà sostenibile e conveniente per i comandi alimentari.