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
<a name="lifecycle-hooks"></a>

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](https://kubernetes.io/docs/concepts/containers/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](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_handle_the_client_requests) 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 verwirft`SIGTERM`, werden den Clients Fehler angezeigt. `500`
+ Wenn Ihre Anwendung sicherstellt, dass alle laufenden Anfragen und Verbindungen nach Erhalt vollständig bearbeitet werden`SIGTERM`, 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](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) 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](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) in der Kubernetes-Dokumentation und [Gracefully shutdown applications](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) im *Amazon EKS* Best Practices Guide.