Questa pagina è stata tradotta dall'API Cloud Translation.

Configura i timeout del probe exec prima di eseguire l'upgrade a GKE versione 1.35

Autopilot Standard

Questa pagina descrive come preparare i probe di attività, idoneità e avvio prima di eseguire l'upgrade dei cluster Google Kubernetes Engine (GKE) alla versione 1.35 e successive impostando i timeout per i comandi in questi probe.

Informazioni sui timeout per i probe di esecuzione

A partire dalla versione 1.35 di GKE, Kubernetes applica timeout per i comandi nel campo exec dei probe di attività, di idoneità e di avvio. Il campo timeoutSeconds nella specifica di un probe definisce il tempo di attesa di Kubernetes per il completamento di qualsiasi azione da parte di un probe. Se ometti questo campo, il valore predefinito è 1, il che significa che le azioni hanno un secondo di tempo per essere completate.

Nelle versioni di GKE precedenti alla 1.35, Kubernetes ignora il valore nel campo timeoutSeconds per i comandi di probe exec. Ad esempio, considera un probe di liveness con le seguenti proprietà:

Un valore di 5 nel campo timeoutSeconds.
Un comando nel campo exec.command che richiede 10 secondi per essere completato.

Nelle versioni precedenti alla 1.35, Kubernetes ignora questo timeout di cinque secondi e segnala erroneamente il probe come riuscito. Nella versione 1.35 e successive, Kubernetes non riesce a eseguire correttamente il probe dopo cinque secondi.

Questo comportamento in cui Kubernetes ignora i timeout del probe exec può comportare probe che vengono eseguiti a tempo indeterminato, il che potrebbe nascondere problemi con le tue applicazioni o potrebbe causare un comportamento imprevedibile. In GKE versione 1.35 e successive, Kubernetes applica correttamente i timeout dei comandi, il che si traduce in un comportamento di probe coerente e prevedibile in linea con Kubernetes open source.

Impatto dell'applicazione dei timeout per i probe exec

Si tratta di una modifica che causa interruzioni in GKE versione 1.35 e successive, necessaria per la stabilità e l'affidabilità dei carichi di lavoro eseguiti su GKE. Quando esegui l'upgrade dei cluster alla versione 1.35 e successive, potresti notare un comportamento imprevisto dei workload se questi hanno probe exec con una delle seguenti proprietà:

Ometti il campo timeoutSeconds: nella versione 1.35 e successive, queste sonde hanno un secondo di tempo per completare correttamente i comandi. Se il comando non viene completato correttamente in un secondo, i probe segnaleranno correttamente gli errori.
Specifica periodi di timeout brevi: nella versione 1.35 e successive, i probe con un periodo di timeout più breve rispetto al tempo di completamento del comando segnaleranno correttamente gli errori.

In GKE versione 1.34 e precedenti, Kubernetes segnala un errore nei probe exec che soddisfano una di queste condizioni. Tuttavia, i comandi in queste sonde exec possono comunque essere eseguiti fino al completamento, perché l'errore della sonda non è un errore della sonda.

Se non specifichi una durata del timeout più precisa e i comandi impiegano più tempo del periodo di timeout esistente per essere completati, i probe segnaleranno errori nella versione 1.35 e successive. A seconda del tipo di probe, quando un probe non va a buon fine si verifica il seguente comportamento:

Probe di attività: se un probe di attività non riesce perché un comando ha raggiunto il timeout, Kubernetes presuppone che l'applicazione non sia riuscita e riavvia il container. Se il probe non riesce ripetutamente, i tuoi pod potrebbero bloccarsi in un ciclo di arresto anomalo con uno stato del pod CrashLoopBackOff.
Probe di idoneità: se un probe di idoneità non va a buon fine perché un comando è scaduto, Kubernetes aggiorna la condizione del pod Ready con lo stato False. Kubernetes non invia traffico al pod finché il probe non funziona correttamente. Se tutti i pod che supportano un servizio hanno lo stato False per la condizione Ready, potresti notare interruzioni del servizio.
Probe di avvio: se un probe di avvio ha esito negativo, Kubernetes presuppone che l'applicazione non sia stata avviata e riavvia il container. Se il probe non riesce ripetutamente, i pod potrebbero bloccarsi in un ciclo di arresti anomali con uno stato del pod CrashLoopBackOff.

Upgrade automatici in pausa

