Se usó la API de Cloud Translation para traducir esta página.

Configura los tiempos de espera de la sonda exec antes de actualizar a la versión 1.35 de GKE

Autopilot estándar

En esta página, se describe cómo preparar tus sondas de actividad, preparación e inicio antes de actualizar tus clústeres de Google Kubernetes Engine (GKE) a la versión 1.35 y versiones posteriores configurando tiempos de espera para los comandos en estas sondas.

Acerca de los tiempos de espera para los sondeos de ejecución

A partir de la versión 1.35 de GKE, Kubernetes aplica tiempos de espera para los comandos en el campo exec de los sondeos de funcionamiento, preparación y inicio. El campo timeoutSeconds en la especificación de un sondeo define cuánto tiempo espera Kubernetes a que un sondeo complete las acciones. Si omites este campo, el valor predeterminado es 1, lo que significa que las acciones tienen un segundo para completarse.

En las versiones de GKE anteriores a la 1.35, Kubernetes ignora el valor del campo timeoutSeconds para los comandos de sondeo exec. Por ejemplo, considera una sonda de actividad que tiene las siguientes propiedades:

Un valor de 5 en el campo timeoutSeconds.
Un comando en el campo exec.command que tarda 10 segundos en completarse.

En versiones anteriores a la 1.35, Kubernetes ignora este tiempo de espera de cinco segundos y, de forma incorrecta, informa que la sonda se realizó correctamente. En la versión 1.35 y posteriores, Kubernetes falla correctamente la sonda después de cinco segundos.

Este comportamiento en el que Kubernetes ignora los tiempos de espera de las sondas exec puede generar sondas que se ejecutan de forma indefinida, lo que podría ocultar problemas con tus aplicaciones o provocar un comportamiento impredecible. En la versión 1.35 y posteriores de GKE, Kubernetes aplica correctamente los tiempos de espera de los comandos, lo que genera un comportamiento de sondeo coherente y predecible que se alinea con Kubernetes de código abierto.

Impacto de aplicar tiempos de espera para los sondeos de ejecución

Este es un cambio rotundo en la versión 1.35 y posteriores de GKE que es necesario para la estabilidad y confiabilidad de las cargas de trabajo que se ejecutan en GKE. Cuando actualices tus clústeres a la versión 1.35 y posteriores, es posible que observes un comportamiento inesperado de las cargas de trabajo si estas tienen sondeos de ejecución con una de las siguientes propiedades:

Omite el campo timeoutSeconds: En la versión 1.35 y versiones posteriores, estas sondas tienen un segundo para completar los comandos correctamente. Si el comando no se completa correctamente en un segundo, las sondas informarán correctamente los errores.
Especifica períodos de espera cortos: En la versión 1.35 y posteriores, las sondas con un período de espera más corto que el tiempo de finalización del comando informarán correctamente los errores.

En la versión 1.34 y anteriores de GKE, Kubernetes informa un error en las sondas de ejecución que cumplen con cualquiera de estas condiciones. Sin embargo, los comandos de estas sondas exec aún pueden ejecutarse hasta completarse, ya que el error de la sonda no es una falla de la sonda.

Si no especificas una duración de tiempo de espera más precisa y los comandos tardan más en completarse que el período de tiempo de espera existente, tus sondeos informarán fallas en la versión 1.35 y versiones posteriores. Según el tipo de sondeo, se aplica el siguiente comportamiento cuando falla un sondeo:

Sondeos de funcionamiento: Si un sondeo de funcionamiento falla porque se agotó el tiempo de espera de un comando, Kubernetes supone que la aplicación falló y reinicia el contenedor. Si el sondeo falla repetidamente, es posible que tus Pods queden atascados en un bucle de fallas con un estado de Pod CrashLoopBackOff.
Sondeos de estado de preparación: Si un sondeo de estado de preparación falla porque se agotó el tiempo de espera de un comando, Kubernetes actualiza la condición del Pod Ready con un estado False. Kubernetes no envía tráfico al Pod hasta que el sondeo se realiza correctamente. Si todos los Pods que respaldan un servicio tienen el estado False para la condición Ready, es posible que notes interrupciones en el servicio.
Sondeos de inicio: Si falla un sondeo de inicio, Kubernetes supone que la aplicación no se inició y reinicia el contenedor. Si la sonda falla repetidamente, es posible que tus Pods queden atascados en un bucle de fallas con un estado de Pod CrashLoopBackOff.

Se pausaron las actualizaciones automáticas

GKE pausa las actualizaciones automáticas a la versión 1.35 cuando detecta que las cargas de trabajo de un clúster podrían verse afectadas por este cambio. GKE reanuda las actualizaciones automáticas si la versión 1.35 es un objetivo de actualización automática para tu plano de control y tus nodos, y si se cumple una de las siguientes condiciones:

