Configura i ganci del ciclo di vita dei container

Durante uno spegnimento regolare del contenitore, l'applicazione dovrebbe rispondere a un SIGTERM segnale avviandone lo spegnimento, in modo che i client non subiscano tempi di inattività. L'applicazione deve eseguire procedure di pulizia come le seguenti:

• Salvataggio dei dati

• Chiusura dei descrittori di file

• Chiusura delle connessioni al database

• Completamento delle richieste in volo con garbo

• Uscire tempestivamente per soddisfare la richiesta di terminazione del pod

Imposta un periodo di grazia sufficientemente lungo per completare la pulizia. Per informazioni su come rispondere al SIGTERM segnale, consultate la documentazione relativa al linguaggio di programmazione utilizzato per l'applicazione.

Gli hook del ciclo di vita dei container consentono ai contenitori di essere consapevoli degli eventi del loro ciclo di vita di gestione. I contenitori possono eseguire il codice implementato in un gestore quando viene eseguito l'hook del ciclo di vita corrispondente. Gli hook del ciclo di vita dei container forniscono una soluzione alternativa per la natura asincrona di Kubernetes e del cloud. Questo approccio può prevenire la perdita delle connessioni che vengono inoltrate al pod di terminazione prima che la risorsa di ingresso entri e vengono aggiornate per non inviare nuovo traffico al pod. iptables

Il ciclo di vita dei container e l'endpoint fanno parte di qualcosa di diverso. EndpointSlice APIs È importante orchestrarli. APIs Tuttavia, quando un pod viene chiuso, l'API Kubernetes notifica contemporaneamente sia il kubelet (per Container Lifecycle) che il controller. EndpointSlice Per ulteriori informazioni, incluso un diagramma, consulta Gestire con garbo le richieste dei client nelle guide alle best practice di EKS.

Quando viene kubelet inviato SIGTERM al pod, il EndpointSlice controller termina l'oggetto. EndpointSlice Tale terminazione notifica ai server dell'API Kubernetes di notificare ogni nodo da aggiornare. kube-proxy iptables Sebbene queste azioni avvengano contemporaneamente, non vi sono dipendenze o sequenze tra di esse. È molto probabile che il contenitore riceva il SIGKILL segnale molto prima dell'aggiornamento delle regole locali kube-proxy iptables su ciascun nodo. In tal caso, gli scenari possibili includono quanto segue:

• Se la tua candidatura elimina immediatamente e senza mezzi termini le richieste e le coincidenze in volo al ricevimento dei clienti, vedi SIGTERM, degli errori. 500

• Se l'applicazione garantisce che tutte le richieste e le coincidenze in volo vengano elaborate completamente al momento della ricezioneSIGTERM, durante il periodo di prova, le nuove richieste dei clienti verranno comunque inviate al contenitore dell'applicazione perché iptables le regole potrebbero non essere ancora aggiornate. Fino a quando la procedura di pulizia non chiuderà il socket del server sul contenitore, tali nuove richieste comporteranno nuove connessioni. Al termine del periodo di prova, le nuove connessioni stabilite dopo l'SIGTERMinvio vengono interrotte incondizionatamente.

Per risolvere gli scenari precedenti, puoi implementare l'integrazione in-app o il PreStop lifecycle hook. Per ulteriori informazioni, incluso un diagramma, consulta Gracefully shutdown delle applicazioni nelle guide alle best practice di EKS.

Nota: indipendentemente dal fatto che l'applicazione si chiuda correttamente o che sia il risultato dell'preStophook, i contenitori delle applicazioni vengono terminati alla fine del periodo di prova. SIGKILL

Utilizzate l'preStophook con un sleep comando per ritardare l'invio. SIGTERM Ciò contribuirà a continuare ad accettare le nuove connessioni mentre l'oggetto di ingresso le indirizza al pod. Verifica il valore temporale del sleep comando per assicurarti che venga presa in considerazione l'eventuale latenza di Kubernetes e altre dipendenze dell'applicazione, come mostrato nell'esempio seguente:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      lifecycle:
        # This "sleep" preStop hook delays the Pod shutdown until
        # after the Ingress Controller removes the matching Endpoint or EndpointSlice
        preStop:
          exec:
            command:
              - /bin/sleep
              - "20"
              # This period should be turned to Ingress/Service Mesh update latency

Per ulteriori informazioni, consulta Container hooks e EKS Best Practices — Load Balancing (Gracefully shutdown applications).