Terminologia

K8s

K8s è il numeronimo convenzionale per Kubernetes: "K", poi otto lettere, poi "s". Si pronuncia "keits" ed è usato ovunque negli strumenti, nei namespace e nella documentazione. Si riferisce allo stesso progetto della parola intera Kubernetes.

OCI

OCI sta per Open Container Initiative, il progetto della Linux Foundation che standardizza i formati dei container. Pubblica tre specifiche: image-spec (layout dell'immagine), runtime-spec (come eseguire un bundle container) e distribution-spec (l'API di push/pull dei registry). La conformità a OCI è ciò che rende le immagini portabili tra gli strumenti.

CRI

CRI sta per Container Runtime Interface, l'API gRPC che il kubelet usa per parlare con un container runtime. Ha disaccoppiato Kubernetes specificamente da Docker, permettendo di inserire qualsiasi runtime conforme (containerd, CRI-O). La rimozione del "dockershim" in-tree in Kubernetes 1.24 ha reso la CRI l'unico percorso di integrazione supportato.

CNI

CNI sta per Container Network Interface, la specifica che governa come viene configurata la rete per i container. Kubernetes usa un plugin CNI per assegnare a ogni Pod un IP e per cablare la rete del cluster. Implementazioni comuni includono Calico, Cilium e Flannel.

CSI

CSI sta per Container Storage Interface, l'API standard per esporre sistemi di storage a blocchi e a file agli orchestratori di container. Un driver CSI permette a Kubernetes di fare provisioning, attach, mount e snapshot di volumi da qualsiasi backend conforme senza codice in-tree. Ha sostituito i vecchi plugin di volume in-tree.

CRD

CRD sta per Custom Resource Definition, il meccanismo per aggiungere tipi di risorsa propri all'API di Kubernetes. Una volta registrate, le custom resource si gestiscono con kubectl come gli oggetti nativi e sono tipicamente riconciliate da un controller personalizzato. Le CRD sono la base del pattern Operator.

CR

CR sta per Custom Resource, un'istanza di un tipo definito da una CRD. Estende l'API di Kubernetes con oggetti specifici di dominio (ad esempio un Database o un Certificate). Un controller osserva le CR e riconcilia lo stato reale per farlo corrispondere.

RBAC

RBAC sta per Role-Based Access Control, il modello di autorizzazione principale di Kubernetes. Role e ClusterRole enumerano i verbi consentiti sulle risorse, e i binding concedono quei ruoli a utenti, gruppi o service account. Applica il minimo privilegio sull'API server.

HPA

HPA sta per Horizontal Pod Autoscaler, il controller che scala il numero di repliche di un carico in base a metriche. Legge CPU, memoria o metriche personalizzate/esterne e regola le repliche entro limiti min/max. Scala in orizzontale (più Pod) anziché in verticale (Pod più grandi).

VPA

VPA sta per Vertical Pod Autoscaler, che raccomanda o imposta le richieste e i limiti di CPU e memoria per i container in base all'uso. A differenza dell'HPA modifica la dimensione dei Pod, non il loro numero, e applicare le modifiche richiede di solito di ricreare il Pod. I due autoscaler in genere non si usano sulla stessa risorsa per la stessa metrica.

CA

In contesto di scaling Kubernetes, CA sta per Cluster Autoscaler, che aggiunge o rimuove nodi quando i Pod non possono essere schedulati o i nodi sono sottoutilizzati. Complementa l'HPA: l'HPA cambia il numero di Pod e il CA cambia il numero di nodi per ospitarli. (In contesto TLS lo stesso acronimo indica Certificate Authority.)

QoS

QoS sta per Quality of Service, la classe che Kubernetes assegna a ciascun Pod in base a richieste e limiti di risorse: Guaranteed, Burstable o BestEffort. La classe influenza l'ordine di eviction sotto pressione del nodo, con i BestEffort sfrattati per primi e i Guaranteed per ultimi. Impostare le richieste uguali ai limiti produce la classe Guaranteed.

OOM / OOMKilled

OOM sta per Out Of Memory; OOMKilled è lo stato mostrato quando il kernel Linux termina un container per aver superato il suo limite di memoria. Indica che il carico ha bisogno di un limite di memoria più alto o ha una perdita, non un errore transitorio. Gli OOMKill ripetuti compaiono nei conteggi di riavvio del Pod.

PV

PV sta per PersistentVolume, una risorsa di storage a livello di cluster con un ciclo di vita indipendente da qualsiasi Pod. È fornita staticamente da un amministratore o dinamicamente da una StorageClass. I Pod la consumano tramite un PersistentVolumeClaim.

PVC

PVC sta per PersistentVolumeClaim, una richiesta di storage che si lega a un PersistentVolume. Astrae il backend di storage dal carico, richiedendo solo dimensione e modalità di accesso. Con una StorageClass innesca il provisioning dinamico.

DNS (interno al cluster)

