Wie man Befehle in Kubernetes-Pods beim Start ausführt

Einführung

Dieses Tutorial führt Sie durch das Ausführen von Befehlen in Kubernetes-Pods beim Start. Sie werden lernen, wie Sie Startbefehle mithilfe der Felder command und args konfigurieren, mehrere Befehle ausführen und Startfehler behandeln. Wir verwenden Minikube, um eine lokale Kubernetes-Umgebung zu erstellen, in der Sie diese Konzepte praktisch anwenden können.

Am Ende dieses Labs werden Sie verstehen, wie Sie das Verhalten Ihrer Kubernetes-Pods beim Start anpassen und eine reibungslose Anwendungsbereitstellung gewährleisten können. Dieses Wissen ist unerlässlich für die richtige Konfiguration von containerisierten Anwendungen in einer Kubernetes-Umgebung.

Einrichten Ihrer Kubernetes-Umgebung

In diesem Schritt bereiten wir unsere Umgebung vor, indem wir Minikube starten und die grundlegenden Kubernetes-Konzepte verstehen, die für dieses Lab erforderlich sind.

Was ist Kubernetes?

Kubernetes ist eine Open-Source-Plattform, die für die Automatisierung der Bereitstellung, Skalierung und des Betriebs von Anwendungscontainern konzipiert ist. Im Zentrum von Kubernetes stehen Pods - die kleinsten bereitstellbaren Einheiten, die erstellt und verwaltet werden können.

Starten von Minikube

Minikube ist ein Tool, das es Ihnen ermöglicht, Kubernetes lokal auszuführen. Starten wir es:

minikube start --driver=docker

Dieser Befehl erstellt einen lokalen Kubernetes-Cluster, der Docker als Treiber verwendet. Der Startvorgang kann einige Minuten dauern, da erforderliche Komponenten heruntergeladen werden.

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

😄  minikube v1.30.1 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Überprüfen der Installation

Lassen Sie uns überprüfen, ob alles korrekt funktioniert, indem wir den Status unseres Minikube-Clusters prüfen:

minikube status

Sie sollten eine Ausgabe sehen, die darauf hinweist, dass Minikube läuft:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Jetzt überprüfen wir, ob kubectl (das Kubernetes-Befehlszeilentool) richtig konfiguriert ist:

kubectl get nodes

Sie sollten einen Knoten (Ihre Minikube-Instanz) als "Ready" aufgelistet sehen:

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m15s   v1.27.4

Verständnis von Kubernetes-Pods

Ein Pod ist die grundlegende Ausführungseinheit einer Kubernetes-Anwendung. Jeder Pod repräsentiert einen laufenden Prozess in Ihrem Cluster und kapselt einen oder mehrere Container. Pods sind von ihrer Konzeption her vorübergehend, was bedeutet, dass sie bei Bedarf erstellt, zerstört und neu erstellt werden können.

In Kubernetes definieren Sie Pods normalerweise in YAML-Dateien. Für dieses Lab haben wir bereits einige Beispiel-YAML-Dateien in Ihrer Umgebung vorbereitet.

Gehen wir in das Verzeichnis, in dem sich diese Dateien befinden:

cd ~/project/kubernetes-examples
ls -la

Sie sollten die folgenden Dateien sehen:

total 20
drwxr-xr-x 2 labex labex 4096 Sep 21 10:00 .
drwxr-xr-x 3 labex labex 4096 Sep 21 10:00 ..
-rw-r--r-- 1 labex labex  193 Sep 21 10:00 basic-pod.yaml
-rw-r--r-- 1 labex labex  254 Sep 21 10:00 liveness-probe-pod.yaml
-rw-r--r-- 1 labex labex  312 Sep 21 10:00 multi-command-pod.yaml
-rw-r--r-- 1 labex labex  263 Sep 21 10:00 startup-command-pod.yaml

Nachdem unsere Umgebung eingerichtet ist, sind wir bereit, mit Kubernetes-Pods zu arbeiten und zu lernen, wie man Befehle beim Start ausführt.

