Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Timeouts für Exec-Probes konfigurieren, bevor Sie ein Upgrade auf GKE-Version 1.35 durchführen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Ihre Aktivitäts-, Bereitschafts- und Startprüfungen vorbereiten, bevor Sie ein Upgrade Ihrer Google Kubernetes Engine-Cluster (GKE) auf Version 1.35 und höher durchführen. Dazu legen Sie Zeitlimits für Befehle in diesen Prüfungen fest.

Zeitlimits für Exec-Probes

Ab GKE-Version 1.35 erzwingt Kubernetes Zeitlimits für Befehle im Feld exec von Aktivitäts-, Bereitschafts- und Startprüfungen. Das Feld timeoutSeconds in der Spezifikation einer Probe definiert, wie lange Kubernetes wartet, bis eine Probe alle Aktionen abgeschlossen hat. Wenn Sie dieses Feld weglassen, ist der Standardwert 1. Das bedeutet, dass alle Aktionen innerhalb einer Sekunde abgeschlossen sein müssen.

In GKE-Versionen vor 1.35 ignoriert Kubernetes den Wert im Feld timeoutSeconds für Befehle von Exec-Probes. Nehmen wir beispielsweise eine Aktivitätsprüfung mit den folgenden Eigenschaften:

Ein Wert von 5 im Feld timeoutSeconds.
Ein Befehl im Feld exec.command, dessen Ausführung 10 Sekunden dauert.

In Versionen vor 1.35 ignoriert Kubernetes dieses Zeitlimit von fünf Sekunden und meldet die Probe fälschlicherweise als erfolgreich. In Version 1.35 und höher meldet Kubernetes die Probe nach fünf Sekunden korrekt als fehlgeschlagen.

Dieses Verhalten, bei dem Kubernetes Zeitlimits für Exec-Probes ignoriert, kann dazu führen, dass Probes unbegrenzt ausgeführt werden. Dadurch werden möglicherweise Probleme mit Ihren Anwendungen verborgen oder es kann zu unvorhersehbarem Verhalten kommen. In GKE-Version 1.35 und höher erzwingt Kubernetes Zeitlimits für Befehle korrekt. Das führt zu einem konsistenten, vorhersehbaren Verhalten von Probes, das mit Open-Source-Kubernetes übereinstimmt.

Auswirkungen der Erzwingung von Zeitlimits für Exec-Probes

Dies ist eine wichtige Änderung in GKE-Version 1.35 und höher, die für die Stabilität und Zuverlässigkeit von Arbeitslasten erforderlich ist, die in GKE ausgeführt werden. Wenn Sie Ihre Cluster auf Version 1.35 und höher aktualisieren, kann es zu unerwartetem Verhalten von Arbeitslasten kommen, wenn diese Exec-Probes mit einer der folgenden Eigenschaften haben:

Das Feld timeoutSeconds wird weggelassen: In Version 1.35 und höher haben diese Probes eine Sekunde Zeit, um Befehle erfolgreich auszuführen. Wenn der Befehl nicht innerhalb einer Sekunde erfolgreich abgeschlossen wird, melden die Probes Fehler korrekt.
Kurze Zeitlimits angeben: In Version 1.35 und höher melden Probes mit einem kürzeren Zeitlimit als die Befehlsabschlusszeit Fehler korrekt.

In GKE-Version 1.34 und früher meldet Kubernetes einen Fehler in Exec-Probes, die eine dieser Bedingungen erfüllen. Die Befehle in diesen Exec-Probes können jedoch weiterhin bis zum Abschluss ausgeführt werden, da der Fehler der Probe kein Fehler der Probe ist.

Wenn Sie keine genauere Zeitlimitdauer angeben und die Befehle länger als das vorhandene Zeitlimit dauern, melden Ihre Probes in Version 1.35 und höher Fehler. Je nach Art der Probe gilt das folgende Verhalten, wenn eine Probe fehlschlägt:

