Configura le sonde e i controlli dello stato del load balancer - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configura le sonde e i controlli dello stato del load balancer

Kubernetes offre diversi modi per eseguire i controlli dello stato delle applicazioni oltre ai controlli dello stato del bilanciamento del carico. Puoi eseguire le seguenti sonde integrate di Kubernetes insieme al controllo dello stato del bilanciamento del carico come comando nel contesto del pod o come sonda HTTP/TCP verso kubelet o l'indirizzo IP dell'host.

Le sonde Liveness e le sonde Readiness devono essere diverse e indipendenti (o almeno con valori di timeout diversi). Se un'applicazione presenta un problema temporaneo, la sonda di prontezza contrassegnerà il pod come non pronto finché il problema non sarà risolto. Se le impostazioni della sonda livenss non sono corrette, la sonda liveness potrebbe terminare il pod.

Sonda di avvio

Utilizzate le sonde di avvio per proteggere le applicazioni con cicli di inizializzazione lunghi. Fino a quando la sonda di avvio non ha esito positivo, le altre sonde sono disattivate.

Puoi definire un tempo massimo di attesa per Kubernetes per l'avvio dell'applicazione. Se, dopo il tempo massimo configurato, il pod continua a non rispondere ai test di avvio, l'applicazione viene terminata e viene creato un nuovo pod.

Utilizzate le sonde di avvio quando l'ora di avvio di un'applicazione è imprevedibile. Se sapete che l'applicazione richiede 10 secondi per avviarsi, utilizzate invece una sonda di vivacità o una sonda di prontezza. initialDelaySeconds

Sonda di vivacità

Utilizza le sonde Liveness per rilevare i problemi delle applicazioni o se il processo è in esecuzione senza problemi. Una sonda di liveness è in grado di rilevare condizioni di stallo in cui il processo continua a funzionare ma l'applicazione non risponde. Quando utilizzate una sonda di vivacità, effettuate le seguenti operazioni:

  • initialDelaySecondsUsare per ritardare la prima sonda.

  • Non impostate le stesse specifiche per le sonde di vivacità e prontezza.

  • Non configurate una sonda di liveness in modo che dipenda da un fattore esterno al vostro pod (ad esempio, un database).

  • Imposta la sonda di vivacità per uno specifico. terminationGracePeriodSeconds Per ulteriori informazioni, consulta la documentazione di Kubernetes.

Sonda di prontezza

Utilizzate una sonda di prontezza per rilevare quanto segue:

  • Se l'applicazione è pronta ad accettare il traffico

  • Disponibilità parziale, in cui l'applicazione potrebbe essere temporaneamente non disponibile ma dovrebbe essere nuovamente integra dopo il completamento di una determinata operazione

Le sonde di prontezza aiutano a garantire che la configurazione e le dipendenze dell'applicazione vengano eseguite senza problemi o errori, in modo che l'applicazione possa servire il traffico. Tuttavia, una sonda di prontezza configurata in modo errato può causare un'interruzione anziché prevenirla. Le sonde di prontezza che dipendono da fattori esterni, come la connettività a un database, possono causare il malfunzionamento della sonda in tutti i pod. Tali errori possono causare un'interruzione e un guasto a catena da un servizio di backend ad altri servizi che utilizzavano i pod guasti.

Controlli dello stato delle risorse e del load balancer in ingresso

Application Load Balancer e ingress Kubernetes offrono funzionalità di controllo dello stato. Per i controlli di integrità dell'Application Load Balancer, specifica le porte e il percorso di destinazione.

Nota: per Kubernetesingress, ci sarà una latenza di annullamento della registrazione. L'impostazione predefinita per Application Load Balancer è 300 secondi. Valuta la possibilità di configurare il controllo dello stato delle risorse in ingresso o del load balancer utilizzando gli stessi valori utilizzati per la sonda di prontezza. 

NGINX fornisce anche un controllo dello stato di salute. Per ulteriori informazioni, consulta la documentazione di NGINX.

I gateway di ingresso e uscita Istio non dispongono di un meccanismo di controllo dello stato paragonabile al controllo dello stato di integrità HTTP di NGINX. Tuttavia, è possibile ottenere funzionalità simili utilizzando l'interruttore automatico Istio o il rilevamento dei valori anomali. DestinationRule

Per ulteriori informazioni, consulta EKS Best Practices — Load Balancing (Availability and Pod Lifecycle).