GKE mette in pausa gli upgrade automatici alla versione 1.35 quando rileva che i workload in un cluster potrebbero essere interessati da questa modifica. GKE riprende gli upgrade automatici se la versione 1.35 è un target di upgrade automatico per il control plane e i nodi, e se viene soddisfatta una delle seguenti condizioni:

Hai aggiornato i probe del workload con valori di timeout e GKE non ha rilevato potenziali problemi per sette giorni.
La versione 1.34 raggiunge la fine del supporto nel tuo canale di rilascio.

Identifica i cluster o i workload interessati

Le sezioni seguenti mostrano come identificare i cluster o i carichi di lavoro che potrebbero essere interessati da questa modifica.

Controlla gli eventi Kubernetes utilizzando la riga di comando

Nelle versioni di GKE 1.34 e precedenti, puoi ispezionare manualmente gli eventi Kubernetes nei tuoi cluster per trovare probe exec che impiegano più tempo per essere completati rispetto al periodo di timeout esistente. Kubernetes aggiunge un evento con un messaggio command timed out per questi probe. Questo metodo è utile per identificare i carichi di lavoro che presentano già problemi a causa di valori di timeout brevi.

Per trovare i workload interessati, esegui una delle seguenti operazioni:

Trovare i workload in più cluster utilizzando uno script
Trovare i carichi di lavoro in cluster specifici utilizzando la riga di comando

Trovare i workload in più cluster utilizzando uno script

Il seguente script bash esegue l'iterazione su tutti i cluster presenti nel tuo file kubeconfig per trovare i workload interessati. Questo script verifica la presenza di errori di timeout del probe exec in tutti i contesti Kubernetes esistenti e raggiungibili e scrive i risultati in un file di testo denominato affected_workloads_report.txt. Per eseguire questo script, segui questi passaggi:

Salva il seguente script come 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"

Esegui lo script:
```
bash execprobe-timeouts.sh
```

Leggi i contenuti del file affected_workloads_report.txt:

cat affected_workloads_report.txt

L'output è simile al seguente:

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

Trovare i workload in cluster specifici utilizzando la riga di comando

Per identificare i carichi di lavoro interessati in cluster specifici, puoi utilizzare lo strumento kubectl per verificare la presenza di errori di timeout del probe di esecuzione. Segui questi passaggi per ogni cluster GKE che esegue la versione 1.34 o precedente:

Connettiti al cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster.
- LOCATION: la posizione del control plane del cluster, ad esempio us-central1.

Controlla la presenza di eventi che indicano che un probe exec ha un errore di timeout:

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)"'

Questo comando ignora i carichi di lavoro in molti spazi dei nomi di sistema. Se esistono carichi di lavoro interessati, l'output è simile al seguente:

Pod/liveness1-exec      Namespace: default

Ripeti i passaggi precedenti per ogni cluster che esegue versioni di GKE precedenti alla 1.35.

Trovare cluster e workload interessati in Cloud Logging

Nella console Google Cloud , vai alla pagina Esplora log.

Vai a Esplora log
Per aprire l'editor query, fai clic sul pulsante di attivazione/disattivazione Mostra query.
Esegui questa query:
```
jsonPayload.message=~" probe errored and resulted in .* state: command timed out" OR jsonPayload.message=~" probe errored : command timed out"
```
L'output è un elenco di errori di probe causati da comandi che hanno richiesto più tempo per essere completati rispetto al periodo di timeout configurato.

Aggiorna i workload interessati prima di eseguire l'upgrade alla versione 1.35

Dopo aver identificato i workload interessati, devi aggiornare i probe interessati.

Esamina i probe di attività, disponibilità e avvio per ogni pod interessato e determina un valore timeoutSeconds appropriato. Questo valore deve essere abbastanza lungo da consentire l'esecuzione corretta del comando in condizioni normali. Per saperne di più, consulta Configurare i probe di attività, disponibilità e avvio.

Apri il file manifest del workload interessato e aggiungi o modifica il campo timeoutSeconds per i probe di attività, disponibilità o avvio. Ad esempio, il seguente probe di attività ha un valore di 10 nel campo timeoutSeconds:

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

Applica il manifest aggiornato al tuo cluster.
Controlla la presenza di errori nei probe aggiornati seguendo i passaggi descritti in Controllare gli eventi Kubernetes utilizzando la riga di comando.

Dopo aver aggiornato e testato tutti i workload interessati, puoi eseguire l'upgrade del cluster a GKE versione 1.35.