Liveness-Prüfungen: Wenn eine Liveness-Prüfung fehlschlägt, weil ein Befehl das Zeitlimit überschritten hat, geht Kubernetes davon aus, dass die Anwendung fehlgeschlagen ist, und startet den Container neu. In Versionen vor 1.35 kann ein Zeitlimit nur ein Warnereignis generieren, ohne einen Neustart des Containers zu erzwingen. Wenn die Probe wiederholt fehlschlägt, bleiben Ihre Pods möglicherweise in einer Absturzschleife mit dem Pod-Status CrashLoopBackOff hängen.
Bereitschaftsprüfungen: Wenn eine Bereitschaftsprüfung fehlschlägt, weil ein Befehl das Zeitlimit überschritten hat, aktualisiert Kubernetes die Ready Pod-Bedingung mit dem Status False. Das bedeutet, dass Kubernetes erst dann Traffic an den Pod sendet, wenn die Probe erfolgreich ist. In GKE-Version 1.35 und höher wird der Pod aus den Service-Endpunkten entfernt. In Versionen vor 1.35 kann ein Zeitlimit nur ein Warnereignis generieren, ohne den Pod aus dem Dienst zu entfernen. Wenn alle Pods, die einen Service unterstützen, den Status False für die Bedingung Ready haben, kann es zu Unterbrechungen des Dienstes kommen.
Startprüfungen: Wenn eine Startprüfung fehlschlägt, geht Kubernetes davon aus, dass die Anwendung nicht gestartet wurde, und startet den Container neu. Wenn die Probe wiederholt fehlschlägt, bleiben Ihre Pods möglicherweise in einer Absturzschleife mit dem Pod-Status CrashLoopBackOff hängen.

Pausierte automatische Upgrades

GKE pausiert automatische Upgrades auf Version 1.35, wenn erkannt wird, dass die Arbeitslasten in einem Cluster von dieser Änderung betroffen sein könnten. GKE setzt automatische Upgrades fort, wenn Version 1.35 ein automatisches Upgradeziel für Ihre Steuerungsebene und Knoten ist und eine der folgenden Bedingungen erfüllt ist:

Sie haben Ihre Arbeitslastprobes mit Zeitlimitwerten aktualisiert und GKE hat seit sieben Tagen keine potenziellen Probleme erkannt.
Version 1.34 erreicht das Ende des Supports in Ihrem Release-Channel.

Betroffene Cluster oder Arbeitslasten identifizieren

In den folgenden Abschnitten erfahren Sie, wie Sie Cluster oder Arbeitslasten identifizieren, die von dieser Änderung betroffen sein könnten.

GKE-Empfehlungen und -Insights verwenden

GKE überwacht Ihre Cluster und verwendet den Recommender Dienst, um Cluster zu identifizieren, die von der Erzwingung von Zeitlimits für Exec-Probes betroffen sind. Wenn GKE erkennt, dass ein Cluster Arbeitslasten mit Exec-Probes hat, die möglicherweise das Zeitlimit überschreiten, wird in der Konsole eine Empfehlung mit dem Titel Zeitlimits für Exec-Probes von Arbeitslasten konfigurieren angezeigt. Google Cloud

Insights und Empfehlungen abrufen

Folgen Sie der Anleitung, um Insights und Empfehlungen aufzurufen. Sie können Insights über die Google Cloud Konsole abrufen. Sie können auch die Google Cloud CLI oder die Recommender API verwenden und mit dem folgenden Untertyp filtern:

EXEC_PROBE_TIMEOUT: Zeitlimits für Exec-Probes

Bei Clustern mit aktiven Empfehlungen pausiert GKE automatische Upgrades auf Version 1.35, bis die Zeitlimitkonfigurationen für Exec-Probes aktualisiert wurden, um Unterbrechungen zu vermeiden.

Kubernetes-Ereignisse über die Befehlszeile prüfen

In GKE-Version 1.34 und früher können Sie die Kubernetes-Ereignisse in Ihren Clustern manuell prüfen, um Exec-Probes zu finden, deren Ausführung länger dauert als das vorhandene Zeitlimit. Kubernetes fügt für diese Probes ein Ereignis mit der Meldung command timed out hinzu. Diese Methode ist nützlich, um Arbeitslasten zu identifizieren, bei denen aufgrund kurzer Zeitlimitwerte bereits Probleme auftreten.