Erstellen Ihres ersten Pods mit grundlegenden Startbefehlen

In diesem Schritt werden wir unseren ersten Kubernetes-Pod erstellen und verstehen, wie er Befehle beim Start ausführt. Wir werden das command-Feld untersuchen, das definiert, was der Container beim Start ausführen soll.

Untersuchung der grundlegenden Pod-Konfiguration

Lassen Sie uns zunächst die Konfiguration eines grundlegenden Pods untersuchen. Öffnen Sie die Datei basic-pod.yaml mit dem nano-Editor:

nano basic-pod.yaml

Sie werden eine YAML-Datei mit folgendem Inhalt sehen:

apiVersion: v1
kind: Pod
metadata:
  name: basic-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c", "echo 'Pod is running' && sleep 3600"]

Diese Konfiguration definiert:

Einen Pod namens basic-pod
Einen einzelnen Container namens ubuntu, der das ubuntu:20.04-Image verwendet
Einen Startbefehl, der eine Nachricht ausgibt und dann 3600 Sekunden (1 Stunde) schläft

Das command-Feld gibt das ausführbare Programm an, das beim Start des Containers ausgeführt wird. In diesem Fall führen wir die /bin/bash-Shell mit der -c-Option aus, die es uns ermöglicht, eine Zeichenfolge von Befehlen zur Ausführung zu übergeben.

Drücken Sie Ctrl+X, um den nano-Editor zu verlassen.

Erstellen des Pods

Lassen Sie uns diesen Pod in unserem Kubernetes-Cluster erstellen:

kubectl apply -f basic-pod.yaml

Sie sollten eine Ausgabe wie die folgende sehen:

pod/basic-pod created

Überprüfen des Pod-Status

Jetzt überprüfen wir, ob unser Pod ordnungsgemäß läuft:

kubectl get pods

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

NAME        READY   STATUS    RESTARTS   AGE
basic-pod   1/1     Running   0          30s

Dies zeigt an, dass unser Pod erfolgreich läuft. Die Angabe 1/1 unter READY bedeutet, dass ein Container von einem erwarteten Container läuft.

Anzeigen der Pod-Logs

Um die Ausgabe unseres Startbefehls zu sehen, können wir die Logs des Pods überprüfen:

kubectl logs basic-pod

Sie sollten sehen:

Pod is running

Dies bestätigt, dass unser Startbefehl erfolgreich ausgeführt wurde.

Untersuchung des laufenden Containers

Lassen Sie uns untersuchen, was in unserem Container passiert, indem wir eine interaktive Shell ausführen:

kubectl exec -it basic-pod -- /bin/bash

Jetzt befinden Sie sich in der Shell des Containers. Lassen Sie uns überprüfen, ob unser Prozess läuft:

ps aux

Sie sollten sehen, dass der sleep-Befehl läuft, der Teil unseres Startbefehls ist:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4112  3372 ?        Ss   10:05   0:00 /bin/bash -c echo 'Pod is running' && sleep 3600
root         7  0.0  0.0   4112  3536 pts/0    Ss   10:06   0:00 /bin/bash
root        14  0.0  0.0   5900  2928 pts/0    R+   10:06   0:00 ps aux
root        15  0.0  0.0   2512   580 ?        S    10:06   0:00 sleep 3600

Der Prozess mit der PID 1 ist unser Startbefehl, und der sleep 3600-Befehl wird als separater Prozess ausgeführt.

Verlassen Sie die Container-Shell, indem Sie eingeben:

exit

Verständnis des Pod-Lebenszyklus

Wenn Sie einen Pod erstellen, durchläuft er mehrere Phasen:

Pending: Der Pod wurde von Kubernetes akzeptiert, läuft aber noch nicht.
Running: Der Pod läuft mit allen Containern.
Succeeded: Alle Container im Pod haben erfolgreich beendet.
Failed: Alle Container haben beendet, und mindestens ein Container ist fehlgeschlagen.
Unknown: Der Zustand des Pods kann nicht ermittelt werden.

