Haben Sie schon einmal aus Frust das Netzkabel aus Ihrem Computer gerissen? Das mag zwar wie eine schnelle Lösung erscheinen, kann aber zu Datenverlust und Systeminstabilität führen. In der Softwarewelt gibt es ein ähnliches Konzept: das harte Herunterfahren. Dieses abrupte Beenden kann genau wie sein physisches Gegenstück Probleme verursachen. Zum Glück gibt es eine bessere Möglichkeit: das ordnungsgemäße Herunterfahren. Durch die Integration eines ordnungsgemäßen Herunterfahrens benachrichtigen wir den Dienst im Voraus. Dadurch kann er laufende Anfragen abschließen, Statusinformationen ggf. auf der Festplatte speichern und letztendlich Datenbeschädigungen beim Herunterfahren vermeiden. In diesem Handbuch geht es um die Welt des ordnungsgemäßen Herunterfahrens, wobei der Schwerpunkt insbesondere auf der Implementierung in liegt, die auf Kubernetes ausgeführt werden. Go-Anwendungen Signale in Unix-Systemen Eines der wichtigsten Tools zum Erreichen eines reibungslosen Herunterfahrens in Unix-basierten Systemen ist das Konzept der Signale. Vereinfacht ausgedrückt handelt es sich dabei um eine einfache Möglichkeit, einem Prozess eine bestimmte Sache von einem anderen Prozess aus mitzuteilen. Wenn wir verstehen, wie Signale funktionieren, können wir sie nutzen, um kontrollierte Beendigungsverfahren in unseren Anwendungen zu implementieren und so einen reibungslosen und datensicheren Herunterfahrvorgang sicherzustellen. Es gibt viele Signale und Sie können sie finden, aber uns interessieren nur die Abschaltsignale: hier – wird an einen Prozess gesendet, um dessen Beendigung anzufordern. Wird am häufigsten verwendet und wir werden uns später darauf konzentrieren. SIGTERM – „sofort beenden“, kann nicht beeinflusst werden. SIGKILL - Unterbrechungssignal (z. B. Strg+C) SIGINT - Beendigungssignal (z. B. Strg+D) SIGQUIT Diese Signale können vom Benutzer (Strg+C / Strg+D), von einem anderen Programm/Prozess oder vom System selbst (Kernel / Betriebssystem) gesendet werden. Beispielsweise wird ein (auch bekannt als Segmentierungsfehler) vom Betriebssystem gesendet. SIGSEGV Unser Meerschweinchen-Service Um die Welt der ordnungsgemäßen Herunterfahren in einer praktischen Umgebung zu erkunden, erstellen wir einen einfachen Dienst, mit dem wir experimentieren können. Dieser „Versuchskaninchen“-Dienst verfügt über einen einzelnen Endpunkt, der einige reale Aufgaben simuliert (wir fügen eine leichte Verzögerung hinzu), indem er -Befehl von Redis aufruft. Wir stellen auch eine grundlegende Kubernetes-Konfiguration bereit, um zu testen, wie die Plattform mit Beendigungssignalen umgeht. den INCR Das ultimative Ziel: sicherzustellen, dass unser Dienst Herunterfahren ordnungsgemäß bewältigt, ohne dass Anfragen/Daten verloren gehen. Indem wir die Anzahl der parallel gesendeten Anfragen mit dem endgültigen Zählerwert in Redis vergleichen, können wir überprüfen, ob unsere Implementierung des ordnungsgemäßen Herunterfahrens erfolgreich ist. Wir werden nicht näher auf die Einrichtung des Kubernetes-Clusters und von Redis eingehen, aber Sie finden das . vollständige Setup in unserem Github-Repository Der Verifizierungsprozess läuft wie folgt ab: Stellen Sie Redis- und Go-Anwendungen in Kubernetes bereit. Verwenden Sie , um 1000 Anfragen zu senden (25/s über 40 Sekunden). Vegeta Initialisieren Sie, während Vegeta ausgeführt wird, ein Kubernetes indem Sie den Image-Tag aktualisieren. Rolling Update, Stellen Sie eine Verbindung zu Redis her, um den „Zähler“ zu überprüfen. Er sollte 1000 betragen. Beginnen wir mit unserem grundlegenden Go HTTP-Server. Hard-Shutdown/main.go package main import ( "net/http" "os" "time" "github.com/go-redis/redis" ) func main() { redisdb := redis.NewClient(&redis.Options{ Addr: os.Getenv("REDIS_ADDR"), }) server := http.Server{ Addr: ":8080", } http.HandleFunc("/incr", func(w http.ResponseWriter, r *http.Request) { go processRequest(redisdb) w.WriteHeader(http.StatusOK) }) server.ListenAndServe() } func processRequest(redisdb *redis.Client) { // simulate some business logic here time.Sleep(time.Second * 5) redisdb.Incr("counter") } Wenn wir unser Überprüfungsverfahren mit diesem Code ausführen, sehen wir, dass einige Anfragen fehlschlagen und der (die Zahl kann bei jedem Durchlauf variieren). Zähler unter 1000 liegt Das bedeutet eindeutig, dass wir während des Rolling Updates einige Daten verloren haben. 😢 Signalbehandlung in Go Go bietet ein , mit dem Sie Unix-Signale verarbeiten können. Es ist wichtig zu beachten, dass SIGINT- und SIGTERM-Signale standardmäßig dazu führen, dass das Go-Programm beendet wird. Und damit unsere Go-Anwendung nicht so abrupt beendet wird, müssen wir eingehende Signale verarbeiten. Signalpaket Hierzu gibt es zwei Möglichkeiten. Kanal verwenden: c := make(chan os.Signal, 1) signal.Notify(c, syscall.SIGTERM) Kontext verwenden (heutzutage bevorzugter Ansatz): ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM) defer stop() gibt eine Kopie des übergeordneten Kontexts zurück, die als „erledigt“ markiert ist (sein „Erledigt“-Kanal ist geschlossen), wenn eines der aufgelisteten Signale eintrifft, wenn die zurückgegebene Funktion aufgerufen wird oder wenn der „Erledigt“-Kanal des übergeordneten Kontexts geschlossen wird, je nachdem, was zuerst eintritt. NotifyContext stop() Es gibt einige Probleme mit unserer aktuellen Implementierung des HTTP-Servers: Wir haben eine langsame ProcessRequest-Goroutine, und da wir das Beendigungssignal nicht behandeln, wird das Programm automatisch beendet, was bedeutet, dass alle laufenden Goroutinen ebenfalls beendet werden. Das Programm schließt keine Verbindungen. Lass es uns neu schreiben. ordnungsgemäßes Herunterfahren/main.go package main // imports var wg sync.WaitGroup func main() { ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM) defer stop() // redisdb, server http.HandleFunc("/incr", func(w http.ResponseWriter, r *http.Request) { wg.Add(1) go processRequest(redisdb) w.WriteHeader(http.StatusOK) }) // make it a goroutine go server.ListenAndServe() // listen for the interrupt signal <-ctx.Done() // stop the server if err := server.Shutdown(context.Background()); err != nil { log.Fatalf("could not shutdown: %v\n", err) } // wait for all goroutines to finish wg.Wait() // close redis connection redisdb.Close() os.Exit(0) } func processRequest(redisdb *redis.Client) { defer wg.Done() // simulate some business logic here time.Sleep(time.Second * 5) redisdb.Incr("counter") } Hier ist die Zusammenfassung der Updates: hinzugefügt, um auf das SIGTERM-Beendigungssignal zu warten. signal.NotifyContext Einführung einer zur Verfolgung laufender Anfragen (processRequest-Goroutinen). sync.WaitGroup Habe den Server in eine Goroutine gepackt und “ mit Kontext verwendet, um die Annahme neuer Verbindungen ordnungsgemäß zu beenden. „server.Shutdown Verwendet wurde um sicherzustellen, dass alle laufenden Anfragen (ProcessRequest-Goroutinen) abgeschlossen werden, bevor fortgefahren wird. wg.Wait(), Ressourcenbereinigung: hinzugefügt, um die Redis-Verbindung vor dem Beenden ordnungsgemäß zu schließen. redisdb.Close() Sauberer Ausgang: Verwendet um eine erfolgreiche Beendigung anzuzeigen. os.Exit(0), Wenn wir nun unseren Verifizierungsprozess wiederholen, werden wir sehen, dass alle 1000 Anfragen korrekt verarbeitet wurden. 🎉 Web-Frameworks/HTTP-Bibliothek Frameworks wie Echo, Gin, Fiber und andere erzeugen für jede eingehende Anfrage eine Goroutine, geben ihr einen Kontext und rufen dann Ihre Funktion/Ihren Handler auf, je nachdem, für welches Routing Sie sich entschieden haben. In unserem Fall wäre das die anonyme Funktion, die HandleFunc für den Pfad „/incr“ gegeben wird. Wenn Sie ein Signal abfangen und Ihr Framework auffordern, ordnungsgemäß herunterzufahren, passieren (vereinfacht ausgedrückt) zwei wichtige Dinge: SIGTERM- Ihr Framework akzeptiert keine eingehenden Anfragen mehr Es wartet, bis alle vorhandenen eingehenden Anfragen abgeschlossen sind (und wartet implizit auf das Ende der Goroutinen). Hinweis: Kubernetes beendet auch die Weiterleitung des eingehenden Datenverkehrs vom Loadbalancer zu Ihrem Pod, sobald es diesen als „Wird beendet“ gekennzeichnet hat. Optional: Shutdown-Timeout Das Beenden eines Prozesses kann komplex sein, insbesondere wenn viele Schritte erforderlich sind, wie z. B. das Schließen von Verbindungen. Um einen reibungslosen Ablauf zu gewährleisten, können Sie ein Timeout festlegen. Dieses Timeout fungiert als Sicherheitsnetz und beendet den Prozess ordnungsgemäß, wenn er länger als erwartet dauert. shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() go func() { if err := server.Shutdown(shutdownCtx); err != nil { log.Fatalf("could not shutdown: %v\n", err) } }() select { case <-shutdownCtx.Done(): if shutdownCtx.Err() == context.DeadlineExceeded { log.Fatalln("timeout exceeded, forcing shutdown") } os.Exit(0) } Kubernetes-Beendigungslebenszyklus Da wir Kubernetes zur Bereitstellung unseres Dienstes verwendet haben, wollen wir uns genauer ansehen, wie Kubernetes die Pods beendet. Sobald Kubernetes beschließt, den Pod zu beenden, finden die folgenden Ereignisse statt: Pod wird auf den Status „Wird beendet“ gesetzt und aus der Endpunktliste aller Dienste entfernt. Hook wird ausgeführt, falls definiert. Der preStop- Signal wird an den Pod gesendet. Aber hey, jetzt weiß unsere Anwendung, was zu tun ist! Das SIGTERM- Kubernetes wartet eine Nachfrist ( ), die standardmäßig 30 Sekunden beträgt. terminationGracePeriodSeconds Signal wird an den Pod gesendet und der Pod wird entfernt. Das SIGKILL- Wie Sie sehen, kann es bei einem Beendigungsprozess mit langer Ausführungsdauer erforderlich sein, die Einstellung zu erhöhen, um Ihrer Anwendung ausreichend Zeit für ein ordnungsgemäßes Herunterfahren zu geben. „terminationGracePeriodSeconds“ Abschluss Ordentliches Herunterfahren schützt die Datenintegrität, sorgt für ein nahtloses Benutzererlebnis und optimiert die Ressourcenverwaltung. Mit seiner umfangreichen Standardbibliothek und dem Schwerpunkt auf Parallelität ermöglicht Go Entwicklern die mühelose Integration von Verfahren für ordnungsgemäßes Herunterfahren – eine Notwendigkeit für Anwendungen, die in containerisierten oder orchestrierten Umgebungen wie Kubernetes bereitgestellt werden. Den Go-Code und die Kubernetes-Manifeste finden Sie in . unserem Github-Repository Ressourcen os/signal-Paket Kubernetes Pod-Lebenszyklus
