Glossario

Container

Un container è un processo isolato che viene eseguito a partire da un'immagine, condividendo il kernel del sistema operativo host invece di avviarne uno proprio. Impacchetta un'applicazione insieme alle sue dipendenze così da girare in modo identico tra ambienti diversi. L'isolamento è fornito da funzionalità del kernel Linux come i namespace (per la visibilità) e i cgroup (per i limiti sulle risorse).

Immagine (Container Image)

Un'immagine container è un bundle di filesystem a livelli (layer) in sola lettura più metadati che descrivono come eseguire un container. Ogni istruzione di un Dockerfile produce un layer, e i layer sono indirizzati per contenuto così che layer identici siano condivisi e messi in cache. Un'immagine è identificata da nome, tag e da un digest immutabile (uno SHA-256 del suo manifest).

Layer

Un layer è una differenza immutabile del filesystem prodotta da un singolo step di build. I layer si impilano tramite un union filesystem (come overlayfs) così che il container in esecuzione veda una vista unificata, con un sottile layer scrivibile in cima. Poiché i layer sono indirizzati per contenuto e messi in cache, ordinare le istruzioni del Dockerfile dal meno al più frequentemente modificato massimizza il riuso.

Dockerfile

Un Dockerfile è un file di testo con istruzioni (FROM, RUN, COPY, ENV, CMD, ENTRYPOINT e altre) che il builder esegue per assemblare un'immagine container. Ogni istruzione di norma crea un nuovo layer, quindi il loro ordine influenza il riuso della cache e la dimensione finale. Le build multi-stage permettono di compilare in uno stage e copiare solo gli artefatti in uno stage finale ridotto.

Build multi-stage

Una build multi-stage usa più istruzioni FROM in un solo Dockerfile, copiando artefatti selezionati dagli stage precedenti in uno stage finale snello. Questo tiene gli strumenti di build (compilatori, SDK) fuori dall'immagine di runtime, riducendo dimensione e superficie d'attacco. Si referenzia uno stage precedente con COPY --from=.

OCI (Open Container Initiative)

L'OCI è l'ente di standardizzazione che definisce specifiche neutrali rispetto al fornitore per immagini, runtime e distribuzione dei container. Le sue specifiche image-spec, runtime-spec e distribution-spec fanno sì che un'immagine costruita da uno strumento giri su qualsiasi runtime conforme e venga pubblicata su qualsiasi registry conforme. Docker, containerd, Podman e CRI-O implementano tutti le specifiche OCI.

Registry

Un registry è un server che archivia e distribuisce immagini container tramite l'API di distribuzione OCI, indirizzando gli artefatti per repository, tag e digest. Esempi pubblici sono Docker Hub e GitHub Container Registry; tra le opzioni private ci sono Harbor e i registry gestiti dai cloud. I client effettuano push e pull e possono fissare un digest immutabile per la riproducibilità.

containerd

containerd è un runtime container conforme a OCI che gestisce l'intero ciclo di vita del container: trasferimento e archiviazione delle immagini, esecuzione, supervisione e gli attacchi di basso livello a storage e rete. Gira come daemon ed è usato sia da Docker Engine sia da Kubernetes (tramite il plugin CRI). Delega la creazione effettiva del container a un runtime di più basso livello come runc.

runc