Unser Pod befindet sich im Zustand "Running", da unser Hauptprozess (sleep 3600) noch läuft. Wenn dieser Prozess abgeschlossen oder beendet wird, wechselt der Pod in den Zustand "Succeeded" oder "Failed", je nach Exit-Code.

Jetzt verstehen Sie, wie Sie einen grundlegenden Pod erstellen und Befehle beim Start mithilfe des command-Felds ausführen können.

Verwenden von Command und Args für die Startkonfiguration

In diesem Schritt lernen wir, wie wir die Felder command und args zusammen verwenden können, um komplexere Startverhaltensweisen in Kubernetes-Pods zu konfigurieren.

Verständnis von Command und Args

Kubernetes bietet zwei Hauptmöglichkeiten, um den Befehl anzugeben, der beim Start eines Containers ausgeführt wird:

command: Gibt das auszuführende Programm an (ähnlich wie Docker's ENTRYPOINT)
args: Gibt die Argumente an, die an den Befehl übergeben werden (ähnlich wie Docker's CMD)

Das separate oder gemeinsame Verwenden dieser Felder bietet Ihnen Flexibilität bei der Konfiguration des Containerstarts.

Untersuchung des Startup-Command-Pods

Lassen Sie uns die Datei startup-command-pod.yaml untersuchen:

nano startup-command-pod.yaml

Sie werden die folgende Konfiguration sehen:

apiVersion: v1
kind: Pod
metadata:
  name: startup-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash"]
      args:
        ["-c", "echo 'Custom startup message' > /tmp/startup.txt && sleep 3600"]

In dieser Konfiguration:

Das command-Feld gibt an, dass wir /bin/bash ausführen möchten.
Das args-Feld liefert die Argumente, die an bash übergeben werden sollen: -c und die Zeichenfolge mit unseren Befehlen.

Diese Trennung von Befehl und Argumenten macht die Konfiguration lesbarer und wartbarer.

Drücken Sie Ctrl+X, um den nano-Editor zu verlassen.

Erstellen des Startup-Command-Pods

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f startup-command-pod.yaml

Sie sollten sehen:

pod/startup-command-pod created

Überprüfen des Pod-Status

Überprüfen Sie, ob der Pod läuft:

kubectl get pods startup-command-pod

Sie sollten sehen:

NAME                  READY   STATUS    RESTARTS   AGE
startup-command-pod   1/1     Running   0          30s

Überprüfen des Startbefehls

Jetzt überprüfen wir, ob unser Startbefehl korrekt ausgeführt wurde, indem wir prüfen, ob die erwartete Datei erstellt wurde:

kubectl exec startup-command-pod -- cat /tmp/startup.txt

Sie sollten sehen:

Custom startup message

Dies bestätigt, dass unser Befehl erfolgreich ausgeführt wurde und die Datei mit dem angegebenen Inhalt erstellt wurde.

Verständnis des Unterschieds zwischen Command und Args

Das Verhältnis zwischen command und args ist wichtig zu verstehen:

Wenn Sie nur command angeben, überschreiben Sie das Standard-ENTRYPOINT des Container-Images.
Wenn Sie nur args angeben, überschreiben Sie das Standard-CMD des Container-Images.
Wenn Sie sowohl command als auch args angeben, überschreiben Sie sowohl das ENTRYPOINT als auch das CMD.

Lassen Sie uns sehen, was passiert, wenn wir unsere Pod-Konfiguration ändern. Erstellen Sie eine neue Datei namens modified-command-pod.yaml:

nano modified-command-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: v1
kind: Pod
metadata:
  name: modified-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/echo"]
      args: ["This message is printed by echo"]

Speichern Sie die Datei und verlassen Sie den Editor mit Ctrl+X, gefolgt von Y und Enter.

Jetzt erstellen wir diesen Pod:

kubectl apply -f modified-command-pod.yaml

Sie sollten sehen:

pod/modified-command-pod created

Überprüfen Sie die Logs, um zu sehen, was passiert ist:

kubectl logs modified-command-pod

Sie sollten sehen:

This message is printed by echo

Beachten Sie, wie der Pod den /bin/echo-Befehl mit unserem angegebenen Argument ausführte und dann beendete, da echo nach dem Ausdrucken seiner Ausgabe beendet wird.

Überprüfen Sie den Pod-Status:

kubectl get pods modified-command-pod

Sie sollten etwas wie Folgendes sehen:

NAME                   READY   STATUS      RESTARTS   AGE
modified-command-pod   0/1     Completed   0          45s

Der Status Completed zeigt an, dass der Pod bis zum Abschluss ausgeführt wurde und erfolgreich beendet wurde.

Jetzt verstehen Sie, wie Sie command und args zusammen verwenden können, um das Startverhalten in Kubernetes-Pods zu konfigurieren.

Ausführen mehrerer Befehle und Umgang mit Startfehlern

In diesem Schritt lernen wir, wie wir mehrere Befehle beim Start eines Pods ausführen können und wie wir Startfehler mithilfe von Gesundheitsüberprüfungen (Health Checks) behandeln können.

Ausführen mehrerer Befehle

Oft müssen Sie mehrere Befehle ausführen, wenn ein Container startet. Es gibt mehrere Möglichkeiten, dies in Kubernetes zu tun:

Verkettung von Befehlen mit Shell-Operatoren (&&, ; usw.)
Verwendung einer Skriptdatei
Verwendung eines Init-Containers

Lassen Sie uns die erste Methode untersuchen, indem wir die Datei multi-command-pod.yaml betrachten:

nano multi-command-pod.yaml

Sie werden Folgendes sehen:

apiVersion: v1
kind: Pod
metadata:
  name: multi-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        [
          "echo 'First command' > /tmp/first.txt && echo 'Second command' > /tmp/second.txt && sleep 3600"
        ]

Diese Konfiguration verknüpft mehrere Befehle mithilfe des &&-Operators, der jeden Befehl nur ausführt, wenn der vorherige erfolgreich war.

Drücken Sie Ctrl+X, um den Editor zu verlassen.

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f multi-command-pod.yaml

Sie sollten sehen:

pod/multi-command-pod created

Jetzt überprüfen wir, ob beide Befehle ausgeführt wurden, indem wir die erstellten Dateien prüfen:

kubectl exec multi-command-pod -- cat /tmp/first.txt

Sie sollten sehen:

First command

Und für die zweite Datei:

kubectl exec multi-command-pod -- cat /tmp/second.txt

Sie sollten sehen:

Second command

Umgang mit Startfehlern mithilfe von Gesundheitsüberprüfungen

Kubernetes bietet Mechanismen, um Startfehler zu erkennen und zu behandeln:

Liveness Probes: Überprüfen, ob der Container läuft; wenn nicht, wird Kubernetes ihn neu starten.
Readiness Probes: Überprüfen, ob der Container bereit ist, Datenverkehr zu empfangen.
Startup Probes: Überprüfen, ob die Anwendung gestartet wurde; nützlich für langsam startende Container.

Lassen Sie uns einen Pod untersuchen, der einen Liveness Probe verwendet:

nano liveness-probe-pod.yaml

Sie werden Folgendes sehen:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args: ["touch /tmp/healthy && sleep 3600"]
      livenessProbe:
        exec:
          command: ["cat", "/tmp/healthy"]
        initialDelaySeconds: 5
        periodSeconds: 5

In dieser Konfiguration:

Der Container erstellt beim Start eine Datei /tmp/healthy.
Der Liveness Probe überprüft alle 5 Sekunden, ob diese Datei vorhanden ist.
Wenn die Datei fehlt, hält Kubernetes den Container für fehlerhaft und startet ihn neu.

Drücken Sie Ctrl+X, um den Editor zu verlassen.

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f liveness-probe-pod.yaml

Sie sollten sehen:

pod/liveness-probe-pod created

Überprüfen Sie, ob der Pod läuft:

kubectl get pods liveness-probe-pod

Sie sollten sehen:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   0          30s

Jetzt sehen wir, was passiert, wenn wir die Gesundheitsüberprüfungsdatei entfernen:

kubectl exec liveness-probe-pod -- rm /tmp/healthy

Warten Sie etwa 10 Sekunden und überprüfen Sie dann erneut den Pod-Status:

kubectl get pods liveness-probe-pod

Sie sollten sehen, dass der Container neu gestartet wurde:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   1          60s

Die Anzahl der Neustarts (RESTARTS) hat sich auf 1 erhöht, was darauf hinweist, dass Kubernetes den fehlerhaften Zustand erkannt und den Container neu gestartet hat.

Lassen Sie uns überprüfen, ob die Gesundheitsüberprüfungsdatei wieder vorhanden ist (sie sollte beim Neustart des Containers durch den Startbefehl neu erstellt worden sein):

kubectl exec liveness-probe-pod -- ls -la /tmp/healthy

Sie sollten sehen, dass die Datei wieder vorhanden ist:

-rw-r--r-- 1 root root 0 Sep 21 10:30 /tmp/healthy

Dies zeigt, wie Kubernetes automatisch von Startfehlern recoverieren und den gewünschten Zustand Ihrer Anwendungen aufrechterhalten kann.

Erstellen eines benutzerdefinierten Startskripts

Für komplexere Initialisierungen möchten Sie möglicherweise ein benutzerdefiniertes Startskript verwenden. Lassen Sie uns einen Pod erstellen, der ein Shellskript zum Starten verwendet:

nano script-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: v1
kind: Pod
metadata:
  name: script-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          cat > /tmp/startup.sh << 'EOF'
          #!/bin/bash
          echo "Script started at $(date)" > /tmp/script-log.txt
          echo "Creating configuration files..." >> /tmp/script-log.txt
          mkdir -p /tmp/config
          echo "app_name=MyApp" > /tmp/config/app.conf
          echo "version=1.0" >> /tmp/config/app.conf
          echo "Script completed successfully" >> /tmp/script-log.txt
          EOF
          chmod +x /tmp/startup.sh
          /tmp/startup.sh
          sleep 3600

Diese Konfiguration:

Erstellt ein Startskript im Container.
Macht es ausführbar.
Führt das Skript aus.
Lässt den Container mit sleep laufen.

Speichern Sie die Datei und verlassen Sie den Editor mit Ctrl+X, gefolgt von Y und Enter.

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f script-pod.yaml

Sie sollten sehen:

pod/script-pod created

Warten Sie einen Moment, bis der Pod gestartet ist, und überprüfen Sie dann seinen Status:

kubectl get pods script-pod

Sie sollten sehen:

NAME         READY   STATUS    RESTARTS   AGE
script-pod   1/1     Running   0          30s

Jetzt überprüfen wir die Ausgabe unseres Skripts:

kubectl exec script-pod -- cat /tmp/script-log.txt

Sie sollten etwas wie Folgendes sehen:

Script started at Tue Sep 21 10:35:42 UTC 2023
Creating configuration files...
Script completed successfully

Und lassen Sie uns überprüfen, ob die Konfigurationsdatei erstellt wurde:

kubectl exec script-pod -- cat /tmp/config/app.conf

Sie sollten sehen:

app_name=MyApp
version=1.0

Dies zeigt, wie Sie komplexe Startskripts verwenden können, um Ihre Container in Kubernetes zu initialisieren.

Best Practices und reale Anwendungen

In diesem letzten Schritt werden wir die Best Practices für das Ausführen von Befehlen in Kubernetes-Pods beim Start untersuchen und ein reales Anwendungsbeispiel erstellen, das diese Praktiken implementiert.

Best Practices für Startbefehle

Beachten Sie bei der Konfiguration von Startbefehlen für Kubernetes-Pods die folgenden Best Practices:

Machen Sie Startbefehle idempotent: Befehle sollten mehrmals ausgeführt werden können, ohne Probleme zu verursachen.
Verwenden Sie Gesundheitsüberprüfungen: Implementieren Sie Liveness- und Readiness-Probes, um einen erfolgreichen Start zu überprüfen.
Behandeln Sie Fehler gracefully: Fügen Sie Fehlerbehandlung in Ihre Startskripte ein.
Trennen Sie Aufgaben: Verwenden Sie Init-Container für Initialisierungsaufgaben, die von Ihrer Hauptanwendung getrennt sind.
Begrenzen Sie die Startzeit: Halten Sie die Initialisierung kurz, um die Bereitstellungszeit zu verkürzen.
Verwenden Sie Umgebungsvariablen: Machen Sie Ihre Startbefehle über Umgebungsvariablen konfigurierbar.
Protokollieren Sie den Startfortschritt: Geben Sie klare Logs für die Fehlersuche aus.

Verwenden von Init-Containern für Startaufgaben

Init-Container werden vor den App-Containern gestartet und sind ideal für Setup-Aufgaben. Lassen Sie uns einen Pod mit einem Init-Container erstellen:

nano init-container-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: v1
kind: Pod
metadata:
  name: init-container-pod
spec:
  initContainers:
    - name: init-config
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Initializing configuration..."
          mkdir -p /work-dir/config
          echo "database_url=mysql://user:password@db:3306/mydb" > /work-dir/config/db.conf
          echo "api_key=1234567890" > /work-dir/config/api.conf
          echo "Initialization complete"
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  containers:
    - name: app
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Application starting..."
          echo "Reading configuration:"
          cat /work-dir/config/db.conf
          cat /work-dir/config/api.conf
          echo "Application running..."
          sleep 3600
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  volumes:
    - name: shared-volume
      emptyDir: {}

In dieser Konfiguration:

Der Init-Container init-config wird zuerst ausgeführt und erstellt Konfigurationsdateien.
Beide Container teilen sich ein Volume namens shared-volume.
Der Haupt-App-Container liest die vom Init-Container erstellte Konfiguration.

Speichern Sie die Datei und verlassen Sie den Editor mit Ctrl+X, gefolgt von Y und Enter.

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f init-container-pod.yaml

Sie sollten sehen:

pod/init-container-pod created

Überprüfen Sie den Pod-Status:

kubectl get pods init-container-pod

Sie sollten sehen, dass der Pod läuft:

NAME                 READY   STATUS    RESTARTS   AGE
init-container-pod   1/1     Running   0          30s

Jetzt überprüfen wir die Logs des Hauptcontainers:

kubectl logs init-container-pod -c app

Sie sollten etwas wie Folgendes sehen:

Application starting...
Reading configuration:
database_url=mysql://user:password@db:3306/mydb
api_key=1234567890
Application running...

Dies bestätigt, dass der Init-Container die Konfigurationsdateien erfolgreich erstellt hat und der Hauptcontainer diese lesen konnte.

Reales Beispiel: Web-Anwendung mit Datenbanküberprüfung

Lassen Sie uns ein realistischeres Beispiel erstellen - eine Web-Anwendung, die vor dem Start die Verfügbarkeit der Datenbank überprüft:

nano webapp-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.28
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "Checking for database availability..."
          ## In a real scenario, this would check an actual database
          ## For this example, we'll simulate success after a short delay
          sleep 5
          echo "Database is available"
          touch /tmp/db-ready
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
  containers:
    - name: webapp
      image: nginx:1.19
      ports:
        - containerPort: 80
      command: ["/bin/sh", "-c"]
      args:
        - |
          if [ -f /tmp/db-ready ]; then
            echo "Database connection verified, starting web application..."
            ## Customize nginx configuration
            echo "<h1>Web Application Started Successfully</h1>" > /usr/share/nginx/html/index.html
            echo "<p>Connected to database</p>" >> /usr/share/nginx/html/index.html
            ## Start nginx
            nginx -g 'daemon off;'
          else
            echo "Error: Database not available"
            exit 1
          fi
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
  volumes:
    - name: shared-volume
      emptyDir: {}

Diese Konfiguration:

Verwenden Sie einen Init-Container, um die Verfügbarkeit der Datenbank zu überprüfen (simuliert).
Der Hauptcontainer überprüft vor dem Start, ob eine vom Init-Container erstellte Datei vorhanden ist.
Enthält eine Readiness-Probe, um zu überprüfen, ob die Anwendung Datenverkehr bedient.
Verwenden Sie ein gemeinsames Volume für die Kommunikation zwischen den Containern.

Speichern Sie die Datei und verlassen Sie den Editor mit Ctrl+X, gefolgt von Y und Enter.

Lassen Sie uns diesen Pod erstellen:

kubectl apply -f webapp-pod.yaml

Sie sollten sehen:

pod/webapp-pod created

Warten Sie einen Moment, bis der Pod vollständig gestartet ist, und überprüfen Sie dann seinen Status:

kubectl get pods webapp-pod

Sie sollten sehen:

NAME         READY   STATUS    RESTARTS   AGE
webapp-pod   1/1     Running   0          30s

Die 1/1 in der READY-Spalte zeigt an, dass die Readiness-Probe erfolgreich war.

Lassen Sie uns Port-Forwarding einrichten, um auf die Web-Anwendung zuzugreifen:

kubectl port-forward webapp-pod 8080:80 &

Dieser Befehl wird im Hintergrund ausgeführt (wegen des &). Jetzt können wir auf die Web-Anwendung mit curl zugreifen:

curl http://localhost:8080

Sie sollten sehen:

<h1>Web Application Started Successfully</h1>
<p>Connected to database</p>

Dies bestätigt, dass unsere Anwendung korrekt initialisiert wurde, die Datenbankverfügbarkeit überprüft hat und jetzt Datenverkehr bedient.

Stoppen Sie den Port-Forwarding-Prozess:

pkill -f "kubectl port-forward"

Aufräumen

Bevor wir das Lab beenden, lassen Sie uns die von uns erstellten Ressourcen aufräumen:

kubectl delete pod basic-pod startup-command-pod modified-command-pod multi-command-pod liveness-probe-pod script-pod init-container-pod webapp-pod

Sie sollten sehen:

pod "basic-pod" deleted
pod "startup-command-pod" deleted
pod "modified-command-pod" deleted
pod "multi-command-pod" deleted
pod "liveness-probe-pod" deleted
pod "script-pod" deleted
pod "init-container-pod" deleted
pod "webapp-pod" deleted

Sie haben jetzt gelernt, wie Sie Befehle in Kubernetes-Pods beim Start ausführen, mehrere Befehle ausführen, Fehler behandeln und Best Practices in realen Szenarien anwenden können.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie Sie Befehle in Kubernetes-Pods beim Start ausführen. Sie haben praktische Erfahrung gesammelt in:

Einrichten einer Kubernetes-Umgebung mit Minikube
Erstellen und Verwalten von Pods mit bestimmten Startbefehlen
Verwenden der Felder command und args zur Konfiguration des Verhaltens von Containern
Ausführen mehrerer Befehle mit Shell-Operatoren und Skripten
Behandeln von Startfehlern mit Gesundheitsüberprüfungen (Health Checks)
Umsetzen von Best Practices mit Init-Containern
Bauen von realen Anwendungen, die eine ordnungsgemäße Initialisierung erfordern

Diese Fähigkeiten sind für die Bereitstellung von containerisierten Anwendungen in Kubernetes-Umgebungen unerlässlich. Durch die richtige Konfiguration von Startbefehlen können Sie sicherstellen, dass Ihre Anwendungen korrekt initialisiert werden, Abhängigkeiten überprüfen und Fehler gracefully behandeln.

Wenn Sie Ihre Kubernetes-Reise fortsetzen, denken Sie daran, dass die ordnungsgemäße Initialisierung von Anwendungen ein kritischer Bestandteil beim Bau von zuverlässigen, skalierbaren und wartbaren Systemen ist.