Configure os tempos limite da sonda exec antes de atualizar para a versão 1.35 do GKE

Autopilot Padrão

---

Esta página descreve como preparar as sondas de atividade, de prontidão e de arranque antes de atualizar os clusters do Google Kubernetes Engine (GKE) para a versão 1.35 e posterior, definindo limites de tempo para comandos nestas sondas.

Termo principal: esta página usa o termo exec probe para se referir a sondas de atividade, prontidão ou inicialização que executam comandos através do campo exec.command na especificação da sonda.

Acerca dos limites de tempo para sondas de execução

A partir da versão 1.35 do GKE, o Kubernetes aplica limites de tempo aos comandos no campo exec das sondas de vitalidade, prontidão e arranque. O campo timeoutSeconds na especificação de uma sonda define durante quanto tempo o Kubernetes aguarda que uma sonda conclua as ações. Se omitir este campo, o valor predefinido é 1, o que significa que as ações têm um segundo para serem concluídas.

Nas versões do GKE anteriores à 1.35, o Kubernetes ignora o valor no campo timeoutSeconds para comandos de sondagem exec. Por exemplo, considere uma sonda de vitalidade com as seguintes propriedades:

• Um valor de 5 no campo timeoutSeconds.
• Um comando no campo exec.command que demora 10 segundos a ser concluído.

Nas versões anteriores à 1.35, o Kubernetes ignora este limite de tempo de cinco segundos e comunica incorretamente que a sondagem foi bem-sucedida. Na versão 1.35 e posterior, o Kubernetes falha corretamente a sondagem após cinco segundos.

Este comportamento em que o Kubernetes ignora os tempos limite da sondagem exec pode resultar em sondagens que são executadas indefinidamente, o que pode ocultar problemas com as suas aplicações ou causar um comportamento imprevisível. Na versão 1.35 e posterior do GKE, o Kubernetes aplica corretamente os limites de tempo dos comandos, o que resulta num comportamento de sondagem consistente e previsível que se alinha com o Kubernetes de código aberto.

Impacto da aplicação de limites de tempo para sondagens de execução

Esta é uma alteração interruptiva na versão 1.35 e posterior do GKE, que é necessária para a estabilidade e a fiabilidade das cargas de trabalho executadas no GKE. Quando atualiza os clusters para a versão 1.35 e posterior, pode notar um comportamento inesperado da carga de trabalho se as cargas de trabalho tiverem sondas exec com uma das seguintes propriedades:

• Omita o campo timeoutSeconds: na versão 1.35 e posterior, estas sondagens têm um segundo para concluir os comandos com êxito. Se o comando não for concluído com êxito num segundo, as sondagens vão comunicar corretamente as falhas.
• Especifique períodos de limite de tempo curtos: na versão 1.35 e posteriores, as sondagens com um período de limite de tempo mais curto do que o tempo de conclusão do comando vão comunicar corretamente as falhas.

Na versão 1.34 e anteriores do GKE, o Kubernetes comunica um erro nas sondagens exec que cumprem qualquer uma destas condições. No entanto, os comandos nestas sondagens exec ainda podem ser executados até à conclusão, porque o erro da sondagem não é uma falha da sondagem.

Se não especificar uma duração de limite de tempo mais precisa e os comandos demorarem mais do que o período de limite de tempo existente a serem concluídos, as suas sondagens vão comunicar falhas na versão 1.35 e posteriores. Consoante o tipo de teste, o seguinte comportamento aplica-se quando um teste falha:

• Sondas de atividade: se uma sonda de atividade falhar porque um comando atingiu o limite de tempo, o Kubernetes assume que a aplicação falhou e reinicia o contentor. Se a sondagem falhar repetidamente, os seus pods podem ficar bloqueados num ciclo de falhas com um CrashLoopBackOff estado do pod.
• Sondas de prontidão: se uma sonda de prontidão falhar porque um comando atingiu o limite de tempo, o Kubernetes atualiza a condição do Ready pod com um estado False. O Kubernetes não envia tráfego para o pod até que a sondagem seja bem-sucedida. Se todos os Pods que suportam um Serviço tiverem o estado False para a condição Ready, pode notar interrupções no Serviço.
• Sondagens de arranque: se uma sondagem de arranque falhar, o Kubernetes assume que a aplicação não foi iniciada e reinicia o contentor. Se a sondagem falhar repetidamente, os seus pods podem ficar bloqueados num ciclo de falhas com um CrashLoopBackOff estado do pod.

Atualizações automáticas pausadas

O GKE pausa as atualizações automáticas para a versão 1.35 quando deteta que as cargas de trabalho num cluster podem ser afetadas por esta alteração. O GKE retoma as atualizações automáticas se a versão 1.35 for um destino de atualização automática para o seu painel de controlo e nós, e se uma das seguintes condições for cumprida:

