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.

Istilah Kunci: Halaman ini menggunakan istilah probe exec untuk merujuk ke probe keaktifan, kesiapan, atau startup yang menjalankan perintah menggunakan kolom exec.command dalam spesifikasi probe.

Tentang waktu tunggu untuk pemeriksaan eksekusi

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

Pada versi GKE yang lebih lama dari 1.35, Kubernetes mengabaikan nilai di kolom timeoutSeconds untuk perintah pemeriksaan exec. 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.

Pada versi yang lebih lama dari 1.35, Kubernetes mengabaikan waktu tunggu lima detik ini dan secara keliru melaporkan probe sebagai berhasil. Di versi 1.35 dan yang lebih baru, Kubernetes akan gagal melakukan pemeriksaan dengan benar setelah lima detik.

Perilaku ini, yang membuat Kubernetes mengabaikan waktu tunggu pemeriksaan exec, dapat menyebabkan pemeriksaan berjalan tanpa batas, yang dapat menyembunyikan masalah pada aplikasi Anda atau menyebabkan perilaku yang tidak dapat diprediksi. Pada 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

Perubahan ini adalah perubahan yang menyebabkan gangguan di GKE versi 1.35 dan yang lebih baru yang diperlukan untuk stabilitas dan keandalan beban kerja 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 exec dengan salah satu properti berikut:

• Menghilangkan kolom timeoutSeconds: di versi 1.35 dan yang lebih baru, probe ini memiliki waktu satu detik untuk berhasil menyelesaikan perintah. Jika perintah tidak berhasil diselesaikan dalam satu detik, probe akan melaporkan kegagalan dengan benar.
• Tentukan periode waktu tunggu singkat: di versi 1.35 dan yang lebih baru, probe dengan periode waktu tunggu yang lebih singkat daripada waktu penyelesaian perintah akan melaporkan kegagalan dengan benar.

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

Jika Anda tidak menentukan durasi waktu tunggu yang lebih akurat dan perintah memerlukan waktu lebih lama dari periode waktu tunggu yang ada untuk diselesaikan, probe Anda 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 kehabisan waktu, Kubernetes mengasumsikan bahwa aplikasi gagal dan memulai ulang container. Jika pemeriksaan gagal berulang kali, Pod Anda mungkin terjebak dalam loop error dengan status Pod CrashLoopBackOff.
• Pemeriksaan kesiapan: jika pemeriksaan kesiapan gagal karena perintah kehabisan waktu, Kubernetes mengupdate kondisi Pod Ready dengan status False. Kubernetes tidak mengirimkan traffic apa pun ke Pod hingga probe berhasil. Jika semua Pod yang mendukung Layanan memiliki status False untuk kondisi Ready, Anda mungkin mengalami gangguan pada Layanan.
• Pemeriksaan startup: jika pemeriksaan startup gagal, Kubernetes mengasumsikan bahwa aplikasi gagal dimulai dan memulai ulang container. Jika pemeriksaan gagal berulang kali, Pod Anda mungkin terjebak dalam loop error dengan status Pod CrashLoopBackOff.

Upgrade otomatis dijeda

GKE menjeda upgrade otomatis ke versi 1.35 saat mendeteksi bahwa beban kerja dalam 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 telah mengupdate 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.

Peringatan: Saat Anda mengupgrade cluster ke versi 1.35 atau yang lebih baru, GKE akan menerapkan batas waktu dengan benar untuk pemeriksaan exec. Jika Anda mengupgrade cluster tanpa memperbarui nilai di kolom timeoutSeconds untuk pemeriksaan exec, gangguan workload mungkin terjadi.

Mengidentifikasi cluster atau workload yang terpengaruh

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

Memeriksa peristiwa Kubernetes menggunakan command line

Di GKE versi 1.34 dan yang lebih lama, Anda dapat memeriksa peristiwa Kubernetes secara manual di cluster untuk menemukan pemeriksaan exec 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 beban kerja 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 probe exec 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:

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

2. Jalankan skrip:

   bash execprobe-timeouts.sh
   

3. Baca isi 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 habis pemeriksaan eksekusi. Ikuti langkah-langkah berikut untuk setiap cluster GKE yang menjalankan versi 1.34 atau yang lebih lama:

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

2. Periksa peristiwa yang menunjukkan bahwa pemeriksaan exec mengalami 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 beban kerja yang terpengaruh, outputnya akan mirip dengan berikut ini:

   Pod/liveness1-exec      Namespace: default
   

3. Ulangi langkah-langkah sebelumnya untuk setiap cluster yang menjalankan versi GKE sebelum 1.35.

Menemukan cluster dan workload yang terpengaruh di Cloud Logging

1. Di konsol Google Cloud , buka halaman Logs Explorer.

   Buka Logs Explorer

2. Untuk membuka editor kueri, klik tombol Show query.

3. 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 probe yang disebabkan oleh perintah yang memerlukan waktu lebih lama untuk diselesaikan daripada periode waktu tunggu yang dikonfigurasi.

Perbarui workload yang terpengaruh sebelum mengupgrade ke 1.35

Praktik terbaik:

Sebelum membuat perubahan apa pun pada lingkungan produksi, uji perubahan pada probe dan dampak upgrade ke versi 1.35 di lingkungan pengembangan.

Setelah mengidentifikasi workload yang terpengaruh, Anda harus memperbarui probe yang terpengaruh.

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

2. Buka file manifes untuk beban kerja 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
   

3. Terapkan manifes yang telah diupdate ke cluster Anda.

4. Periksa apakah ada error dalam probe yang diperbarui dengan mengikuti langkah-langkah di Memeriksa peristiwa Kubernetes menggunakan command line.

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