Ausführliche Cloud-native Analyse zur Verwendung temporärer Container zur Fehlerbehebung in Kubernetes

1. Hintergrund

• Container und das sie umgebende Ökosystem verändern die Art und Weise, wie Ingenieure Arbeitslasten bereitstellen, warten und Fehler beheben. Das Debuggen von Anwendungen in einem Kubernetes-Cluster kann jedoch manchmal schwierig sein, da die erforderlichen Debugging-Tools möglicherweise nicht im Container gefunden werden. Viele Ingenieure verwenden einen abgespeckten, auf der Distribution basierenden Build ohne Distributions-Basis-Image, der nicht einmal über einen Paketmanager oder eine Shell verfügt, und sogar einige Teams verwenden Scratch als Basis-Image und fügen nur die für die Anwendung erforderlichen Dateien hinzu laufen.
• Einige Gründe für diese gängige Praxis sind:
• • Hat eine kleinere Angriffsfläche.
• • Für eine schnellere Scanleistung.
• • Reduzierte Bildgröße.
• • Für schnellere Builds und kürzere CD/CI-Zyklen.
• • Reduzieren Sie Abhängigkeiten.
• Diese abgespeckten Basis-Images enthalten keine Tools zur Fehlerbehebung der Anwendung oder ihrer Abhängigkeiten, was den größten Nutzen der kurzlebigen Containerfunktion von Kubernetes darstellt. Ephemere Container ermöglichen die Erstellung von Container-Images, die alle Debugging-Tools enthalten, die Sie möglicherweise benötigen. Sobald ein Debugging erforderlich ist, kann der Staging-Container auf dem ausgewählten laufenden Pod bereitgestellt werden.
• Container können nicht zu bereitgestellten Containern hinzugefügt werden, die Spezifikation muss aktualisiert und die Ressourcen neu erstellt werden. Allerdings können temporäre Container zu vorhandenen Pods hinzugefügt werden, um die Fehlerbehebung bei Online-Problemen zu erleichtern.

2. Konfiguration temporärer Container

• Ephemere Container haben dieselben Spezifikationen wie normale Container. Allerdings sind einige Felder deaktiviert und einige Verhaltensweisen wurden geändert.
• Einige der bahnbrechenden Änderungen sind unten aufgeführt. Die vollständige Liste finden Sie in der vorläufigen Containerspezifikation:
• • Sie werden nicht neu gestartet.
• • Das Definieren von Ressourcen ist nicht zulässig.
• • Port nicht erlaubt.
• • Start-, Aktivitäts- und Bereitschaftstests sind nicht zulässig.

3. Starten Sie den temporären Container

• Überprüfen Sie zunächst, ob die Funktion für kurzlebige Container aktiviert ist:

kubectl debug -it <POD_NAME> --image=busybox

• Wenn diese Funktion nicht aktiviert ist, wird eine Meldung ähnlich der folgenden angezeigt:

Defaulting debug container name to debugger-wg54p.
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").

• Hängen Sie EphemeralContainers=true an –feature-gates= in den Parametern kubelet, kube-apiserver, kube-controller-manager, kube-proxy und kube-scheduler an, zum Beispiel:

...
--feature-gates=RemoveSelfLink=false,EphemeralContainers=true
...

4. Verwenden Sie temporäre Container

• Jetzt unterstützt der Cluster die temporäre Containerfunktion. Um einen temporären Container zu erstellen, verwenden Sie den Unterbefehl debug des Befehlszeilentools kubectl. Erstellen Sie zunächst ein Deployment:

kubectl create deployment nginx-deployment --image=nginx

• Rufen Sie den Namen des Pods ab, der debuggt werden muss:

$ kubectl get pods

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-66b6c48dd5-frsv9   1/1     Running   6          62d

• Der folgende Befehl erstellt einen neuen temporären Container im Pod nginx-deployment-66b6c48dd5-frsv9, der von Busybox gespiegelt wird. Mit den Parametern -i und -t können wir eine Verbindung zum neu erstellten Container herstellen:

$ kubectl debug -it pods/nginx-deployment-66b6c48dd5-frsv9 --image=busybox

• Jetzt können Sie debuggen:

/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=112 time=9.797 ms
64 bytes from 8.8.8.8: seq=1 ttl=112 time=9.809 ms
^C
/ # nc --help
BusyBox v1.34.1 (2021-11-11 01:55:05 UTC) multi-call binary.

Usage: nc [OPTIONS] HOST PORT  - connect
nc [OPTIONS] -l -p PORT [HOST] [PORT]  - listen
...

• Wenn Sie den Befehl kubectl discover pod <POD_NAME> verwenden, sehen Sie ein neues Feld „Ephemere Container“. Dieser Abschnitt enthält ephemere Container und ihre Eigenschaften:

$ kubectl describe pods <POD_NAME>

...
...
Ephemeral Containers:
  debugger-thwrn:
    Container ID:   containerd://eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0
    Image:          busybox
    Image ID:       docker.io/library/busybox@sha256:e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353
    Port:           <none>
    Host Port:      <none>

5. Geben Sie den Prozess-Namespace für den temporären Container frei

• Die gemeinsame Nutzung von Prozess-Namespaces war schon immer eine gute Option zur Fehlerbehebung, und diese Funktion ist für kurzlebige Container verfügbar. Die gemeinsame Nutzung von Prozess-Namespaces kann nicht auf vorhandene Container angewendet werden, daher muss eine Kopie des Zielcontainers erstellt werden. –share-processesflag ermöglicht die gemeinsame Nutzung von Prozess-Namespaces, wenn es mit --copy-to verwendet wird. Diese Flags kopieren die vorhandene Pod-Spezifikationsdefinition in die neue Definition und ermöglichen die gemeinsame Nutzung von Prozess-Namespaces in der Spezifikation:

$ kubectl debug -it <POD_NAME> --image=busybox --share-processes --copy-to=debug-pod

• Führen Sie den Befehl ps aus, um die laufenden Prozesse anzuzeigen. Wie erwartet können Sie /pause im Busybox-Container und den Nginx-Prozess im Nginx-Deployment-Container sehen:

# ps aux

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 root      0:00 sh
   17 root      0:00 ps aux

• Über den Prozess-Namespace kann auch auf das gemeinsam genutzte Container-Dateisystem zugegriffen werden, was für das Debuggen nützlich ist, und auf den Container kann über den Link /proc//root zugegriffen werden. Aus der obigen Ausgabe können wir erkennen, dass die PID von Nginx 6 ist.

# ls /proc/6/root/etc/nginx

conf.d koi-utf mime.types nginx.conf uwsgi_params fastcgi_params koi-win modules scgi_params win-utf

• Hier sehen Sie die Nginx-Verzeichnisstruktur und die Konfigurationsdateien im Zielcontainer.

6. Fazit

• Die temporäre Containerfunktion bietet zweifellos großen Komfort beim Debuggen und Beheben von Problemen, während die gemeinsame Nutzung von Prozess-Namespaces erweiterte Debugging-Funktionen ermöglicht.
• Wenn Sie auch Anwendungen verwenden, die in Kubernetes-Clustern laufen, lohnt es sich, sich die Zeit zu nehmen, diese Funktionen auszuprobieren. Es ist nicht schwer, sich vorzustellen, dass einige Teams diese Tools sogar zur Automatisierung von Arbeitsabläufen nutzen, etwa um andere Container automatisch zu reparieren, wenn Bereitschaftsprüfungen fehlschlagen.