Führen Sie einen der folgenden Schritte aus, um betroffene Arbeitslasten zu finden:

Arbeitslasten in mehreren Clustern mit einem Skript finden
Arbeitslasten in bestimmten Clustern über die Befehlszeile finden

Arbeitslasten in mehreren Clustern mit einem Skript finden

Das folgende Bash-Skript durchläuft alle Cluster in Ihrer kubeconfig-Datei , um betroffene Arbeitslasten zu finden. Das Skript sucht in allen vorhandenen und erreichbaren Kubernetes-Kontexten nach Zeitlimitfehlern für Exec-Probes und schreibt die Ergebnisse in eine Textdatei mit dem Namen affected_workloads_report.txt. So führen Sie dieses Skript aus:

Speichern Sie das folgende Skript als execprobe-timeouts.sh:

#!/bin/bash

# This script checks for exec probe timeouts across all existing and reachable
# Kubernetes contexts and writes the findings to a text file, with one
# row for each affected workload, including its cluster name.

# --- Configuration ---
OUTPUT_FILE="affected_workloads_report.txt"
# -------------------

# Check if kubectl and jq are installed
if ! command -v kubectl &> /dev/null || ! command -v jq &> /dev/null; then
    echo "Error: kubectl and jq are required to run this script." >&2
    exit 1
fi

echo "Fetching all contexts from your kubeconfig..."

# Initialize the report file with a formatted header
printf "%-40s | %s\n" "Cluster Context" "Impacted Workload" > "$OUTPUT_FILE"

# Get all context names from the kubeconfig file
CONTEXTS=$(kubectl config get-contexts -o name)

if [[ -z "$CONTEXTS" ]]; then
  echo "No Kubernetes contexts found in your kubeconfig file."
  exit 0
fi

echo "Verifying each context and checking for probe timeouts..."
echo "=================================================="

# Loop through each context
for CONTEXT in $CONTEXTS; do
  echo "--- Checking context: $CONTEXT ---"

  # Check if the cluster is reachable by running a lightweight command
  if kubectl --context="$CONTEXT" get ns --request-timeout=1s > /dev/null 2>&1; then
    echo "Context '$CONTEXT' is reachable. Checking for timeouts..."

    # Find timeout events based on the logic from the documentation
    AFFECTED_WORKLOADS_LIST=$(kubectl --context="$CONTEXT" get events --all-namespaces -o json | jq -r '.items[] | select((.involvedObject.namespace | type == "string") and (.involvedObject.namespace | endswith("-system") | not) and (.message | test("^(Liveness|Readiness|Startup) probe errored(.*): command timed out(.*)|^ * probe errored and resulted in .* state: command timed out.*"))) | .involvedObject.kind + "/" + .involvedObject.name' | uniq)

    if [[ -n "$AFFECTED_WORKLOADS_LIST" ]]; then
      echo "Found potentially affected workloads in context '$CONTEXT'."

      # Loop through each affected workload and write a new row to the report
      # pairing the context with the workload.
      while IFS= read -r WORKLOAD; do
        printf "%-40s | %s\n" "$CONTEXT" "$WORKLOAD" >> "$OUTPUT_FILE"
      done <<< "$AFFECTED_WORKLOADS_LIST"
    else
      echo "No workloads with exec probe timeouts found in context '$CONTEXT'."
    fi
  else
    echo "Context '$CONTEXT' is not reachable or the cluster does not exist. Skipping."
  fi
  echo "--------------------------------------------------"
done

echo "=================================================="
echo "Script finished."
echo "A detailed report of affected workloads has been saved to: $OUTPUT_FILE"

Führen Sie das Skript aus:
```
bash execprobe-timeouts.sh
```

Lesen Sie den Inhalt der Datei affected_workloads_report.txt:

cat affected_workloads_report.txt

Die Ausgabe sieht etwa so aus:

Cluster Context                   | Impacted Workload
-----------------------------------------|----------------------------
gke_my-project_us-central1-c_cluster-1   | Pod/liveness1-exec
gke_my-project_us-central1-c_cluster-1   | Deployment/another-buggy-app
gke_my-project_us-east1-b_cluster-2      | Pod/startup-probe-test

Arbeitslasten in bestimmten Clustern über die Befehlszeile finden

Um betroffene Arbeitslasten in bestimmten Clustern zu identifizieren, können Sie mit dem Tool kubectl nach Zeitlimitfehlern für Exec-Probes suchen. Führen Sie die folgenden Schritte für jeden GKE-Cluster aus, auf dem Version 1.34 oder früher ausgeführt wird:

Als Nächstes stellen Sie die Verbindung zum Cluster her:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME ist der Name des Clusters.
- LOCATIONist der Standort der Clustersteuerungsebene, z. B. us-central1.

Suchen Sie nach Ereignissen, die darauf hinweisen, dass bei einer Exec-Prüfung ein Zeitlimitfehler aufgetreten ist:

kubectl get events --all-namespaces -o json |
    jq -r '.items[] | select((.involvedObject.namespace | type == "string") and (.involvedObject.namespace | endswith("-system") | not) and (.message | test("^(Liveness|Readiness|Startup) probe errored(.*): command timed out(.*)|^ * probe errored and resulted in .* state: command timed out.*"))) | "\(.involvedObject.kind)/\(.involvedObject.name)        Namespace: \(.involvedObject.namespace)"'

Dieser Befehl ignoriert Arbeitslasten in vielen System-Namespaces. Wenn betroffene Arbeitslasten vorhanden sind, sieht die Ausgabe etwa so aus:

Pod/liveness1-exec      Namespace: default

Wiederholen Sie die vorherigen Schritte für jeden Cluster, auf dem GKE-Versionen vor 1.35 ausgeführt werden.

Betroffene Cluster und Arbeitslasten in Cloud Logging finden

Rufen Sie in der Google Cloud Konsole die Seite Log-Explorer auf.

Zum Log-Explorer
Klicken Sie auf die Schaltfläche Abfrage anzeigen, um den Abfrageeditor zu öffnen.
Führen Sie die folgende Abfrage aus:
```
jsonPayload.message=~" probe errored and resulted in .* state: command timed out" OR jsonPayload.message=~" probe errored: command timed out"
```
Die Ausgabe ist eine Liste von Fehlern bei Probes, die durch Befehle verursacht wurden, deren Ausführung länger gedauert hat als das konfigurierte Zeitlimit.

Betroffene Arbeitslasten aktualisieren, bevor Sie ein Upgrade auf Version 1.35 durchführen

Nachdem Sie die betroffenen Arbeitslasten identifiziert haben, müssen Sie die betroffenen Probes aktualisieren.

Prüfen Sie die Aktivitäts-, Bereitschafts- und Startprobes für jeden betroffenen Pod und legen Sie einen geeigneten Wert für timeoutSeconds fest. Dieser Wert sollte lang genug sein, damit der Befehl unter normalen Bedingungen erfolgreich ausgeführt werden kann. Weitere Informationen finden Sie unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.

Öffnen Sie die Manifestdatei für die betroffene Arbeitslast und fügen Sie das Feld timeoutSeconds für Aktivitäts-, Bereitschafts- oder Startprobes hinzu oder ändern Sie es. Die folgende Aktivitätsprüfung hat beispielsweise den Wert 10 im Feld timeoutSeconds:

spec:
  containers:
  - name: my-container
    image: my-image
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10

Wenden Sie das aktualisierte Manifest auf Ihren Cluster an.
Prüfen Sie die aktualisierten Probes auf Fehler. Folgen Sie dazu der Anleitung unter Kubernetes-Ereignisse über die Befeh1lszeile prüfen.

Nachdem Sie alle betroffenen Arbeitslasten aktualisiert und getestet haben, können Sie ein Upgrade Ihres Clusters auf GKE-Version 1.35 durchführen.