View a markdown version of this page

Konfigurieren Sie Container-Lebenszyklus-Hooks - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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. Ihre Anwendung sollte Bereinigungsverfahren wie die folgenden ausführen:

  • 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, bis die Bereinigung abgeschlossen ist. 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-Lebenszyklus Endpoint und EndpointSlice sind Teil verschiedener APIs. Es ist wichtig, diese APIs zu orchestrieren. Wenn ein Pod jedoch beendet wird, benachrichtigt die Kubernetes-API gleichzeitig sowohl das Kubelet (für den Container-Lebenszyklus) als auch den Controller. EndpointSlice Weitere Informationen, einschließlich eines Diagramms, finden Sie unter Sorgfältige Bearbeitung von Kundenanfragen im Amazon EKS Best Practices Guide.

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 sofort und unverblümt verwirftSIGTERM, werden den Clients Fehler angezeigt. 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 im Amazon EKS Best Practices Guide.

Anmerkung

Unabhängig davon, ob die Anwendung ordnungsgemäß heruntergefahren wird oder ob das Ergebnis des preStop Hooks ist, werden die Anwendungscontainer am 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 in der Kubernetes-Dokumentation und Gracefully shutdown applications im Amazon EKS Best Practices Guide.