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

Mengonfigurasi waktu tunggu pemeriksaan exec sebelum mengupgrade ke GKE versi 1.35

Autopilot Standard

Halaman ini menjelaskan cara menyiapkan pemeriksaan keaktifan, kesiapan, dan startup sebelum Anda mengupgrade cluster Google Kubernetes Engine (GKE) ke versi 1.35 dan yang lebih baru dengan menetapkan waktu tunggu untuk perintah dalam pemeriksaan ini.

Tentang waktu tunggu untuk pemeriksaan eksekusi

Mulai GKE versi 1.35, Kubernetes menerapkan waktu tunggu untuk perintah di kolom exec pemeriksaan keaktifan, kesiapan, dan startup. Kolom timeoutSeconds dalam spesifikasi pemeriksaan menentukan berapa lama Kubernetes menunggu pemeriksaan untuk menyelesaikan tindakan apa pun. Jika Anda menghapus kolom ini, nilai defaultnya adalah 1, yang berarti bahwa tindakan apa pun memiliki waktu satu detik untuk diselesaikan.

Di GKE versi yang lebih lama dari 1.35, Kubernetes mengabaikan nilai di kolom timeoutSeconds untuk perintah pemeriksaan eksekusi. Misalnya, pertimbangkan pemeriksaan keaktifan yang memiliki properti berikut:

Nilai 5 di kolom timeoutSeconds.
Perintah di kolom exec.command yang memerlukan waktu 10 detik untuk diselesaikan.

Dalam versi yang lebih lama dari 1.35, Kubernetes mengabaikan waktu tunggu lima detik ini dan salah melaporkan pemeriksaan sebagai berhasil. Dalam versi 1.35 dan yang lebih baru, Kubernetes dengan benar melaporkan pemeriksaan gagal setelah lima detik.

Perilaku ini, yang mana Kubernetes mengabaikan waktu tunggu pemeriksaan eksekusi, dapat menyebabkan pemeriksaan berjalan tanpa batas, yang mungkin menyembunyikan masalah pada aplikasi Anda atau dapat menyebabkan perilaku yang tidak dapat diprediksi. Di GKE versi 1.35 dan yang lebih baru, Kubernetes dengan benar menerapkan waktu tunggu perintah, yang menghasilkan perilaku pemeriksaan yang konsisten dan dapat diprediksi yang selaras dengan Kubernetes open source.

Dampak penerapan waktu tunggu untuk pemeriksaan eksekusi

Ini adalah perubahan yang dapat menyebabkan gangguan pada GKE versi 1.35 dan yang lebih baru yang diperlukan untuk stabilitas dan keandalan workload yang berjalan di GKE. Saat mengupgrade cluster ke 1.35 dan yang lebih baru, Anda mungkin melihat perilaku workload yang tidak terduga jika workload memiliki pemeriksaan eksekusi dengan salah satu properti berikut:

Menghapus kolom timeoutSeconds: di versi 1.35 dan yang lebih baru, pemeriksaan ini memiliki waktu satu detik untuk berhasil menyelesaikan perintah. Jika perintah tidak berhasil diselesaikan dalam satu detik, pemeriksaan akan melaporkan kegagalan dengan benar.
Menentukan periode waktu tunggu yang singkat: di versi 1.35 dan yang lebih baru, pemeriksaan dengan periode waktu tunggu yang lebih singkat dari waktu penyelesaian perintah akan melaporkan kegagalan dengan benar.

Di GKE versi 1.34 dan yang lebih lama, Kubernetes melaporkan error dalam pemeriksaan eksekusi yang memenuhi salah satu kondisi ini. Namun, perintah dalam pemeriksaan eksekusi ini masih dapat berjalan hingga selesai, karena error pemeriksaan bukanlah kegagalan pemeriksaan.

Jika Anda tidak menentukan durasi waktu tunggu yang lebih akurat dan perintah memerlukan waktu lebih lama dari periode waktu tunggu yang ada untuk diselesaikan, pemeriksaan akan melaporkan kegagalan di versi 1.35 dan yang lebih baru. Bergantung pada jenis pemeriksaan, perilaku berikut berlaku saat pemeriksaan gagal:

