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.

Termine chiave: in questa pagina il termine probe exec si riferisce ai probe di attività, idoneità, o avvio che eseguono i comandi utilizzando il campo exec.command nella specifica del probe.

Informazioni sui timeout per i probe exec

A partire dalla versione 1.35 di GKE, Kubernetes applica i timeout per i comandi nel campo exec dei probe di attività, idoneità e avvio. Il campo timeoutSeconds nella specifica di un probe definisce per quanto tempo Kubernetes attende il completamento di eventuali azioni 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 del probe exec. Ad esempio, considera un probe di attività 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 che il probe è riuscito. Nella versione 1.35 e successive, Kubernetes segnala correttamente l'errore del probe dopo cinque secondi.

Questo comportamento in cui Kubernetes ignora i timeout dei probe exec può comportare l'esecuzione indefinita dei probe, il che potrebbe nascondere problemi con le applicazioni o causare comportamenti imprevedibili. Nella versione 1.35 di GKE e successive, Kubernetes applica correttamente i timeout dei comandi, il che comporta un comportamento coerente e prevedibile dei probe in linea con Kubernetes open source.

Impatto dell'applicazione dei timeout per i probe exec

Si tratta di una modifica che introduce un'incompatibilità nelle versioni 1.35 e successive di GKE, necessaria per la stabilità e l'affidabilità dei workload in esecuzione 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, questi probe 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 inferiore al tempo di completamento del comando segnaleranno correttamente gli errori.

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

Se non specifichi una durata del timeout più precisa e i comandi richiedono più tempo per essere completati rispetto al periodo di timeout esistente, i probe segnaleranno errori nella versione 1.35 e successive. A seconda del tipo di probe, si applica il seguente comportamento quando un probe non riesce:

• 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. Nelle versioni precedenti alla 1.35, un timeout potrebbe generare solo un evento di avviso senza forzare il riavvio di un container. Se il probe non riesce ripetutamente, i pod potrebbero bloccarsi in un loop di arresto anomalo con lo stato del pod CrashLoopBackOff.
• Probe di idoneità: se un probe di idoneità non riesce perché un comando ha raggiunto il timeout, Kubernetes aggiorna la condizione del pod Ready con lo stato False. Ciò significa che Kubernetes non invia traffico al pod finché il probe non riesce. Nella versione 1.35 di GKE e successive, il pod viene rimosso dagli endpoint del servizio. Nelle versioni precedenti alla 1.35, un timeout potrebbe generare solo un evento di avviso senza rimuovere il pod dal servizio. 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 non riesce, 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 loop di arresto anomalo con lo 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 i 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.

Avviso: quando esegui l'upgrade di un cluster alla versione 1.35 o successive, GKE applica correttamente i timeout per i probe exec. Se esegui l'upgrade del cluster senza aggiornare i valori nel campo timeoutSeconds per i probe exec, potrebbero verificarsi interruzioni del workload.

Identificare i cluster o i workload interessati

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

Utilizzare insight e suggerimenti di GKE

GKE monitora i cluster e utilizza il servizio Recommender per identificare i cluster interessati dall' applicazione dei timeout dei probe exec. Se GKE rileva che un cluster ha workload con probe exec che potrebbero raggiungere il timeout, nella console viene visualizzato un suggerimento intitolato Configura i timeout dei probe exec del workload.Google Cloud

Visualizzare insight e suggerimenti

Segui le istruzioni per visualizzare insight e suggerimenti. Puoi ottenere insight utilizzando la Google Cloud console. Puoi anche utilizzare Google Cloud CLI o l'API Recommender, filtrando con il seguente sottotipo:

• EXEC_PROBE_TIMEOUT: timeout dei probe exec

Per i cluster con suggerimenti attivi, GKE mette in pausa gli upgrade automatici alla versione 1.35 finché le configurazioni del timeout dei probe exec non vengono aggiornate per consentire operazioni che non causino interruzioni.

Controllare gli eventi di Kubernetes utilizzando la riga di comando

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

Nota: gli eventi di Kubernetes vengono conservati solo per un'ora. Per identificare i workload con eventi verificatisi più di un'ora fa, utilizza Cloud Logging.

Per trovare i workload interessati, procedi in uno dei seguenti modi:

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

Trovare i workload in più cluster utilizzando uno script

Il seguente script bash scorre tutti i cluster presenti nel file kubeconfig per trovare i workload interessati. Questo script verifica la presenza di errori di timeout dei 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:

1. 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"
   

2. Esegui lo script:

   bash execprobe-timeouts.sh
   

3. 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 workload interessati in cluster specifici, puoi utilizzare lo strumento kubectl per verificare la presenza di errori di timeout dei probe exec. Segui questi passaggi per ogni cluster GKE che esegue la versione 1.34 o precedenti:

1. Connettiti al cluster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=LOCATION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster.
   • LOCATION: la località del control plane del cluster, ad esempio us-central1.

2. Verifica 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 workload in molti spazi dei nomi di sistema. Se esistono workload interessati, l'output è simile al seguente:

   Pod/liveness1-exec      Namespace: default
   

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

Trovare cluster e workload interessati in Cloud Logging

1. Nella Google Cloud console, vai alla pagina Esplora log.

   Vai a Esplora log

2. Per aprire l'editor di query, fai clic sul pulsante di attivazione/disattivazione Mostra query.

3. 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 dei probe causati da comandi che hanno richiesto più tempo per essere completati rispetto al periodo di timeout configurato.

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

Best practice:

Prima di apportare modifiche all'ambiente di produzione, testa le modifiche ai probe e l'impatto dell'upgrade alla versione 1.35 in un ambiente di sviluppo.

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

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

2. Apri il file manifest del workload interessato e aggiungi o modifica il campo timeoutSeconds per i probe di attività, idoneità 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
   

3. Applica il manifest aggiornato al cluster.

4. Verifica la presenza di errori nei probe aggiornati seguendo i passaggi descritti in Controllare gli eventi di Kubernetes utilizzando la riga di comando.

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