🥇Le sonde di attività in Kubernetes possono essere pericolose

Nota. trad.: L'ingegnere capo di Zalando, Henning Jacobs, ha ripetutamente notato problemi tra gli utenti di Kubernetes nel comprendere lo scopo dei sondaggi di attività (e prontezza) e il loro corretto utilizzo. Ha quindi raccolto i suoi pensieri in questa capiente nota, che col tempo entrerà a far parte della documentazione del K8.

Controlli dello stato, noti in Kubernetes come sonde di vitalità (cioè, letteralmente, "test di vitalità" - trad. ca.), può essere piuttosto pericoloso. Consiglio di evitarli se possibile: le uniche eccezioni sono quando sono veramente necessarie e si è pienamente consapevoli delle specificità e delle conseguenze del loro utilizzo. Questa pubblicazione parlerà dei controlli di attività e disponibilità e ti dirà anche in quali casi Costo e non dovresti usarli.

Il mio collega Sandor ha recentemente condiviso su Twitter gli errori più comuni che incontra, compresi quelli relativi all'uso delle sonde di prontezza/attività:

Configurato in modo errato livenessProbe può aggravare le situazioni di carico elevato (arresto valanga + tempo di avvio del contenitore/applicazione potenzialmente lungo) e portare ad altre conseguenze negative come la riduzione delle dipendenze (Guarda anche il mio recente articolo sulla limitazione del numero di richieste nella combinazione K3s+ACME). È ancora peggio quando la sonda di attività è combinata con un controllo dello stato, che è un database esterno: un singolo errore del DB riavvierà tutti i tuoi contenitori!

Messaggio generale "Non utilizzare sonde di attività" in questo caso non aiuta molto, quindi vediamo a cosa servono i controlli di prontezza e attività.

Nota: la maggior parte dei test riportati di seguito erano originariamente inclusi nella documentazione interna degli sviluppatori di Zalando.

Controlli di disponibilità e attività

Kubernetes fornisce due importanti meccanismi chiamati sonde di vitalità e sonde di prontezza. Eseguono periodicamente alcune azioni, come l'invio di una richiesta HTTP, l'apertura di una connessione TCP o l'esecuzione di un comando nel contenitore, per confermare che l'applicazione funziona come previsto.

Utilizza Kubernetes sonde di prontezzaper capire quando il contenitore è pronto ad accettare il traffico. Un pod è considerato pronto all'uso se tutti i suoi contenitori sono pronti. Un utilizzo di questo meccanismo è controllare quali pod vengono utilizzati come backend per i servizi Kubernetes (e in particolare Ingress).

Sonde di vitalità aiutare Kubernetes a capire quando è il momento di riavviare il contenitore. Ad esempio, un tale controllo consente di intercettare una situazione di stallo quando un'applicazione rimane bloccata in un punto. Il riavvio del contenitore in questo stato aiuta a far decollare l'applicazione nonostante gli errori, ma può anche portare a errori a catena (vedere di seguito).

Se provi a distribuire un aggiornamento dell'applicazione che non supera i controlli di attività/idoneità, la sua implementazione verrà bloccata mentre Kubernetes attende lo stato Ready da tutti i pod.

esempio

