Liveness riavvia il container. Readiness lo toglie dal Service, il processo resta su. Startup copre l’avvio lento. HTTP: successo 200–399. Non è un 429. Non è Lighthouse.
Un endpoint /health non è un mestiere solo. Liveness fa riavviare il container. Readiness lo toglie dal Service. Startup tiene ferme le altre due finché l’app non è partita. Non sono la stessa probe. Verifica del 9 ottobre 2026 su kubernetes.io (ultima modifica 30 giugno 2026).
In breve: liveness fallita → kubelet riavvia. Readiness fallita → via dagli EndpointSlice, il processo resta su. Startup fallita → kill e restartPolicy. HTTP: successo 200–399. Non è un 429. Non è Lighthouse.
Cosa trovi in questo articolo
Tre probe, tre effetti
La pagina Liveness, Readiness, and Startup Probes di Kubernetes, rilettura 9 ottobre 2026 (last modified 30 giugno 2026): una probe è una diagnostica periodica del kubelet su un container. O esegue codice nel container, o fa una richiesta di rete. Il cluster è Operatività. Non è un header HTTP di rate limit: quello sta in 429 e Retry-After.
| In pagina (rilettura 9 ottobre 2026) | |
|---|---|
| Startup | Verifica se l’app è partita. Finché non ha successo, liveness e readiness non girano. Si esegue solo all’avvio. Se fallisce, il kubelet uccide il container; vale la restartPolicy. |
| Liveness | Decide quando riavviare. Esempio in pagina: deadlock, processo vivo ma fermo. Oltre la soglia di fallimenti, il kubelet riavvia. Non aspetta che la readiness abbia successo. |
| Readiness | Decide quando accettare traffico (file da caricare, cache da scaldare, dipendenze, sovraccarico temporaneo). Fallita: il controller EndpointSlice toglie l’IP del Pod da tutti i Service che lo selezionano. Gira per tutto il ciclo di vita. |
| Indipendenza | Caution in pagina: readiness e liveness «do not depend on each other to succeed». Per aspettare prima della readiness: initialDelaySeconds o una startup probe. |
| Default period | periodSeconds di default 10 s. Esempio startup: failureThreshold × periodSeconds = 30 × 10 = 300 s di margine all’avvio, poi prende il sopravvento la liveness. |
Caution sulla liveness, stessa pagina: va configurata perché indichi un fallimento irrecuperabile, per esempio un deadlock. Un’implementazione sbagliata produce cascading failures: riavvii sotto carico, meno scalabilità, più lavoro sui Pod rimasti. Capire la differenza, poi applicarla.
Quando servirne una (e quando no)
Stessa scheda, sezione «When to use each probe».
Startup. Container che mettono tempo a entrare in servizio. Invece di allungare l’intervallo della liveness, si dà una finestra più lunga all’avvio. Se di solito parte in più di initialDelaySeconds + failureThreshold × periodSeconds, si punta la stessa endpoint della liveness e si alza solo la failureThreshold della startup, senza toccare i default della liveness.
Liveness. Se il processo già esce da solo quando è malato, «you do not necessarily need a liveness probe»: il kubelet segue la restartPolicy. Se vuoi che un fallimento di probe uccida e riavvii, serve liveness e restartPolicy Always o OnFailure. Pattern in pagina: stessa endpoint HTTP a basso costo della readiness, failureThreshold più alta sulla liveness, così il Pod resta unready un po’ prima del kill.
Readiness. Traffico solo dopo il successo. Può coincidere con la liveness: la sola presenza della readiness fa partire il Pod senza traffico. Utile anche per mettersi in manutenzione su un endpoint diverso. Dipendenza stretta da un backend: liveness sull’app, readiness anche sul backend, per non mandare richieste a chi può rispondere solo con errori. Dati o migrazioni lunghe in avvio: startup; se serve distinguere «è rotta» da «sta ancora caricando», readiness.
Nota in pagina: per drenare le richieste in cancellazione del Pod non serve per forza una readiness. In cancellazione l’endpoint negli EndpointSlice passa ready: false. Dettaglio nel Pod Lifecycle.
exec, HTTP, TCP, gRPC
Ogni probe definisce esattamente uno di quattro meccanismi. Tutorial Configure Liveness, Readiness and Startup Probes, stessa data di modifica.
| Meccanismo | Successo in pagina |
|---|---|
| exec | Comando nel container, exit 0. Caution: fork di processi a ogni giro; su nodi densi e intervalli bassi pesa sulla CPU. In quel caso gli altri tre. |
| httpGet | GET sull’IP del Pod, porta e path. Successo: status ≥ 200 e < 400. Qualunque altro codice è fallimento. |
| tcpSocket | Porta aperta. Se il remoto chiude subito dopo l’open, conta comunque come healthy. |
| grpc | Stabile da Kubernetes v1.27. Health Checking Protocol, stato SERVING. Di default in chiaro; gli errori sono tutti failure, niente codici distinti. Timeout di default 1 s. |
HTTP/2 cleartext (h2c) sulle probe HTTP: feature gate H2CContainerProbe, alpha da v1.37, disabilitata di default. Non è il default. Non si tratta come disponibile in produzione solo perché compare in pagina.
Il monitoring applicativo e i backup restano un altro mestiere: monitoring del sito, backup. Una probe non sostituisce né l’uno né l’altro.
Errori da evitare
Usare la liveness come se fosse la readiness: sotto carico la probe fallisce, il kubelet riavvia, il carico peggiora. Caution ufficiale: cascading failures.
Allungare all’infinito
initialDelaySecondsdella liveness per un avvio lento: in pagina c’è la startup.Trattare TCP «porta aperta» come «l’app risponde 200»: in pagina basta il socket.
Puntare gRPC in TLS senza il feature gate: di default la probe gRPC è plaintext.
Mettere un exec ogni pochi secondi su un nodo pieno di Pod: in pagina è overhead di CPU.
Confondere una probe con un 429 o con uno score Lighthouse: altri articoli, altri strumenti.
In sintesi
Liveness riavvia. Readiness toglie il traffico. Startup copre l’avvio lento. HTTP 200–399, exec 0, TCP porta aperta, gRPC SERVING. Non sono la stessa sonda. Si rilegge kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/ il giorno in cui si scrive lo spec. Verifica del 9 ottobre 2026.