runc è un piccolo strumento da riga di comando che crea ed esegue container secondo la specifica runtime OCI. È il runtime di basso livello di riferimento che imposta namespace, cgroup e il filesystem di root prima di eseguire il processo del container. Runtime di più alto livello come containerd e CRI-O invocano runc (o un'alternativa come crun) per creare ogni container.

Docker Compose

Docker Compose è uno strumento per definire ed eseguire applicazioni multi-container da un unico file YAML dichiarativo (compose.yaml). Descrive servizi, reti e volumi e li avvia insieme con un solo comando. È pensato per lo sviluppo locale e per deployment su singolo host, non per il clustering in produzione.

Volume

Un volume è uno storage persistente gestito da Docker che esiste indipendentemente dal layer scrivibile di un container, così i dati sopravvivono alla rimozione del container. I volumi sono il meccanismo preferito per la persistenza rispetto ai bind mount perché sono gestiti da Docker, portabili e funzionano su tutte le piattaforme. Possono essere condivisi tra container e supportati da driver per storage di rete o cloud.

Bind mount

Un bind mount mappa uno specifico percorso del filesystem host dentro un container. A differenza dei volumi, i dati risiedono in un percorso host che controlli tu, comodo per lo sviluppo locale (montare il codice sorgente) ma che lega il container al layout dell'host. I bind mount aggirano la gestione dei volumi di Docker e possono esporre file dell'host al container.

Kubernetes

Kubernetes (K8s) è una piattaforma open source per automatizzare il deployment, lo scaling e l'operatività di applicazioni containerizzate su un cluster di macchine. Espone un'API dichiarativa: si invia lo stato desiderato degli oggetti e i controller riconciliano continuamente lo stato reale verso di esso. È nato in Google ed è ora governato dalla CNCF.

Pod

Un Pod è la più piccola unità distribuibile in Kubernetes: uno o più container che condividono un namespace di rete (un IP e uno spazio di porte) e possono condividere volumi. I container in un Pod sono sempre schedulati insieme sullo stesso nodo e avviati insieme. I Pod sono di solito creati e gestiti da controller di più alto livello anziché direttamente.

Nodo (Node)

Un nodo è una macchina worker (virtuale o fisica) in un cluster Kubernetes su cui girano i Pod. Ogni nodo esegue un kubelet, un container runtime e un kube-proxy. Il control plane schedula i Pod sui nodi in base alle richieste di risorse e ai vincoli.

Control plane

Il control plane è l'insieme dei componenti che gestiscono lo stato globale del cluster e prendono le decisioni di scheduling. Comprende l'API server, etcd, lo scheduler e i controller manager. Espone l'API di Kubernetes e guida continuamente il cluster verso lo stato desiderato dichiarato.

kube-apiserver

Il kube-apiserver è il front end del control plane di Kubernetes e l'unico componente che parla direttamente con etcd. Tutte le letture e scritture dello stato del cluster passano dalla sua API REST, che gestisce autenticazione, autorizzazione, admission control e validazione. Ogni altro componente (kubelet, controller, kubectl) comunica attraverso di esso.

etcd

etcd è un key-value store distribuito e consistente che funge da backing store per tutti i dati del cluster Kubernetes. Usa l'algoritmo di consenso Raft per restare consistente tra le repliche. Perdere etcd significa perdere lo stato del cluster, quindi va sottoposto a backup ed eseguito con quorum (un numero dispari di membri).

kube-scheduler

Il kube-scheduler osserva i Pod appena creati che non hanno un nodo assegnato e seleziona un nodo per ciascuno. Filtra i nodi che non possono eseguire il Pod (risorse insufficienti, regole di affinità non soddisfatte) e poi assegna un punteggio ai candidati rimasti. La decisione considera richieste di risorse, affinità/anti-affinità, taint e toleration e vincoli.

kube-controller-manager

Il kube-controller-manager esegue i loop di controllo principali (controller) che riconciliano lo stato reale verso quello desiderato, come i controller di node, replicaset e deployment. Ogni controller osserva l'API server e intraprende azioni correttive. Raggrupparli in un unico binario riduce la complessità operativa.

kubelet

Il kubelet è l'agente di nodo che garantisce che i container descritti nelle spec dei Pod assegnati al suo nodo siano in esecuzione e in salute. Parla con il container runtime tramite la Container Runtime Interface (CRI), riporta lo stato di nodo e Pod all'API server ed esegue le probe di liveness e readiness. Non gestisce container che non ha creato tramite Kubernetes.

kube-proxy

kube-proxy è un agente di rete su ciascun nodo che implementa l'astrazione Service mantenendo regole di rete che instradano il traffico verso i Pod di backend corretti. Programma tipicamente regole iptables o IPVS (o delega al dataplane eBPF di un CNI). Abilita IP virtuali stabili per i Service nonostante i Pod vadano e vengano.

Deployment

Un Deployment è un controller di Kubernetes che gestisce un'applicazione stateless mantenendo un numero desiderato di repliche di Pod identiche tramite un ReplicaSet. Supporta aggiornamenti graduali (rolling update) e rollback dichiarativi creando un nuovo ReplicaSet e spostando i Pod in modo progressivo. È il modo standard per eseguire carichi stateless.

ReplicaSet

Un ReplicaSet garantisce che un numero specificato di repliche di Pod identiche sia in esecuzione in ogni momento, creando o eliminando Pod per corrispondere. È il controller di più basso livello gestito da un Deployment; raramente lo si crea direttamente. Ogni revisione di un Deployment corrisponde a un distinto ReplicaSet, ed è così che funzionano i rollback.

StatefulSet

Uno StatefulSet gestisce applicazioni stateful, dando a ciascun Pod un'identità di rete stabile e univoca e uno storage persistente stabile che sopravvive al rescheduling. I Pod vengono creati, scalati ed eliminati in un ordine deterministico, e ciascuno ottiene il proprio PersistentVolumeClaim da un volumeClaimTemplate. È adatto a database e sistemi clusterizzati che necessitano di identità stabile.

DaemonSet

Un DaemonSet garantisce che una copia di un Pod giri su tutti i nodi (o su un sottoinsieme selezionato), aggiungendo automaticamente il Pod quando nuovi nodi entrano nel cluster. È usato per agenti a livello di nodo come raccoglitori di log, agenti di monitoraggio e plugin CNI. Rimuovere il DaemonSet effettua la garbage collection dei Pod che ha creato.

Job

Un Job crea uno o più Pod e garantisce che un numero specificato di essi venga eseguito fino al completamento con successo, riprovando in caso di fallimento entro un backoff limit. È pensato per task batch o run-to-completion anziché per servizi a lunga durata. Una volta raggiunti i completamenti richiesti, il Job è terminato.

CronJob

Un CronJob crea Job secondo una pianificazione ripetuta definita con sintassi cron, per task periodici come backup o generazione di report. Gestisce limiti di storico per le esecuzioni riuscite e fallite e una concurrency policy che controlla le esecuzioni sovrapposte. Ogni tick pianificato genera un nuovo oggetto Job.

Service

Un Service è un'astrazione che definisce un endpoint di rete stabile (un IP virtuale e un nome DNS) per un insieme logico di Pod selezionati tramite label. Bilancia il traffico tra i Pod di backend in salute, disaccoppiando i client dai singoli IP dei Pod che cambiano nel tempo. I tipi includono ClusterIP, NodePort, LoadBalancer ed ExternalName.

ClusterIP

ClusterIP è il tipo di Service predefinito, che espone il Service su un IP virtuale interno raggiungibile solo dall'interno del cluster. Fornisce DNS interno stabile e bilanciamento del carico tra i Pod del Service. È il mattone su cui i Service NodePort e LoadBalancer si basano per l'accesso esterno.

Ingress

Un Ingress è un oggetto API che gestisce l'accesso esterno HTTP e HTTPS ai Service, fornendo routing per host e per path, terminazione TLS e virtual hosting. Richiede un Ingress controller (come ingress-nginx) per soddisfare effettivamente le sue regole. Consolida un routing che altrimenti richiederebbe molti Service LoadBalancer.

Namespace (Kubernetes)

Un Namespace di Kubernetes è un cluster virtuale che partiziona le risorse all'interno di un singolo cluster fisico, dando ambito ai nomi e abilitando isolamento e quote per team. I nomi degli oggetti devono essere unici all'interno di un namespace ma possono ripetersi tra namespace diversi. ResourceQuota, RBAC e NetworkPolicy sono comunemente applicate per namespace.

Namespace Linux

Un namespace Linux è una funzionalità del kernel che dà a un processo una vista isolata di una risorsa di sistema globale, come gli ID di processo (pid), lo stack di rete (net), i mount (mnt) e l'hostname (uts). I container combinano più namespace così che ciascuno veda la propria fetta privata del sistema. Sono la principale primitiva di isolamento alla base dei container.

cgroup

I control group (cgroup) sono una funzionalità del kernel Linux che limita, contabilizza e isola l'uso delle risorse (CPU, memoria, I/O) di un gruppo di processi. I container usano i cgroup per applicare limiti di CPU e memoria così che un container non possa affamare gli altri. Le richieste e i limiti di risorse di Kubernetes si traducono in fondo in impostazioni dei cgroup.

ConfigMap

Una ConfigMap è un oggetto di Kubernetes che archivia configurazione non riservata come coppie chiave-valore, disaccoppiando la configurazione dal contenuto dell'immagine. Può essere consumata come variabili d'ambiente, argomenti da riga di comando o file montati in un Pod. Non è cifrata e non deve contenere segreti.

Secret

Un Secret è un oggetto di Kubernetes per archiviare piccole quantità di dati sensibili come password, token e chiavi. Per impostazione predefinita i Secret sono archiviati codificati in base64 (non cifrati) in etcd a meno che non sia abilitata la cifratura a riposo. Possono essere montati come file o esposti come variabili d'ambiente, e l'accesso va limitato con RBAC.

PersistentVolume

Un PersistentVolume (PV) è una porzione di storage del cluster fornita da un amministratore o dinamicamente da una StorageClass, con un ciclo di vita indipendente da qualsiasi Pod. Astrae lo storage sottostante (disco cloud, NFS, driver CSI) dietro un'API uniforme. I Pod consumano i PV legandosi ad essi tramite i PersistentVolumeClaim.

PersistentVolumeClaim

Un PersistentVolumeClaim (PVC) è la richiesta di un utente di storage di una data dimensione e modalità di accesso, che Kubernetes lega a un PersistentVolume corrispondente. Permette ai carichi di richiedere storage senza conoscere i dettagli del provider sottostante. Con una StorageClass può innescare il provisioning dinamico di un nuovo PV.

StorageClass

Una StorageClass descrive una classe di storage (il suo provisioner, i parametri e la reclaim policy) e abilita il provisioning dinamico di PersistentVolume su richiesta. Quando un PVC referenzia una StorageClass, il cluster crea automaticamente un volume adeguatamente supportato. I cluster definiscono tipicamente una StorageClass predefinita per le richieste che ne omettono una.

Label e Selector

Una label è una coppia chiave-valore allegata a un oggetto Kubernetes per identificarlo e raggrupparlo; un selector interroga gli oggetti in base alle loro label. Service, Deployment e NetworkPolicy usano i selector per puntare ai Pod giusti in modo lasco, senza fissare identità rigide. Le label sono il meccanismo centrale per collegare gli oggetti in Kubernetes.

Probe di liveness

Una probe di liveness è un controllo periodico che il kubelet esegue per determinare se un container è ancora in salute; il suo fallimento provoca il riavvio del container. Rileva deadlock o stati bloccati in cui il processo è in esecuzione ma non avanza. Le probe possono essere HTTP, TCP o exec, con tempistiche configurabili.

Probe di readiness

Una probe di readiness determina se un container è pronto a ricevere traffico; finché fallisce, il Pod viene rimosso dagli endpoint del Service ma non riavviato. Evita di instradare richieste a un Pod che sta ancora avviandosi, scaldando le cache o temporaneamente sovraccarico. È distinta dalla probe di liveness, che governa i riavvii.

Richieste e limiti di risorse

Una richiesta (request) è la quantità di CPU o memoria che lo scheduler riserva per un container, mentre un limite (limit) è il massimo che può usare. Le richieste guidano lo scheduling e definiscono la classe QoS di un Pod; superare il limite di memoria causa un OOM kill, superare il limite di CPU causa throttling. Impostarle entrambe previene problemi di vicini rumorosi.

Horizontal Pod Autoscaler

L'Horizontal Pod Autoscaler (HPA) regola automaticamente il numero di repliche di Pod di un carico in base a metriche osservate come l'utilizzo CPU o metriche personalizzate. Interroga l'API delle metriche e scala il numero di repliche verso l'alto o il basso entro limiti configurati. Complementa, ed è distinto da, lo scaling verticale e l'autoscaling del cluster.

Helm

Helm è un package manager per Kubernetes che raggruppa manifest correlati in unità versionate e parametrizzabili chiamate chart. Il templating con file di values permette di riusare uno stesso chart tra ambienti, e i rilasci possono essere aggiornati o sottoposti a rollback. Semplifica l'installazione e la gestione di applicazioni complesse.

CNI (Container Network Interface)

La CNI è una specifica e un insieme di plugin che configurano le interfacce di rete per i container Linux, usata da Kubernetes per fornire il networking ai Pod. Un plugin CNI (Calico, Cilium, Flannel e altri) assegna gli IP ai Pod e implementa il modello di rete piatta del cluster così che ogni Pod possa raggiungere ogni altro Pod. Kubernetes di per sé non implementa il networking dei Pod; lo delega alla CNI.

NetworkPolicy

Una NetworkPolicy specifica come gruppi di Pod possono comunicare, agendo da firewall a livello di Pod tramite selettori di label per regole di ingress ed egress. Per impostazione predefinita i Pod accettano traffico da ovunque; una volta che un Pod è selezionato da una policy, è permesso solo il traffico consentito. Richiede un plugin CNI che supporti l'enforcement delle NetworkPolicy.

RBAC (Role-Based Access Control)

L'RBAC in Kubernetes governa chi può compiere quali azioni su quali risorse, tramite Role/ClusterRole (insiemi di permessi) legati a soggetti con RoleBinding/ClusterRoleBinding. Segue il principio del minimo privilegio ed è a livello di namespace (Role) o di cluster (ClusterRole). È il principale meccanismo di autorizzazione per l'API di Kubernetes.

Taint e Toleration

Un taint è applicato a un nodo per respingere i Pod che non lo tollerano, e una toleration su un Pod gli permette (ma non lo obbliga) di essere schedulato su un nodo con taint. Insieme permettono di riservare nodi a carichi specifici, come nodi GPU o nodi del control plane. Lavorano accanto alle regole di affinità, non al loro posto.

Operator

Un Operator è un pattern che estende Kubernetes con un controller personalizzato più delle Custom Resource Definition per automatizzare la gestione di una specifica applicazione (ad esempio provisioning, backup e failover di un database). Codifica la conoscenza operativa umana in software che riconcilia una custom resource. Gli Operator sono il modo in cui le applicazioni stateful e complesse vengono gestite in modo dichiarativo.