Pemeriksaan keaktifan: jika pemeriksaan keaktifan gagal karena perintah waktu tunggu habis, Kubernetes mengasumsikan bahwa aplikasi gagal dan memulai ulang container. Dalam versi yang lebih lama dari 1.35, waktu tunggu mungkin hanya menghasilkan peristiwa peringatan tanpa memaksa container dimulai ulang. Jika pemeriksaan berulang kali gagal, Pod Anda mungkin akan terjebak dalam loop error dengan status Pod CrashLoopBackOff.
Pemeriksaan kesiapan: jika pemeriksaan kesiapan gagal karena perintah waktu tunggu habis, Kubernetes akan memperbarui kondisi Pod Ready dengan status False. Artinya, Kubernetes tidak mengirimkan traffic apa pun ke Pod hingga pemeriksaan berhasil. Di GKE versi 1.35 dan yang lebih baru, Pod akan dihapus dari endpoint Layanan. Dalam versi yang lebih lama dari 1.35, waktu tunggu mungkin hanya menghasilkan peristiwa peringatan tanpa menghapus Pod dari layanan. Jika semua Pod yang mendukung Layanan memiliki status False untuk kondisi Ready, Anda mungkin akan melihat gangguan pada Layanan.
Pemeriksaan startup: jika pemeriksaan startup gagal, Kubernetes mengasumsikan bahwa aplikasi gagal dimulai dan memulai ulang container. Jika pemeriksaan berulang kali gagal, Pod Anda mungkin akan terjebak dalam loop error dengan status Pod CrashLoopBackOff.

Upgrade otomatis dijeda

GKE menjeda upgrade otomatis ke versi 1.35 saat mendeteksi bahwa workload di cluster mungkin terpengaruh oleh perubahan ini. GKE melanjutkan upgrade otomatis jika versi 1.35 adalah target upgrade otomatis untuk bidang kontrol dan node Anda, dan jika salah satu kondisi berikut terpenuhi:

Anda memperbarui pemeriksaan workload dengan nilai waktu tunggu dan GKE belum mendeteksi potensi masalah selama tujuh hari.
Versi 1.34 mencapai akhir dukungan di saluran rilis Anda.

Mengidentifikasi cluster atau workload yang terpengaruh

Bagian berikut menunjukkan cara mengidentifikasi cluster atau workload yang mungkin terpengaruh oleh perubahan ini.

Menggunakan rekomendasi dan insight GKE

GKE memantau cluster Anda dan menggunakan layanan Recommender untuk mengidentifikasi cluster yang terpengaruh oleh penerapan waktu tunggu pemeriksaan eksekusi. Jika GKE mendeteksi bahwa a cluster memiliki workload dengan pemeriksaan eksekusi yang mungkin waktu tunggunya habis, rekomendasi berjudul Konfigurasi waktu tunggu pemeriksaan eksekusi workload Anda akan muncul di Google Cloud konsol.

Mendapatkan insight dan rekomendasi

Ikuti petunjuk untuk melihat insight dan rekomendasi. Anda bisa mendapatkan insight menggunakan Google Cloud konsol. Anda juga dapat menggunakan Google Cloud CLI atau Recommender API, dengan memfilter menggunakan subjenis berikut:

EXEC_PROBE_TIMEOUT: Waktu tunggu pemeriksaan eksekusi

Untuk cluster yang memiliki rekomendasi aktif, GKE menjeda upgrade otomatis ke versi 1.35 hingga konfigurasi waktu tunggu pemeriksaan eksekusi diperbarui untuk memungkinkan operasi yang tidak mengganggu.

Memeriksa peristiwa Kubernetes menggunakan command line

Di GKE versi 1.34 dan yang lebih lama, Anda dapat memeriksa peristiwa Kubernetes di cluster secara manual untuk menemukan pemeriksaan eksekusi yang memerlukan waktu lebih lama untuk diselesaikan daripada periode waktu tunggu yang ada. Kubernetes menambahkan peristiwa dengan pesan command timed out untuk pemeriksaan ini. Metode ini berguna untuk mengidentifikasi workload yang sudah mengalami masalah karena nilai waktu tunggu yang singkat.