In Kubernetes, il DNS interno al cluster (comunemente CoreDNS) risolve i nomi di Service e Pod nei loro IP virtuali. Un Service di nome "web" nel namespace "shop" è raggiungibile a "web.shop.svc.cluster.local". Questa denominazione stabile permette ai carichi di trovarsi senza fissare gli IP.

Quorum etcd

Il quorum è la maggioranza dei membri etcd che deve concordare per confermare una scrittura sotto il protocollo di consenso Raft. Un cluster di N membri tollera la perdita di (N-1)/2 membri, motivo per cui si raccomanda un numero dispari di membri (3 o 5). Perdere il quorum rende il cluster in sola lettura e incapace di schedulare modifiche.

ENTRYPOINT vs CMD

In un Dockerfile, ENTRYPOINT definisce l'eseguibile che gira sempre, mentre CMD fornisce argomenti predefiniti (o un comando predefinito) facili da sovrascrivere a run time. Combinati, ENTRYPOINT imposta il binario e CMD fornisce default sovrascrivibili. Usare la forma exec (array JSON) evita una shell aggiuntiva e garantisce che i segnali raggiungano il processo.

ARG vs ENV

In un Dockerfile, ARG definisce una variabile di build disponibile solo durante la build, mentre ENV imposta una variabile d'ambiente persistita nell'immagine e visibile a run time. I valori ARG non compaiono nel container in esecuzione a meno che non vengano copiati in una ENV. I segreti non dovrebbero usare nessuno dei due; usa invece i secret mount di BuildKit.

BuildKit

BuildKit è il moderno motore di build di Docker, che abilita build parallele dei layer, cache efficiente, segreti di build e forwarding SSH. È il builder predefinito nelle versioni attuali di Docker ed è esposto anche tramite il plugin buildx per immagini multi-piattaforma. Migliora velocità e sicurezza rispetto al builder legacy.

buildx

buildx è il plugin della CLI Docker che pilota BuildKit e aggiunge build multi-piattaforma, più istanze di builder ed export/import avanzato della cache. Permette di costruire, ad esempio, immagini linux/amd64 e linux/arm64 con un solo comando. È lo strumento standard per produrre immagini cross-architettura.

Sidecar

Un sidecar è un container ausiliario che gira nello stesso Pod del container applicativo principale per estenderlo o potenziarlo, condividendone rete e volumi. Usi tipici sono spedizione dei log, proxy e ricaricatori di configurazione. Kubernetes 1.29+ supporta i container sidecar nativi come una speciale forma di init container che resta in esecuzione.

Init container

Un init container viene eseguito fino al completamento prima dei container applicativi di un Pod, nell'ordine dichiarato. È usato per task di setup come attendere una dipendenza, eseguire migrazioni o recuperare configurazione. I container applicativi partono solo dopo che tutti gli init container hanno avuto successo.

kubectl

kubectl è il client da riga di comando per l'API server di Kubernetes, usato per creare, ispezionare, aggiornare ed eliminare risorse del cluster. Legge i dettagli di connessione al cluster da un file kubeconfig e supporta comandi imperativi e apply dichiarativo. È la principale interfaccia umana verso un cluster.

kubeconfig

Un kubeconfig è un file YAML che archivia cluster, utenti (credenziali) e context che legano un utente a un cluster e a un namespace. kubectl e le librerie client lo leggono (di default da ~/.kube/config) per sapere con quale cluster parlare e come autenticarsi. Più context permettono a un solo file di gestire più cluster.

GitOps

GitOps è un modello operativo in cui lo stato desiderato di un cluster è dichiarato in un repository Git e un agente in-cluster (come Argo CD o Flux) riconcilia continuamente lo stato reale per farlo corrispondere. Git diventa l'unica fonte di verità e il log di audit delle modifiche. Un rollback è un revert di Git.

DaemonSet vs Deployment

Un Deployment esegue un numero scelto di repliche piazzate ovunque lo scheduler le faccia entrare, mentre un DaemonSet esegue esattamente un Pod per nodo corrispondente. I Deployment sono adatti a servizi stateless scalabili; i DaemonSet ad agenti per nodo come raccoglitori di log e metriche. Sono controller diversi per intenti di posizionamento diversi.

Rolling update

Un rolling update sostituisce gradualmente i Pod della vecchia versione con la nuova, governato da maxSurge (Pod extra consentiti) e maxUnavailable (Pod che possono essere indisponibili). Abilita deploy senza downtime se abbinato a probe di readiness. La strategia alternativa Recreate ferma tutti i vecchi Pod prima di avviare quelli nuovi.

Namespace (Linux vs K8s)

Il termine namespace è sovraccarico: un namespace Linux è una primitiva di isolamento del kernel (pid, net, mnt e altri) usata per costruire i container, mentre un Namespace di Kubernetes è una partizione logica degli oggetti API in un cluster. Operano a livelli completamente diversi. Il contesto determina quale si intende.