Konfigurieren Sie Container-Lebenszyklus-Hooks

Während eines ordnungsgemäßen Herunterfahrens des Containers sollte Ihre Anwendung auf ein SIGTERM Signal reagieren und das Herunterfahren starten, damit es bei den Clients nicht zu Ausfallzeiten kommt. In Ihrer Anwendung sollten beispielsweise die folgenden Bereinigungsverfahren ausgeführt werden:

• Daten werden gespeichert

• Dateideskriptoren werden geschlossen

• Datenbankverbindungen werden geschlossen

• Anfragen während des Fluges ordnungsgemäß bearbeiten

• Rechtzeitiges Beenden, um die Anfrage zur Kündigung des Pods zu erfüllen

Legen Sie eine Übergangsfrist fest, die lang genug ist, damit die Bereinigung abgeschlossen werden kann. Informationen dazu, wie Sie auf das SIGTERM Signal reagieren, finden Sie in der Dokumentation der Programmiersprache, die Sie für Ihre Anwendung verwenden.

Container-Lifecycle-Hooks ermöglichen es Containern, Ereignisse in ihrem Management-Lebenszyklus zu erkennen. Container können Code ausführen, der in einem Handler implementiert ist, wenn der entsprechende Lifecycle-Hook ausgeführt wird. Container-Lifecycle-Hooks bieten eine Problemumgehung für die asynchrone Natur von Kubernetes und der Cloud. Dieser Ansatz kann den Verlust von Verbindungen verhindern, die vor der Eingangsressource an den abschließenden Pod weitergeleitet und aktualisiert iptables werden, sodass kein neuer Datenverkehr an den Pod gesendet wird.

Container Lifecycle und Endpoint EndpointSlice sind Teil verschiedener Systeme. APIs Es ist wichtig, diese APIs zu orchestrieren. Wenn ein Pod jedoch beendet wird, benachrichtigt die Kubernetes-API gleichzeitig sowohl das Kubelet (für Container Lifecycle) als auch den Controller. EndpointSlice Weitere Informationen, einschließlich eines Diagramms, finden Sie in den EKS Best Practices Guides unter Sorgfältige Bearbeitung von Client-Anfragen.

Beim kubelet Senden SIGTERM an den Pod beendet der EndpointSlice Controller das Objekt. EndpointSlice Durch diese Kündigung werden die Kubernetes-API-Server benachrichtigt, sie über jeden Knoten zu informieren, kube-proxy der aktualisiert werden soll. iptables Obwohl diese Aktionen gleichzeitig ausgeführt werden, gibt es keine Abhängigkeiten oder Sequenzen zwischen ihnen. Es besteht eine hohe Wahrscheinlichkeit, dass der Container das SIGKILL Signal viel früher empfängt, als die lokalen iptables Regeln kube-proxy auf jedem Knoten aktualisiert werden. In diesem Fall sind unter anderem folgende Szenarien möglich:

• Wenn Ihre Anwendung die laufenden Anfragen und Verbindungen nach Erhalt der Clients sofort und unverblümt verwirft, treten Fehler SIGTERM, auf. 500

• Wenn Ihre Anwendung sicherstellt, dass alle laufenden Anfragen und Verbindungen nach Erhalt vollständig bearbeitet werdenSIGTERM, werden während der Übergangszeit neue Kundenanfragen trotzdem an den Anwendungscontainer gesendet, da die iptables Regeln möglicherweise noch nicht aktualisiert wurden. Solange das Bereinigungsverfahren den Server-Socket auf dem Container nicht schließt, führen diese neuen Anfragen zu neuen Verbindungen. Nach Ablauf der Karenzzeit werden die neuen Verbindungen, die nach dem SIGTERM Senden von hergestellt wurden, bedingungslos gelöscht.

Um die vorherigen Szenarien zu berücksichtigen, können Sie die In-App-Integration oder den PreStop Lifecycle-Hook implementieren. Weitere Informationen, einschließlich eines Diagramms, finden Sie unter Anwendungen ordnungsgemäß herunterfahren in den EKS Best Practices Guides.

Hinweis: Unabhängig davon, ob die Anwendung ordnungsgemäß heruntergefahren wird oder ob das Ergebnis des preStop Hooks ist, werden die Anwendungscontainer am Ende der Übergangszeit bis zum Ende der Übergangszeit beendet. SIGKILL

Verwenden Sie den preStop Hook mit einem sleep Befehl, um das Senden zu verzögern. SIGTERM Dies hilft dabei, die neuen Verbindungen weiterhin zu akzeptieren, während das Eingangsobjekt sie an den Pod weiterleitet. Testen Sie den Zeitwert des sleep Befehls, um sicherzustellen, dass die Latenz von Kubernetes und anderen Anwendungsabhängigkeiten berücksichtigt werden, wie im folgenden Beispiel gezeigt:

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

Weitere Informationen finden Sie unter Container-Hooks und EKS Best Practices — Load Balancing (Anwendungen ordnungsgemäß herunterfahren).