Untuk menemukan workload yang terpengaruh, lakukan salah satu hal berikut:

Menemukan workload di beberapa cluster menggunakan skrip
Menemukan workload di cluster tertentu menggunakan command line

Menemukan workload di beberapa cluster menggunakan skrip

Skrip bash berikut melakukan iterasi pada semua cluster yang ada di file kubeconfig Anda untuk menemukan workload yang terpengaruh. Skrip ini memeriksa error waktu tunggu pemeriksaan eksekusi di semua konteks Kubernetes yang ada dan dapat dijangkau, serta menulis temuan ke file teks bernama affected_workloads_report.txt. Untuk menjalankan skrip ini, ikuti langkah-langkah berikut:

Simpan skrip berikut sebagai 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"

Jalankan skrip:
```
bash execprobe-timeouts.sh
```

Baca konten file affected_workloads_report.txt:

cat affected_workloads_report.txt

Outputnya mirip dengan hal berikut ini:

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

Menemukan workload di cluster tertentu menggunakan command line

Untuk mengidentifikasi workload yang terpengaruh di cluster tertentu, Anda dapat menggunakan alat kubectl untuk memeriksa error waktu tunggu pemeriksaan eksekusi. Ikuti langkah-langkah berikut untuk setiap cluster GKE yang menjalankan versi 1.34 atau yang lebih lama:

Hubungkan ke cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION
```
Ganti kode berikut:
- CLUSTER_NAME: nama cluster.
- LOCATION: lokasi bidang kontrol cluster, seperti us-central1.

Periksa peristiwa yang menunjukkan bahwa pemeriksaan eksekusi memiliki error waktu tunggu:

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

Perintah ini mengabaikan workload di banyak namespace sistem. Jika ada workload yang terpengaruh, outputnya mirip dengan hal berikut ini:

Pod/liveness1-exec      Namespace: default

Ulangi langkah-langkah sebelumnya untuk setiap cluster yang menjalankan versi GKE yang lebih lama dari 1.35.

Menemukan cluster dan workload yang terpengaruh di Cloud Logging

Di Google Cloud konsol, buka halaman Logs Explorer.

Buka Logs Explorer
Untuk membuka editor kueri, klik tombol Show query.
Jalankan kueri berikut:
```
jsonPayload.message=~" probe errored and resulted in .* state: command timed out" OR jsonPayload.message=~" probe errored: command timed out"
```
Outputnya adalah daftar error pemeriksaan yang disebabkan oleh perintah yang memerlukan waktu lebih lama untuk diselesaikan daripada periode waktu tunggu yang dikonfigurasi.

Mengupdate workload yang terpengaruh sebelum mengupgrade ke 1.35

Setelah mengidentifikasi workload yang terpengaruh, Anda harus mengupdate pemeriksaan yang terpengaruh.

Tinjau pemeriksaan keaktifan, kesiapan, dan startup untuk setiap Pod yang terpengaruh dan tentukan nilai timeoutSeconds yang sesuai. Nilai ini harus cukup lama agar perintah dapat dijalankan dengan berhasil dalam kondisi normal. Untuk informasi selengkapnya, lihat Konfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Startup.

Buka file manifes untuk workload yang terpengaruh dan tambahkan atau ubah kolom timeoutSeconds untuk pemeriksaan keaktifan, kesiapan, atau startup. Misalnya, pemeriksaan keaktifan berikut memiliki nilai 10 di kolom timeoutSeconds:

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

Terapkan manifes yang diperbarui ke cluster Anda.
Periksa error dalam pemeriksaan yang diperbarui dengan mengikuti langkah-langkah di Memeriksa peristiwa Kubernetes menggunakan command line.

Setelah mengupdate dan menguji semua workload yang terpengaruh, Anda dapat mengupgrade cluster ke GKE versi 1.35.