Actualizaste los sondeos de carga de trabajo con valores de tiempo de espera y GKE no detectó posibles problemas durante siete días.
La versión 1.34 alcanza el fin de la asistencia en tu canal de versiones.

Identifica los clústeres o las cargas de trabajo afectados

En las siguientes secciones, se muestra cómo identificar los clústeres o las cargas de trabajo que podrían verse afectados por este cambio.

Cómo verificar eventos de Kubernetes con la línea de comandos

En la versión 1.34 y anteriores de GKE, puedes inspeccionar manualmente los eventos de Kubernetes en tus clústeres para encontrar sondeos de ejecución que tardan más en completarse que el período de espera existente. Kubernetes agrega un evento con un mensaje command timed out para estos sondeos. Este método es útil para identificar cargas de trabajo que ya experimentan problemas debido a valores de tiempo de espera cortos.

Para encontrar las cargas de trabajo afectadas, realiza una de las siguientes acciones:

Cómo encontrar cargas de trabajo en varios clústeres con una secuencia de comandos
Cómo encontrar cargas de trabajo en clústeres específicos con la línea de comandos

Cómo encontrar cargas de trabajo en varios clústeres con una secuencia de comandos

La siguiente secuencia de comandos de Bash itera en todos los clústeres que se encuentran en tu archivo kubeconfig para encontrar las cargas de trabajo afectadas. Esta secuencia de comandos verifica si hay errores de tiempo de espera de la sonda exec en todos los contextos de Kubernetes existentes y accesibles, y escribe los resultados en un archivo de texto llamado affected_workloads_report.txt. Para ejecutar esta secuencia de comandos, sigue estos pasos:

Guarda la siguiente secuencia de comandos como 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"

Ejecuta la secuencia de comandos:
```
bash execprobe-timeouts.sh
```

Lee el contenido del archivo affected_workloads_report.txt:

cat affected_workloads_report.txt

El resultado es similar a este:

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

Cómo encontrar cargas de trabajo en clústeres específicos con la línea de comandos

Para identificar las cargas de trabajo afectadas en clústeres específicos, puedes usar la herramienta kubectl para verificar si hay errores de tiempo de espera de la sonda de ejecución. Sigue estos pasos para cada clúster de GKE que ejecute la versión 1.34 o una anterior:

Conéctese al clúster:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION
```
Reemplaza lo siguiente:
- CLUSTER_NAME: el nombre del clúster
- LOCATION: Es la ubicación del plano de control del clúster, como us-central1.

Verifica si hay eventos que indiquen que una sonda exec tiene un error de tiempo de espera:

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

Este comando ignora las cargas de trabajo en muchos espacios de nombres del sistema. Si existen cargas de trabajo afectadas, el resultado es similar al siguiente:

Pod/liveness1-exec      Namespace: default

Repite los pasos anteriores para cada clúster que ejecute versiones de GKE anteriores a la 1.35.

Busca los clústeres y las cargas de trabajo afectados en Cloud Logging

En la Google Cloud consola, ve a la página Explorador de registros.

Ir al Explorador de registros
Para abrir el editor de consultas, haz clic en el botón de activación Mostrar consulta.
Ejecute la siguiente consulta:
```
jsonPayload.message=~" probe errored and resulted in .* state: command timed out" OR jsonPayload.message=~" probe errored : command timed out"
```
El resultado es una lista de errores de sondeo que se produjeron debido a comandos que tardaron más en completarse que el período de tiempo de espera configurado.

Actualiza las cargas de trabajo afectadas antes de actualizar a la versión 1.35

Después de identificar las cargas de trabajo afectadas, debes actualizar las sondas afectadas.

Revisa los sondeos de capacidad de funcionamiento, preparación e inicio de cada Pod afectado y determina un valor de timeoutSeconds adecuado. Este valor debe ser lo suficientemente largo para que el comando se ejecute correctamente en condiciones normales. Para obtener más información, consulta Configura sondeos de funcionamiento, inicio y preparación.

Abre el archivo de manifiesto de la carga de trabajo afectada y agrega o modifica el campo timeoutSeconds para las sondas de actividad, preparación o inicio. Por ejemplo, la siguiente sonda de actividad tiene un valor de 10 en el campo timeoutSeconds:

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

Aplica el manifiesto actualizado a tu clúster.
Para verificar si hay errores en las sondas actualizadas, sigue los pasos que se indican en Cómo verificar eventos de Kubernetes con la línea de comandos.

Después de actualizar y probar todas las cargas de trabajo afectadas, puedes actualizar tu clúster a la versión 1.35 de GKE.