Der Blog

Debuggen von Kubernetes mit automatisierten Runbooks und temporären Containern

von Jake Cohen 2. Mai 2023 | 5 Minuten Lesezeit

In unserer vorheriger Blog haben wir die Schwierigkeit besprochen, während eines Vorfalls alle relevanten Diagnosen zu erfassen, bevor eine „Pflasterlösung“ angewendet wird. Das häufigste, konkrete Beispiel hierfür ist eine Anwendung, die in einem Container ausgeführt wird und der Container erneut bereitgestellt wird – möglicherweise auf eine frühere oder dieselbe Version –, nur um das unmittelbare Problem zu lösen. Für Unternehmen, bei denen jede Millisekunde Leistung und jede Sekunde Betriebszeit erhebliche Auswirkungen auf das Kundenerlebnis hat, sind diese Arten von kurzfristigen Lösungen eine Notwendigkeit. Die Kosten für das Unternehmen werden jedoch erheblich, wenn Ingenieure mit der Entwicklung der langfristig Lösung für diese Vorfälle. Sowohl bei größeren als auch bei (wiederkehrenden) kleineren Vorfällen müssen die Ingenieure übermäßig viel Zeit damit verbringen, Beweise für den Zustand der Anwendung und der Umgebung zum Zeitpunkt des Vorfalls zu sammeln.

Während ein Großteil dieser Diagnosedaten in Überwachungstools gespeichert ist und daher bestehen bleibt, ist es manchmal erforderlich, eine Shell in einem Container zu verwenden, um Informationen abzurufen, die nur für die Lebensdauer des Containers verfügbar sind. In Kubernetes geschieht dies mithilfe des kubectl exec Befehl. Mit den richtigen Parametern können Benutzer eine Live-Shell in ihrem laufenden Container erhalten und mit der Ausführung von Befehlen beginnen, um Diagnosen abzurufen. Sobald ein Benutzer beispielsweise eine Shell in einem Java-Container hat, kann er Folgendes aufrufen: jstack um einen Thread-Dump ihrer Anwendung zu erhalten.

Doch viele Einsatzteams lassen nicht irgendjemand Ausführung in Produktions-Pods (wo kritische Vorfälle passieren) oder die Anzahl der Personen, die dazu in der Lage sind, ist sehr gering – sowohl aus Sicherheitsgründen als auch aufgrund der begrenzten Anzahl von Personen, die mit dem Betrieb in Kubernetes vertraut sind. Um während eines Vorfalls Diagnosedaten abzurufen, müssen daher regelmäßig Personen mit Kubernetes-Zugriff und -Expertise zu Hilfe gezogen werden. Dieser Prozess treibt die Kosten von Vorfällen in die Höhe, indem er die MTTR erhöht, sowie die Anzahl der Personen, die beteiligt werden müssen.

Aus diesen Gründen ist es am besten, Automatisierung zu verwenden, die es den Benutzern überflüssig macht, Ausführung in laufende Pods. Bei dieser Automatisierungsarchitektur wird bei Auftreten eines Problems ein automatisiertes Runbook aufgerufen, das die Debugdaten abruft, an einen dauerhaften Speicherort (S3, Blob Storage, SFTP-Server usw.) sendet und dann die Ingenieure informiert, wo sie die Debugdaten finden und verwenden können.

PagerDuty Process Automation bietet genau für diesen Anwendungsfall ein vorgefertigtes Runbook auf Vorlagenbasis: Wenn eine Warnung einen Vorfall innerhalb von PagerDuty erstellt, kann dies automatisch (oder per Mausklick) das Runbook dazu veranlassen, Befehle im Pod auszuführen, die Ausgabe an einen dauerhaften Speicherort zu senden und Einzelheiten zum Speicherort dieser Daten im Vorfall bereitzustellen.

Den Technikern wird während und nach dem Vorfall ein Link zu den Debugdaten zur Verfügung gestellt

Benutzer unserer kommerziellen Automatisierungsprodukte ( Prozessautomatisierung und Runbook-Automatisierung ) und Open Source Rundeck kann den Anweisungen folgen Hier um das automatisierte Runbook herunterzuladen und damit zu beginnen.

Dieses automatisierte Runbook ist ideal, wenn das Container-Image bereits über die zum Debuggen erforderlichen Befehlszeilenprogramme (Binärdateien) verfügt. Beispielsweise werden viele containerisierte Java-Apps mit dem jstack Dienstprogramm im Container-Image; was passiert jedoch, wenn die Debugging-Dienstprogramme nicht als Teil des Container-Images ausgeliefert werden? Oder, was immer häufiger vorkommt, was passiert, wenn der Container „distrolos“ ist und daher nicht einmal eine Shell bereitstellt?

Das ist wo Vergängliche Kubernetes-Container ins Spiel – es bietet Benutzern einen Mechanismus zum Anhängen eines Containers (mit einem beliebigen Image) an einen laufenden Pod, ohne dass die Pod-Definition geändert oder der Pod erneut bereitgestellt werden muss.

Durch die gemeinsame Nutzung des Prozess-Namespace kann der temporäre Container seine Debugging-Dienstprogramme für einen anderen Container im Pod verwenden – selbst wenn der ursprüngliche Container abgestürzt ist. Hier ist ein Blog von Ivan Velichko, das sehr detailliert auf die gemeinsame Nutzung von Prozess-Namespaces mit kurzlebigen Containern eingeht:

Quelle: https://iximiuz.com/en/posts/kubernetes-ephemeral-containers/

Ähnlich wie bei der Verwendung kubectl exec , die ordnungsgemäße Nutzung flüchtiger Container erfordert weiterhin Zugriff auf die Ausführung kubectl Befehle im Kubernetes-Cluster – der für diese externen Operationen selten verfügbar ist. Und wie zuvor erfordert das Wissen, wie man den Befehl richtig erstellt, ein hohes Maß an Vertrautheit mit Kubernetes:

kubectl debug -it -n ${namespace} -c debugger --image=busybox --share-processes ${pod_name}
(Beispielbefehl zur Verwendung von Kubernetes Ephemeral Containers)

Um Benutzern entgegenzukommen, die Container ohne Debugging-Dienstprogramme oder Container ohne Distribution haben, haben wir eine neues Kubernetes-Plugin das die Funktionalität flüchtiger Container nutzt:

Wir haben dieses Plugin in einer Vorlage für ein automatisiertes Runbook verwendet, das auch Diagnoseausgaben erfasst und an einen dauerhaften Speicherort sendet. Benutzer von Process Automation und Runbook Automation können mit diesem Vorlagenjob beginnen, indem sie ihn als Teil des Automated Diagnostics Project herunterladen. Hier .

Wenn Sie noch kein Process Automation- oder Runbook Automation-Konto haben, klicken Sie auf Hier um mit den Automatisierungsprodukten von PagerDuty zu beginnen.