Ecco un esempio di una sonda di disponibilità che controlla un percorso /health tramite HTTP con impostazioni predefinite (intervallo: 10 secondi, timeout: 1 secondo, soglia di successo: 1, soglia di fallimento: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Raccomandazioni

Per i microservizi con endpoint HTTP (REST e così via) definire sempre una sonda di disponibilità, che controlla se l'applicazione (pod) è pronta ad accettare il traffico.
Assicurarsi che la sonda sia pronta copre la disponibilità della porta effettiva del server web:
- utilizzando le porte per scopi amministrativi, chiamate "admin" o "management" (ad esempio, 9090), per readinessProbe, assicurati che l'endpoint restituisca OK solo se la porta HTTP primaria (come 8080) è pronta ad accettare il traffico*;
  *Sono a conoscenza di almeno un caso su Zalando in cui ciò non è avvenuto, ovvero readinessProbe Ho controllato la porta "di gestione", ma il server stesso non ha iniziato a funzionare a causa di problemi nel caricamento della cache.
- collegare una sonda di disponibilità a una porta separata può portare al fatto che il sovraccarico sulla porta principale non si rifletterà nel controllo dello stato (ovvero, il pool di thread sul server è pieno, ma il controllo dello stato mostra comunque che tutto è a posto ).
едитесь, то la sonda di disponibilità consente l'inizializzazione/migrazione del database;
- Il modo più semplice per ottenere ciò è contattare il server HTTP solo dopo aver completato l'inizializzazione (ad esempio, migrando un database da flyway e così via.); ovvero, invece di modificare lo stato del controllo dello stato, è sufficiente non avviare il server Web fino al completamento della migrazione del database*.
  * Puoi anche eseguire migrazioni di database da contenitori init esterni al pod. Sono ancora un fan delle applicazioni autonome, ovvero quelle in cui il contenitore dell'applicazione sa come portare il database nello stato desiderato senza coordinamento esterno.
Utilizzare httpGet per i controlli di preparazione attraverso tipici endpoint di controllo dello stato (ad esempio, /health).
Comprendere i parametri di controllo predefiniti (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- le opzioni predefinite indicano che il pod diventerà non pronto dopo circa 30 secondi (3 controlli di integrità falliti).
Utilizza una porta separata per "amministrazione" o "gestione" se lo stack tecnologico (ad esempio Java/Spring) lo consente, per separare la gestione dell'integrità e delle metriche dal traffico regolare:
- ma non dimenticare il punto 2.
Se necessario, la sonda di disponibilità può essere utilizzata per riscaldare/caricare la cache e restituire un codice di stato 503 finché il contenitore non si riscalda:
- Ti consiglio anche di leggere il nuovo assegno startupProbe, è apparso nella versione 1.16 (ne abbiamo scritto in russo qui - ca. trad.).

Precauzioni

Non fare affidamento su dipendenze esterne (come i data warehouse) durante l'esecuzione di test di disponibilità/attività: ciò può portare a errori a cascata:
- Ad esempio, prendiamo un servizio REST con stato con 10 pod che dipendono da un database Postgres: quando il controllo dipende da una connessione funzionante al DB, tutti e 10 i pod potrebbero fallire se c'è un ritardo sul lato rete/DB - di solito tutto finisce peggio di quanto potrebbe;
- Tieni presente che Spring Data controlla la connessione al database per impostazione predefinita*;
  * Questo è il comportamento predefinito di Spring Data Redis (almeno è stata l'ultima volta che ho controllato), che ha portato a un errore "catastrofico": quando Redis non è stato disponibile per un breve periodo, tutti i pod "si sono bloccati".
- “esterno” in questo senso può significare anche altri pod della stessa applicazione, cioè idealmente il controllo non dovrebbe dipendere dallo stato di altri pod dello stesso cluster per evitare crash a cascata:
  - i risultati possono variare per le applicazioni con stato distribuito (ad esempio, memorizzazione nella cache in memoria nei pod).
Non utilizzare una sonda di vitalità per i pod (fanno eccezione i casi in cui sono realmente necessari e si è pienamente consapevoli delle specificità e delle conseguenze del loro utilizzo):
- Una sonda di attività può aiutare a ripristinare i contenitori bloccati, ma poiché hai il pieno controllo sulla tua applicazione, cose come processi bloccati e deadlock idealmente non dovrebbero accadere: l'alternativa migliore è mandare in crash deliberatamente l'applicazione e riportarla allo stato stazionario precedente;
- un'analisi di attività non riuscita causerà il riavvio del contenitore, quindi potenzialmente esacerbando le conseguenze degli errori relativi al caricamento: il riavvio del contenitore comporterà tempi di inattività (almeno per la durata dell'avvio dell'applicazione, diciamo 30 secondi e passa), causando nuovi errori , aumentando il carico su altri contenitori e aumentando la probabilità del loro guasto, ecc.;
- i controlli di attività combinati con una dipendenza esterna sono la peggiore combinazione possibile, minacciando errori a cascata: un leggero ritardo sul lato database porterà al riavvio di tutti i tuoi contenitori!
Parametri dei controlli di vitalità e disponibilità deve essere diverso:
- puoi utilizzare un sondaggio di attività con lo stesso controllo di integrità, ma una soglia di risposta più alta (failureThreshold), ad esempio, assegnare lo stato non pronto dopo 3 tentativi e considerare che la sonda di attività ha fallito dopo 10 tentativi;
Non utilizzare controlli esecutivi, poiché sono associati a problemi noti che portano alla comparsa di processi zombie:
- dettagli: cfr presentazione da parte degli specialisti Datadog.

Riassunto

Utilizza le sonde di disponibilità per determinare quando un pod è pronto per ricevere traffico.
Utilizza le sonde di attività solo quando sono realmente necessarie.
L'uso improprio delle sonde di disponibilità/attività può portare a una disponibilità ridotta e a errori a catena.

Materiali aggiuntivi sull'argomento

Documenti Kubernetes: Configurare i proxy di attività e disponibilità;
Rivisitazione delle sonde di attività e prontezza di Kubernetes: come evitare di spararsi dall'altra parte;
Interruzione post-mortem di NRE Labs (parla anche di livenessProbe).

Aggiornamento n. 1 del 2019-09-29

Informazioni sui contenitori init per la migrazione del database: aggiunta la nota a piè di pagina.

EJ me lo ha ricordato riguardo al PDB: uno dei problemi con i controlli di attività è la mancanza di coordinamento tra i pod. Kubernetes ha Budget per l'interruzione dei pod (PDB) per limitare il numero di errori simultanei che un'applicazione può riscontrare, tuttavia i controlli non tengono conto del PDB. Idealmente, potremmo dire ai K8 di "Riavviare un pod se il test fallisce, ma non riavviarli tutti per evitare di peggiorare le cose".

Bryan l'ha detto perfettamente: “Usa il sondaggio della vitalità quando sai esattamente cosa la cosa migliore da fare è uccidere l'applicazione"(ancora una volta, non lasciarti trasportare).

Aggiornamento n. 2 del 2019-09-29

Per quanto riguarda la lettura della documentazione prima dell'uso: ho creato la richiesta corrispondente (richiesta di funzionalità) per aggiungere documentazione sulle sonde di attività.

Le sonde di attività in Kubernetes possono essere pericolose