• Atualizou as sondas de carga de trabalho com valores de tempo limite e o GKE não detetou potenciais problemas durante sete dias.
• A versão 1.34 atinge o fim do apoio técnico no seu canal de lançamento.

Aviso: quando atualiza um cluster para a versão 1.35 ou posterior, o GKE aplica corretamente os limites de tempo limite para sondagens exec. Se atualizar o cluster sem atualizar os valores no campo timeoutSeconds para sondas de execução, podem ocorrer interrupções na carga de trabalho.

Identifique os clusters ou as cargas de trabalho afetados

As secções seguintes mostram-lhe como identificar clusters ou cargas de trabalho que podem ser afetados por esta alteração.

Verifique os eventos do Kubernetes através da linha de comandos

Na versão 1.34 e anterior do GKE, pode inspecionar manualmente os eventos do Kubernetes nos seus clusters para encontrar sondagens de execução que demoram mais tempo a concluir do que o período de limite de tempo existente. O Kubernetes adiciona um evento com uma mensagem command timed out para estas sondagens. Este método é útil para identificar cargas de trabalho que já estão a ter problemas devido a valores de tempo limite curtos.

Para encontrar cargas de trabalho afetadas, faça uma das seguintes ações:

• Encontre cargas de trabalho em vários clusters através de um script
• Encontre cargas de trabalho em clusters específicos através da linha de comandos

Encontre cargas de trabalho em vários clusters através de um script

O seguinte script bash itera sobre todos os clusters que estão no seu ficheiro kubeconfig para encontrar cargas de trabalho afetadas. Este script verifica se existem erros de limite de tempo da sonda exec em todos os contextos do Kubernetes existentes e acessíveis, e escreve as conclusões num ficheiro de texto denominado affected_workloads_report.txt. Para executar este script, siga estes passos:

1. Guarde o seguinte script 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"
   

2. Execute o script:

   bash execprobe-timeouts.sh
   

3. Leia o conteúdo do ficheiro affected_workloads_report.txt:

   cat affected_workloads_report.txt
   

   O resultado é semelhante ao seguinte:

   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
   

Encontre cargas de trabalho em clusters específicos através da linha de comandos

Para identificar cargas de trabalho afetadas em clusters específicos, pode usar a kubectlferramenta para verificar se existem erros de tempo limite da sondagem exec. Siga estes passos para cada cluster do GKE que execute a versão 1.34 ou anterior:

1. Ligue-se ao cluster:

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

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: a localização do plano de controlo do cluster, como us-central1.

2. Procure eventos que indiquem que uma sondagem exec tem um erro de limite de tempo:

   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 cargas de trabalho em muitos espaços de nomes do sistema. Se existirem cargas de trabalho afetadas, o resultado é semelhante ao seguinte:

   Pod/liveness1-exec      Namespace: default
   

3. Repita os passos anteriores para cada cluster que execute versões do GKE anteriores à 1.35.

Encontre clusters e cargas de trabalho afetados no Cloud Logging

1. Na Google Cloud consola, aceda à página Explorador de registos.

   Aceda ao Explorador de registos

2. Para abrir o editor de consultas, clique no botão Mostrar consulta.

3. Execute a seguinte consulta:

   jsonPayload.message=~" probe errored and resulted in .* state: command timed out" OR jsonPayload.message=~" probe errored : command timed out"
   

   O resultado é uma lista de erros de sondagem causados por comandos que demoraram mais tempo a concluir do que o período de limite de tempo configurado.

Atualize as cargas de trabalho afetadas antes de atualizar para a versão 1.35

Prática recomendada:

Antes de fazer alterações ao seu ambiente de produção, teste as alterações às sondas e o impacto da atualização para a versão 1.35 num ambiente de desenvolvimento.

Depois de identificar as cargas de trabalho afetadas, tem de atualizar as sondas afetadas.

1. Reveja as sondas de atividade, prontidão e arranque de cada Pod afetado e determine um valor timeoutSeconds adequado. Este valor deve ser suficientemente longo para que o comando seja executado com êxito em condições normais. Para mais informações, consulte o artigo Configure as sondas de atividade, disponibilidade e arranque.

2. Abra o ficheiro de manifesto para a carga de trabalho afetada e adicione ou modifique o campo timeoutSeconds para sondas de atividade, prontidão ou arranque. Por exemplo, a seguinte sondagem de atividade tem um valor de 10 no campo timeoutSeconds:

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

3. Aplique o manifesto atualizado ao seu cluster.

4. Verifique se existem erros nas sondas atualizadas seguindo os passos em Verifique os eventos do Kubernetes através da linha de comandos.

Depois de atualizar e testar todas as cargas de trabalho afetadas, pode atualizar o cluster para a versão 1.35 do GKE.