Masalah umum GKE

Halaman ini mencantumkan masalah umum GKE. Halaman ini ditujukan untuk Admin dan arsitek yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta merespons pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal.

Halaman ini mencantumkan masalah umum untuk semua versi yang didukung dan untuk dua versi minor yang langsung mendahului versi paling awal dalam dukungan yang diperpanjang. Setelah versi mencapai akhir dukungan yang diperpanjang, semua masalah N-2 akan dihapus. Misalnya, saat versi 1.30 mencapai akhir dukungan yang diperpanjang, masalah umum yang khusus untuk versi 1.28 dan yang lebih lama akan dihapus.

Jika Anda adalah bagian dari Google Developer Program, simpan halaman ini untuk menerima notifikasi saat catatan rilis yang terkait dengan halaman ini dipublikasikan. Untuk mempelajari lebih lanjut, lihat Halaman Tersimpan.

Untuk memfilter masalah umum menurut versi atau kategori produk, pilih filter Anda dari menu drop-down berikut.

Pilih versi GKE Anda:

Pilih kategori masalah Anda:

Atau, telusuri masalah Anda:

Kategori Versi yang diidentifikasi Versi tetap Masalah dan solusinya
Upgrade dan update
  • 1.36.3-gke.1767000 dan yang lebih baru

Addon Agent Sandbox (agentsandbox) mempromosikan definisi resource kustom dan API-nya dari v1alpha1 ke v1beta1 mulai GKE versi 1.36.3-gke.1767000. Jika Anda mengupgrade cluster yang menjalankan Agent Sandbox dari versi yang lebih lama dari 1.36.3-gke.1767000 tanpa memigrasikan resource kustom, workload v1alpha1 yang ada tidak akan berfungsi dengan baik.

Solusi:

Sebelum mengupgrade bidang kontrol cluster ke 1.36.3-gke.1767000 atau yang lebih baru, migrasikan manifes dan workload Agent Sandbox Anda dari v1alpha1 ke v1beta1 dengan mengikuti Panduan migrasi Agent Sandbox v1alpha1 ke v1beta1.

Operasi
  • 1,35
  • 1,36
  • 1,37
  • 1.35.6-gke.1250001 dan yang lebih baru
  • 1.36.4-gke.1391002 dan yang lebih baru
  • 1.37.1-gke.1187000 dan yang lebih baru

Permintaan POST HTTP untuk token dari server metadata gagal dengan error 400 Bad Request

Workload yang menggunakan Workload Identity Federation for GKE untuk melakukan autentikasi ke API Google Cloud dengan meminta token akses akun layanan atau token identitas dari server metadata GKE (seperti /computeMetadata/v1/instance/service-accounts/default/token atau /computeMetadata/v1/instance/service-accounts/default/identity) mungkin gagal dengan error HTTP 400 Bad Request (INVALID_ARGUMENT).

Masalah ini terjadi saat aplikasi, library klien, atau gateway API mengirim permintaan HTTP POST tanpa rantai sertifikat yang valid dalam isi permintaan. Dalam versi GKE yang terpengaruh, permintaan POST ke endpoint token ini hanya disediakan untuk token akses dan ID terikat. Akibatnya, permintaan yang memiliki JSON kosong, berenkode formulir, atau tidak valid dalam payload akan ditolak.

Untuk memperbaiki masalah ini, upgrade ke versi patch terbaru dalam versi minor saluran rilis mana pun.

Solusi:

Untuk mengatasi masalah ini, konfigurasikan aplikasi, library klien, atau gateway API Anda untuk menggunakan metode GET, bukan POST, saat Anda meminta token akses atau ID dari server metadata, seperti dalam contoh berikut: 

curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

Jika workload Anda menggunakan SDK atau gateway pihak ketiga (seperti MuleSoft Flex Gateway, IBM App Connect, atau skrip HTTP kustom) yang secara default mengirim permintaan POST ke endpoint server metadata, perbarui konfigurasi atau library klien untuk mengirim permintaan GET.

Upgrade dan update
  • 1.33 dan yang lebih baru
 Ditentukan Nanti

Selama upgrade versi minor dua langkah untuk bidang kontrol di cluster Autopilot yang menggunakan Pod durasi yang diperpanjang, node pool baru mungkin disediakan menggunakan versi node sebelumnya. Autoscaler Cluster mengevaluasi node yang baru disediakan terhadap versi bidang kontrol yang diupgrade, mendeteksi ketidakcocokan versi, dan menerapkan taint cloud.google.com/not-target-gke-version:true. Autoscaler Cluster juga memblokir peningkatan skala node pool Pod durasi diperpanjang yang sudah ada atau yang baru dibuat, yang menggunakan versi node sebelumnya.

Perilaku ini mencegah Pod dijadwalkan dan memicu loop penskalaan tanpa batas. Alih-alih meningkatkan skala node pool yang ada, node auto-provisioning akan membuat node pool baru dengan satu node pada setiap iterasi peningkatan skala untuk mengakomodasi workload yang tertunda. Loop ini menghasilkan ratusan node pool kosong terpisah yang pada akhirnya dapat menghabiskan kuota grup instance terkelola regional.


Solusi:

Untuk menyelesaikan loop penskalaan, selesaikan upgrade bidang kontrol secara manual dengan menjalankan perintah berikut: 

gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION]

Atau, terapkan toleransi berikut ke workload yang terpengaruh agar dapat dijadwalkan pada node versi sebelumnya: 

tolerations:
- key: "cloud.google.com/not-target-gke-version"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
Operasi 1.37.0-gke.2941000 dan yang lebih baru 1.37.1-gke.1131000

Node yang memasang volume NFS mengumpulkan entri pemasangan dan berhenti membuat container

Pada node yang menjalankan versi yang terpengaruh, pemasangan volume NFS akan menyisakan entri tambahan di tabel pemasangan node. Selain itu, saat Pod yang menggunakan volume NFS dihentikan, upaya untuk melepas gagal, sehingga kubelet berulang kali mencoba melepas. Setiap percobaan ulang menambahkan lebih banyak entri ke tabel pemasangan, yang menyebabkan tabel pemasangan terus bertambah meskipun tidak ada workload baru yang dijadwalkan.

Saat tabel pemasangan mencapai batas kernel, runtime container tidak dapat lagi membuat container di node tersebut. Node berhenti menjalankan Pod baru, mungkin melaporkan status NotReady, dan mungkin dimulai ulang berulang kali. Pod yang menggunakan volume NFS mungkin tetap dalam status Terminating karena volumenya tidak dapat dilepas.

Dalam peristiwa Pod dan log kubelet, node dalam status ini melaporkan error yang mirip dengan berikut ini:

MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1
 
mount: /etc: mount(2) system call failed: No space left on device

Masalah ini memengaruhi node pool yang memasang volume NFS dengan driver NFS in-tree Kubernetes. Node yang tidak menggunakan driver NFS dalam hierarki untuk memasang volume NFS tidak akan terpengaruh.

Solusi:

Untuk memulihkan node yang terpengaruh, mulai ulang atau buat ulang node tersebut. Entri pemasangan tambahan hanya ada dalam status node yang berjalan, sehingga akan dihapus saat node dimulai ulang. Pod yang terjebak dalam status Terminating setelah mulai ulang dapat dihapus dengan perintah berikut:

kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0

Untuk mencegah masalah ini terulang di cluster Standard, downgrade node pool yang memasang volume NFS ke versi 1.36. Tetapkan pengecualian pemeliharaan agar GKE tidak otomatis mengupgrade node pool kembali ke versi yang terpengaruh.

Jika cluster Autopilot menjalankan versi yang terpengaruh, gunakan salah satu opsi berikut:

  • Jika volume NFS Anda didukung oleh Filestore, pasang volume tersebut dengan driver CSI Filestore, bukan driver NFS in-tree. Driver CSI memasang volume dari containernya sendiri dan tidak menggunakan komponen node yang terpengaruh.
  • Jika Anda harus terus menggunakan driver NFS dalam hierarki, biarkan perbaikan otomatis node memulihkan node yang terpengaruh. Cluster Autopilot memperbaiki node secara otomatis, dan node yang melaporkan status NotReady selama sekitar 10 menit akan dikosongkan dan dibuat ulang, sehingga tabel pemasangannya akan dihapus.
Upgrade 1.34.9-gke.1065000 dan yang lebih baru, 1.35.6-gke.1049000 dan yang lebih baru, serta semua versi patch 1.36 1.34.10-gke.1328000 dan yang lebih baru, 1.35.8-gke.1026000 dan yang lebih baru, 1.36.4-gke.1058000 dan yang lebih baru (belum ada perbaikan untuk 1.37)

Kegagalan workload GPU A4X Max (GB300)

Membuat atau mengupgrade node pool GKE A4X Max (a4x-maxgpu-4g-metal) pada atau ke versi patch tertentu (lihat kolom Versi yang diidentifikasi) menyebabkan kegagalan workload GPU dengan NVIDIA GB300 Grace Blackwell Ultra Superchip yang terpasang. Karena waktu booting High Bandwidth Memory (HBM) yang diperpanjang pada hardware GB300 dengan jenis mesin bare metal ini, waktu tunggu layanan startup nvidia-persistenced habis. Waktu tunggu ini menyebabkan GPU tidak diinisialisasi, dan menghasilkan pesan error cudaErrorDeviceUnavailable(46) saat Pod mencoba mengklaim resource CUDA.

Solusi:

Upgrade setiap cluster dan node pool yang terpengaruh ke versi yang diperbaiki. GKE mencegah pembuatan node pool A4X Max dengan versi yang terpengaruh, dan tidak akan otomatis mengupgrade node pool ke versi yang terpengaruh. GKE tidak mencegah upgrade manual ke versi yang terpengaruh. Namun, untuk menghindari kegagalan, sebaiknya jangan mengupgrade ke versi yang terpengaruh.

Solusi:

Jika Anda tidak dapat mengupgrade, hapus semua node pool A4X Max yang menjalankan versi yang terpengaruh, dan buat ulang node pool menggunakan versi sebelumnya yang tidak terpengaruh. Perhatikan bahwa karena kapasitas A4X Max harus diperoleh melalui pemesanan, Anda tidak akan kehilangan kapasitas apa pun dengan menghapus node pool.

Operasi Versi 1.33 sebelum 1.33.5-gke.2469000, versi 1.34 sebelum 1.34.1-gke.2037001 1.33.5-gke.2469000 dan yang lebih baru, 1.34.1-gke.2037001 dan yang lebih baru, 1.35 dan yang lebih baru

Node GPU atau TPU terjebak dengan taint impending-node-termination setelah pemeliharaan host

Pada cluster GKE dengan node akselerator (GPU atau TPU) yang menjalankan versi yang terpengaruh, node mungkin macet dengan taint cloud.google.com/impending-node-termination atau cloud.google.com/maintenance-window-started setelah pemeliharaan atau perbaikan host Compute Engine selesai. Saat instance VM dimulai lagi, pengontrol pemeliharaan GKE mungkin akan menerapkan kembali taint ini sebelum waktunya jika ada peristiwa pemeliharaan mendatang yang dijadwalkan untuk node tersebut, sehingga mencegah workload baru dijadwalkan pada node yang responsif.

Solusi:

Untuk mengatasi status macet, Anda harus menghapus label pemeliharaan aktif yang dikelola GKE dan taint secara manual dari node yang terpengaruh. Jika Anda hanya menghapus taint, pengontrol pemeliharaan GKE akan otomatis menerapkannya kembali.

Untuk menghapus label dan taint, jalankan perintah berikut:

kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest-
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination-
kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started-

Ganti NODE_NAME dengan nama node yang terpengaruh.
Operasi
  • 1,33
  • 1,34
 1.34.1-gke.1829001 dan yang lebih baru

GKE salah memberitahukan delapan chip TPU yang dapat dialokasikan untuk akselerator TPU v7 (tpu7x) dengan topologi 2x2x1, yang secara fisik hanya berisi empat chip. Ketidakcocokan pelaporan ini mencegah penjadwalan Pod untuk workload TPU v7.

Arsitektur dual-chiplet TPU v7 tidak ditangani dengan benar di versi sebelumnya, sehingga menyebabkan kegagalan penerimaan Pod. Bergantung pada resource TPU yang diminta, error berikut akan terjadi:

  • Saat meminta empat TPU (google.com/tpu: 4), `kubelet` akan menampilkan UnexpectedAdmissionError: "invalid TPU chip count request, you must request all 4 chips on this node together".
  • Saat meminta delapan TPU (google.com/tpu: 8), webhook penerimaan tpu-accelerator-topology-constraints menolak permintaan dengan error berikut: "Invalid resource requests for google.com/tpu. Nilainya harus sama dengan salah satu dari [4] untuk akselerator tpu7x dan topologi 2x2x1".

Solusi:

Untuk mengatasi masalah ini, upgrade cluster GKE ke versi 1.34.1-gke.1829001 atau yang lebih baru.

Operasi 1.35.3-gke.1234000 dan yang lebih baru Ditentukan Nanti

Klien Lustre tidak menggunakan NIC sekunder pada node multi-NIC

Pada node GKE dengan beberapa Kartu Antarmuka Jaringan (NIC), driver CSI Managed Lustre diaktifkan secara default untuk menggunakan semua NIC yang tersedia guna menggabungkan bandwidth dengan menyebarkan traffic penyimpanan TCP ke seluruh antarmuka jaringan. Namun, karena masalah umum, klien Lustre mulai dari versi 2.14.0_p249 mungkin tidak menggunakan NIC sekunder. Sebagai gantinya, semua traffic penyimpanan TCP ke instance Managed Lustre dirutekan secara eksklusif melalui NIC utama, sehingga mencegah agregasi bandwidth dan membatasi throughput penyimpanan.

Solusi:

Jika workload Anda memerlukan agregasi bandwidth multi-NIC untuk Managed Lustre, downgrade node pool Anda ke versi GKE sebelum 1.35.3-gke.1234000, seperti 1.35.2-gke.1842000.
Operasi 1.35 dan yang lebih baru Ditentukan Nanti

Waktu tunggu koneksi habis atau koneksi ditolak untuk alur yang dialihkan ke server metadata GKE

Di GKE versi 1.35 dan yang lebih baru, workload yang menggunakan Workload Identity untuk melakukan autentikasi ke Google Cloud API mungkin mengalami waktu tunggu konektivitas sementara atau koneksi yang ditolak ke server metadata GKE segera setelah startup node.

Solusi:

Untuk rekomendasi dan solusi, lihat memecahkan masalah error waktu tunggu saat memulai Pod.
Operasi 1.33.8-gke.1026000 dan yang lebih baru 1.35.1 dan yang lebih baru

Shim gVisor gagal melakukan pembersihan, mencatat error "runsc: executable file not found in $PATH" ke dalam log

Setiap kali Pod gVisor keluar atau dihentikan karena OOM, containerd akan mencoba menghapus sandbox. Namun, proses pembersihan terkadang gagal, sehingga mencatat error exec: "runsc": executable file not found in $PATH. Error ini dapat menyebabkan masalah seperti kehabisan resource, penurunan kualitas jaringan, kepanikan NodeLocalDNS, waktu tunggu DNS habis, atau latensi tinggi saat membuat Pod.

Solusi:

Upgrade node GKE ke versi 1.35.1 atau yang lebih baru. Untuk cluster Standard, upgrade node pool dengan node yang terpengaruh. Untuk cluster Autopilot, upgrade cluster Autopilot secara manual ke versi 1.35.1 atau yang lebih baru, dan GKE akan otomatis mengupgrade node Anda agar sesuai dengan versi bidang kontrol sesegera mungkin.

Solusi:

Jika Anda tidak dapat mengupgrade cluster, lakukan salah satu tindakan berikut:

  • Tinjau dan tingkatkan permintaan dan batas memori untuk pod gVisor.
  • Deploy DaemonSet dengan hak istimewa berikut untuk menyalin biner runsc dari /home/containerd/usr/local/sbin ke /home/kubernetes/bin:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: runsc-path
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: runsc-path
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: runsc-path
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor
      volumes:
      - name: host
        hostPath:
          path: /
      initContainers:
      - name: copy-runsc
        image: bash
        command:
        - /usr/local/bin/bash
        - -c
        - |
          set -euo pipefail
          cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin
          chmod a+rx /host/home/kubernetes/bin/runsc
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: 5Mi
            cpu: 5m
        securityContext:
          privileged: true
      containers:
      - image: gcr.io/google-containers/pause:3.2
        name: pause
Operasi 1.35.0-gke.2232000 dan yang lebih baru 1.35.3-gke.1.35.3-gke.1290000 dan yang lebih baru

Volume dinamis beralih ke jenis disk default

Workload yang menggunakan volume dinamis di GKE versi 1.35.0-gke.2232000 atau yang lebih baru mungkin gagal dijadwalkan atau dipasang. Masalah ini juga dapat menyebabkan volume disediakan menggunakan hd-type pengganti (seperti hyperdisk-balanced), bukan pd-type, bahkan pada node yang tidak mendukung Hyperdisk.

Hal ini terjadi karena server Node PDCSI gagal mengisi objek CSINode dengan topologi jenis disk yang didukung. Akibatnya, pengontrol tidak memiliki informasi topologi yang diperlukan untuk mencocokkan volume dengan node yang kompatibel.

Solusi:

Upgrade ke 1.35.3-gke.1290000 atau yang lebih baru.
Upgrade dan update
  • Semua versi patch sebelum 1.34.3-gke.1208000 untuk GKE 1.34
  • Semua versi patch sebelum 1.35.0-gke.2232000 untuk GKE 1.35
  • 1.34.3-gke.1208000 untuk GKE 1.34
  • 1.35.0-gke.2232000 untuk GKE 1.35

Masalah startup pod selama upgrade ke GKE 1.35 untuk cluster GKE Dataplane V2

Cluster yang mengupgrade bidang kontrol ke GKE versi 1.35.0-gke.2232000 dan yang lebih baru dari versi

  • lebih lama dari 1.34.3-gke.1208000 untuk GKE 1.34
  • lebih lama dari 1.35.0-gke.2232000 untuk GKE 1.35
mungkin mengalami masalah startup Pod untuk workload baru yang dibuat selama peluncuran DaemonSet anetd.

Workload baru akan gagal dimulai selama peluncuran anetd jika dijadwalkan pada node dengan anetd yang sudah tidak berlaku. Selama peluncuran, Anda mungkin melihat pesan error berikut:

Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

Hal ini terjadi karena GKE menggunakan Operator identity-management-mode yang mengharuskan semua agen dan operator memiliki tampilan label yang relevan dengan identitas yang disinkronkan. Mulai GKE 1.35.0-gke.2232000, label topology.kubernetes.io dikecualikan dari set yang relevan dengan identitas untuk mencegah duplikasi identitas. Perubahan ini menyebabkan ketidakcocokan konfigurasi sementara antara bidang kontrol yang diupgrade dan agen anetd yang sudah tidak berlaku selama peluncuran. Untuk mengetahui informasi selengkapnya, lihat PR Cilium.

Solusi:

  • Untuk GKE 1.34 sebelum 1.34.3-gke.1208000: upgrade terlebih dahulu ke 1.34.3-gke.1208000 atau yang lebih baru, lalu upgrade ke 1.35.0-gke.2232000 atau yang lebih baru
  • Untuk GKE 1.35 sebelum 1.35.0-gke.2232000: setelah mengupgrade, tunggu hingga peluncuran anetd selesai. Untuk mempercepat peluncuran secara manual, hapus Pod anetd yang sudah tidak berlaku. Hal ini akan memastikan bahwa operator dan agen node anetd memiliki tampilan yang disinkronkan dari label yang relevan dengan identitas.
Upgrade dan update
  • 1,32
  • 1,33
  • 1,34
  • 1,35
  • 1.32.11-gke.1153001 dan yang lebih baru
  • 1.33.5-gke.2326000 dan yang lebih baru
  • 1.34.3-gke.1214000 dan yang lebih baru
  • 1.35.0-gke.2180000 dan yang lebih baru

Pada cluster GKE dengan kebijakan jaringan Calico yang diaktifkan, regresi dalam versi yang terpengaruh dapat menyebabkan penundaan yang signifikan dalam penjadwalan Pod pada node baru atau yang dibuat ulang. Penundaan ini dapat menyebabkan node tetap dalam status NotReady untuk waktu yang lama.

Masalah ini disebabkan oleh skrip startup CNI Calico yang salah memformat URL server Kubernetes API untuk alamat IPv4 dengan menyertakannya dalam tanda kurung siku ([]). Pendekatan ini menyebabkan error penguraian URL saat membuat sandbox Pod baru, yang terlihat di log `kubelet`:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443"


Solusi:

Versi komponen Calico ditentukan oleh versi bidang kontrol cluster. Untuk mengurangi masalah ini, upgrade bidang kontrol cluster Anda ke salah satu versi yang telah diperbaiki. Setelah mengupgrade bidang kontrol, Anda harus membuat ulang node di node pool untuk memastikan node tersebut menggunakan format URL server Kubernetes API yang benar. Anda dapat melakukannya dengan melakukan upgrade langsung pada node pool ke versi yang sama atau lebih baru, atau dengan membuat ulang node pool secara manual.

Performa
  • 1.32.8-gke.1134000 dan yang lebih baru untuk GKE 1.32
  • 1.33.3-gke.1392000 dan yang lebih baru untuk GKE 1.33
  • Semua versi patch untuk GKE 1.34 dan 1.35
  • 1.32.11-gke.1075000 dan yang lebih baru untuk GKE 1.32
  • 1.33.5-gke.2392000 dan yang lebih baru untuk GKE 1.33
  • 1.34.3-gke.1318000 dan yang lebih baru untuk GKE 1.34
  • 1.35.0-gke.2398000 dan yang lebih baru untuk GKE 1.35

Performa jaringan tujuan umum menurun pada jenis mesin GPU seri A dan G4

Cluster GKE dengan node GPU seri A dan G4 menunjukkan penurunan performa untuk jaringan tujuan umum di GKE 1.32.8-gke.1134000 dan yang lebih baru untuk GKE 1.32, serta di GKE 1.33.3-gke.1392000 dan yang lebih baru. Penurunan performa pada jaringan tujuan umum memengaruhi jenis mesin GPU, termasuk seri mesin A3, seri mesin A4, seri mesin A4X, dan seri mesin G4. Perhatikan bahwa GPUDirect-TCPXO di A3 Mega dan GPUDirect-RDMA di A3 Ultra, A4, dan A4X tidak terpengaruh.

Hal ini terjadi karena skrip level node (/usr/bin/google_set_multiqueue) yang menetapkan afinitas interupsi tidak dikonfigurasi dengan benar.

Solusi:

Upgrade setiap node pool yang terpengaruh ke versi yang telah diperbaiki.
Performa
  • 1.32.8-gke.1134000 dan yang lebih baru untuk GKE 1.32
  • 1.33.3-gke.1392000 dan yang lebih baru untuk GKE 1.33 dan yang lebih baru
  • 1.32.11-gke.1075000 dan yang lebih baru untuk GKE 1.32
  • 1.33.5-gke.2392000 dan yang lebih baru untuk GKE 1.33

Performa GPUDirect-TCPX menurun di A3 High

Cluster GKE dengan node A3 High (a3-highgpu-8g) menunjukkan penurunan performa saat menggunakan GPUDirect-TCPX di GKE 1.32.8-gke.1134000 dan yang lebih baru untuk GKE 1.32, serta di GKE 1.33.3-gke.1392000 dan yang lebih baru.

Hal ini terjadi karena skrip level node (/usr/bin/google_set_multiqueue) yang menetapkan afinitas interupsi tidak dikonfigurasi dengan benar.

Solusi:

Untuk node pool GKE 1.32, upgrade versi node pool GKE ke 1.32.11-gke.1075000 atau yang lebih baru. Untuk nodepool GKE 1.33 dan yang lebih baru, upgrade versi nodepool GKE ke 1.33.5-gke.2392000 atau yang lebih baru.1392000. Untuk node pool GKE 1.34, lihat GPUDirect-TCPX tidak tersedia dengan A3 High untuk GKE versi 1.34 dan yang lebih baru.
Upgrade 1,35

1.35.0-gke.2232000 dan yang lebih baru.

Duplikasi identitas Cilium di cluster GKE Dataplane V2

Cluster GKE yang menjalankan versi 1.35 dengan GKE Dataplane V2 diaktifkan mungkin mengalami peningkatan jumlah resource kustom ciliumidentities.cilium.io. Masalah ini disebabkan oleh label topology.kubernetes.io yang ditambahkan ke Pod di Kubernetes 1.35, yang menghasilkan identitas Cilium tambahan untuk setiap zona tempat Pod dari workload dijadwalkan.

Di cluster Regional dan Zona, menjadwalkan workload baru dapat menyebabkan duplikasi identitas Cilium sementara. Duplikasi ini terjadi karena Pod mendapatkan satu identitas pada waktu pembuatan berdasarkan label awal, dan identitas lain setelah label topologi ditambahkan saat Pod dijadwalkan ke node. Di cluster Regional, jumlah identitas mungkin juga meningkat dengan faktor yang sebanding dengan jumlah zona yang dicakup cluster.

Dampak:

Jika jumlah total identitas melebihi 65.535, workload baru mungkin gagal dijadwalkan.

Solusi:

Untuk membatasi jumlah total identitas, hindari menambahkan label dengan sejumlah besar nilai unik ke Pod Anda.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi Cilium berikut:

Upgrade manual harus dilakukan dari versi 1.34.3-gke.1208000 dan yang lebih baru. Jika Anda memulai upgrade dari versi yang lebih lama dari 1.34.3-gke.1208000, Anda mungkin mengalami masalah sementara pada penjadwalan Pod selama proses upgrade.
Upgrade
  • Versi patch 1.34 sebelum 1.34.5-gke.1153000
  • Versi patch 1.35 sebelum 1.35.2-gke.1485000
  • 1.34.5-gke.1153000 dan yang lebih baru
  • 1.35.2-gke.1485000 dan yang lebih baru
  • 1.36 dan yang lebih baru

Anda juga harus menggunakan penginstal GPUDirect-TCPX versi 3.1.9 atau yang lebih baru dan sidecar versi 2.0.12 atau yang lebih baru. Versi penginstal dan sidecar memiliki pemetaan satu-ke-satu dan harus sesuai. Misalnya, penginstal GPUDirect-TCPX versi 3.1.12 sesuai dengan sidecar versi 2.0.15. Untuk mengetahui informasi selengkapnya tentang versi penginstal dan sidecar, lihat Catatan Rilis GPUDirect-TCPX.

GPUDirect-TCPX tidak tersedia dengan A3 High untuk versi GKE tertentu

Cluster GKE dengan node A3 High (a3-highgpu-8g) menggunakan GPUDirect-TCPX untuk memaksimalkan bandwidth jaringan GPU. Untuk node yang menggunakan TCPX dan A3 High, mengupgrade ke versi GKE yang terpengaruh dapat menyebabkan masalah fungsional atau performa pada TCPX. Hal ini karena TCPX tidak kompatibel dengan kernel Linux 6.12 yang diupdate, yang digunakan oleh Container-Optimized OS milestone 125 atau yang lebih baru. Milestone 125 digunakan oleh GKE versi 1.34.

Jenis mesin GPU A3 High lainnya (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) dan seri mesin GPU lainnya tidak terpengaruh karena tidak mendukung GPUDirect-TCPX.

Solusi:

Upgrade ke patch versi GKE yang telah diperbaiki untuk menyelesaikan masalah ini. Untuk mengetahui detail tentang cara mengonfigurasi dan mengupgrade node pool dengan GPUDirect-TCPX, lihat Memaksimalkan bandwidth jaringan GPU di cluster Standard atau Memaksimalkan bandwidth jaringan GPU di cluster Autopilot.

Saat menjalankan pengujian NCCL pada versi tetap, Anda mungkin melihat peringatan berikut yang tidak berdampak pada performa atau fungsi:

  • Log NCCL WARN untuk Rx Ctrl Timeouts: pesan ini dapat muncul jika workload memposting operasi komunikasi Recv pada target jauh lebih awal daripada memposting operasi komunikasi Send pada inisiator. Tidak ada dampak yang diperkirakan terhadap performa.
  • Log NCCL WARN untuk No free space for recv task: pesan ini memperingatkan jumlah total tugas jaringan yang rendah untuk memproses operasi, yang mengakibatkan semua tugas terisi untuk sementara. Tidak ada dampak yang diperkirakan pada performa.
Operasi Semua versi sebelum 1.34.0-gke.2285000 1.34.0-gke.2285000 dan yang lebih baru

Kapasitas instance minimum yang diperbarui

Kapasitas minimum untuk instance Managed Lustre telah diperbarui menjadi 9.000 GiB. Cluster yang menjalankan versi sebelum 1.34.0-gke.2285000 tidak dapat membuat instance dengan kapasitas minimum ini melalui driver CSI Managed Lustre.

Solusi:

Upgrade versi cluster Anda ke 1.34.0-gke.2285000 atau yang lebih baru untuk mengaktifkan pembuatan instance Managed Lustre dengan kapasitas minimum 9.000 GiB.
Operasi Semua versi Ditentukan Nanti

UI konsolGoogle Cloud menjadi tidak dapat diedit selama perbaikan otomatis node

Saat node GKE sedang menjalani perbaikan otomatis, node pool tidak dapat diedit melalui konsol Google Cloud karena operasi yang sedang berlangsung.

Solusi:

Anda masih dapat mengedit konfigurasi node pool menggunakan perintah gcloud CLI.
Operasi Versi 1.33 sebelum 1.33.4-gke.1036000 1.33.4-gke.1036000 dan yang lebih baru

Tingkat performa yang salah untuk instance Lustre yang disediakan secara dinamis

Saat menyediakan instance Lustre secara dinamis, pembuatan instance akan gagal dengan error InvalidArgument untuk PerUnitStorageThroughput, terlepas dari nilai perUnitStorageThroughput yang ditentukan dalam permintaan API.

Solusi:

Upgrade cluster GKE ke versi 1.33.4-gke.1036000 atau yang lebih baru. Jika menggunakan saluran Stabil, versi yang lebih baru mungkin belum tersedia. Dalam hal ini, Anda dapat memilih versi secara manual dari saluran Regular atau Rapid yang menyertakan perbaikan.
Operasi
  • 1.32.3-gke.1099000 dan yang lebih baru
  • 1,33
 1.33.3-gke.1266000 dan yang lebih baru

Error input/output saat mengganti nama atau memindahkan file menggunakan driver CSI Cloud Storage FUSE

Saat menggunakan versi driver CSI Cloud Storage FUSE yang terpengaruh, penggantian nama atau pemindahan file di bucket Cloud Storage mungkin gagal dengan error I/O.

Solusi:

Tambahkan definisi image file bantuan tertentu ke manifes Pod Anda untuk sementara. Di bagian spec.containers manifes Pod, tambahkan definisi container berikut dengan image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2.

    # Add the following block to use the fixed sidecar image
    - name: gke-gcsfuse-sidecar
      image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2

Untuk mengetahui informasi selengkapnya, lihat manifes Pod di Mengonfigurasi image pribadi untuk container sidecar.

Setelah mengupgrade cluster ke versi GKE yang diperbaiki atau yang lebih baru, Anda harus menghapus seluruh blok gke-gcsfuse-sidecar dari manifes. Setelah menghapus blok ini, GKE akan melanjutkan untuk otomatis memasukkan dan mengelola image sidecar yang benar untuk versi cluster yang diupgrade.
Logging dan pemantauan Semua versi Ditentukan Nanti

Kondisi race di DaemonSet gke-metrics-agent

Saat Anda menambahkan label cloud.google.com/gke-metrics-agent-scaling-level ke node pool untuk meningkatkan alokasi memori DaemonSet gke-metrics-agent secara manual, kondisi race terjadi di DaemonSet selama pembuatan node baru. Kondisi race ini menyebabkan mulai ulang yang tidak teratur dan dapat menyebabkan hilangnya metrik.

Masalah ini terjadi karena ada penundaan sebelum label ditambahkan ke node baru di node pool. Selama penundaan ini, DaemonSet akan membuat Pod dengan alokasi memori asli pada node tersebut. Setelah label diterapkan, DaemonSet akan membuat Pod yang memiliki alokasi memori baru. Pod yang ada tidak sepenuhnya dihapus saat Pod yang diupdate dimulai. Kedua Pod ini mencoba mengikat ke nomor port yang sama.

Solusi:

Setelah Anda menambahkan label cloud.google.com/gke-metrics-agent-scaling-level ke node pool, mulai ulang DaemonSet gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Upgrade 1,33 1.33.2-gke.1043000

Batas file terbuka yang lebih rendah dengan containerd 2.0

Untuk node pool yang menjalankan GKE versi 1.33, yang menggunakan containerd 2.0, batas ringan default untuk file terbuka (ulimit -n) untuk container diturunkan menjadi 1024.

Ini adalah perubahan pada containerd itu sendiri (lihat PR containerd #8924) saat LimitNOFILE dihapus dari containerd.service sebagai praktik terbaik, sehingga batas minimum sistem default berlaku.

Workload yang mengharapkan batas sementara default yang lebih tinggi (misalnya, workload yang secara implisit mengandalkan batas default yang lebih tinggi sebelumnya) mungkin mengalami kegagalan, seperti error Too many open files.

Solusi:

Upgrade dari versi patch 1.33 yang lebih lama ke 1.33.2-gke.1043000 atau yang lebih baru.

Solusi:

Tingkatkan batas file yang dapat dibuka untuk workload Anda menggunakan salah satu metode berikut:

  • Penyesuaian Tingkat Aplikasi: Ubah kode aplikasi atau konfigurasi aplikasi untuk menetapkan ulimit -n atau prlimit --nofile=524288 secara eksplisit.
  • Plugin Penyesuai Ulimit NRI Containerd Gunakan plugin containerd/nri ulimit-adjuster untuk menyesuaikan ulimit.
  • Downgrade node pool (khusus Standard): Untuk cluster GKE Standard, Anda dapat melakukan downgrade node pool untuk sementara ke versi 1.32 guna menghindari masalah ini hingga resolusi permanen tersedia.
Untuk mengetahui informasi selengkapnya tentang migrasi ke containerd 2, lihat Memigrasikan node ke containerd 2.
Upgrade 1.31.5-gke.1169000, 1.32.1-gke.1376000 1.31.7-gke.1164000, 1.32.3-gke.1512000

CRD status.storedVersions tidak valid untuk CRD terkelola

Beberapa CRD yang dikelola GKE mungkin memiliki kolom status.storedVersions yang tidak valid, sehingga menimbulkan risiko terganggunya akses ke objek CRD setelah upgrade.

Masalah ini memengaruhi cluster yang memiliki kedua karakteristik berikut:

  • Cluster yang menggunakan versi GKE yang terpengaruh pada suatu waktu.
  • Cluster yang memiliki versi objek CRD yang tidak didukung (served=false) yang disimpan di etcd.

Solusi:

Solusi yang direkomendasikan adalah menunda upgrade cluster hingga masalah terselesaikan.

Atau, jika Anda tahu bahwa cluster Anda berisi versi objek CRD yang tidak didukung, Anda dapat menambahkan versi ini ke kolom status.storedVersions menggunakan perintah kubectl patch.
Operasi, logging, dan pemantauan 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000
  • 1.32.2-gke.1652003 atau yang lebih baru
  • 1.31.6-gke.1221001 atau yang lebih baru
  • 1.30.10-gke.1227001 atau yang lebih baru

Metrik tidak ada atau autoscaler workload tidak melakukan penskalaan

Anda mungkin mengamati kesenjangan dalam data metrik pada versi yang terpengaruh setelah ukuran cluster bertambah lebih dari lima node. Masalah ini mungkin juga memengaruhi operasi penskalaan otomatis.

Masalah ini hanya memengaruhi cluster yang diupgrade ke versi yang terpengaruh. Cluster yang baru dibuat akan berfungsi seperti yang diharapkan.

Solusi:

Jika Anda terpengaruh, Anda dapat mendowngrade satu versi patch atau mengupgrade ke versi yang lebih baru dan telah diperbaiki.
Operasi

Batas ukuran dan lampiran Google Cloud Hyperdisk

Biasanya, pod yang tidak dapat dijadwalkan karena batas lampiran volume node akan memicu penyediaan otomatis node baru. Saat menjalankan workload yang menggunakan produk Hyperdisk yang dijadwalkan ke node yang menjalankan VM C3, node auto-provisioning tidak akan terjadi dan pod akan dijadwalkan ke node yang sudah penuh.

Workload dijadwalkan ke node meskipun tidak ada lampiran disk yang tersedia. Workload juga gagal dimulai, karena error seperti berikut:

 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17]

Masalah ini terjadi pada semua produk Hyperdisk di mesin C3.

Batas pemasangan Hyperdisk bervariasi menurut jumlah vCPU VM dan produk Hyperdisk. Untuk mengetahui informasi selengkapnya, lihat Batas performa Hyperdisk.

Solusi:

Produk Google Cloud Hyperdisk memicu penyediaan otomatis pada bentuk VM lainnya. Sebaiknya gunakan bentuk yang hanya mendukung Google Cloud Hyperdisk.
Operasi 1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000

gke-metadata-server mengalami OOMKilled di node TPU/GPU

Pada node TPU GKE (misalnya ct4p-hightpu-4t) dan node GPU (misalnya a3-highgpu-8g), kernel mungkin menghentikan gke-metadata-server dengan OOMKilled saat penggunaan memori server melebihi 100 MB.

Solusi:

Jika Anda mengamati peristiwa OOMKilled untuk gke-metadata-server di node TPU atau GPU, hubungi tim on-call GKE Identity (ID Komponen: 395450) untuk mengetahui opsi mitigasi.

Operasi
  • 1.32.0-gke.1358000 hingga 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000
  • 1.33.0-gke.0 hingga 1.33.0-gke.1552000
  • 1.32.4-gke.1353003 dan yang lebih baru
  • 1.33.0-gke.1552000 dan yang lebih baru

Pengubahan ukuran volume mungkin terhenti karena status NodePendingResize yang menggantung pada PVC.

Cluster pada versi 1.32 yang memiliki node pada versi 1.31 atau yang lebih lama akan gagal mengupdate status PersistentVolumeClaim selama pengubahan ukuran. Status yang salah ini mencegah operasi pengubahan ukuran berikutnya dimulai, sehingga secara efektif mencegah pengubahan ukuran lebih lanjut.

PVC dalam status ini memiliki kolom status.allocatedResourceStatuses yang berisi NodePendingResize atau kolom status.allocatedResources dan status.conditions.type: FileSystemResizePending.

Jika PVC dibuat saat cluster Anda berada dalam versi yang terpengaruh, Anda mungkin melihat masalah ini berlanjut setelah cluster diupgrade ke versi yang diketahui telah diperbaiki. Dalam skenario ini, PVC Anda perlu di-patch untuk menghapus kolom status.allocatedResources dengan solusi satu kali.

Solusi:

PVC yang macet karena status menggantung dapat di-patch untuk menghapus status tersebut. Anda dapat menggunakan perintah patch seperti berikut untuk menghapus status menggantung:

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'
 
kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
Operasi
  • 1.32.4-gke.1236007, 1.32.4-gke.1353001
  • 1.32.4-gke.1353003 dan yang lebih baru

Driver PDCSI mungkin mencatat log secara berlebihan

Cluster GKE pada versi 1.32 tertentu mungkin memunculkan pesan log yang berlebihan dari driver PDCSI. Logging berlebih ini akan menggunakan kuota Write API Cloud Logging.

Solusi:

Anda dapat mengurangi logging yang berlebihan ini dengan menambahkan filter pengecualian. Untuk mengecualikan pesan log agar tidak diserap ke dalam Cloud Logging, gunakan kueri berikut: 

      resource.type="k8s_container"
      resource.labels.container_name="gce-pd-driver"
      (sourceLocation.file="cache.go" OR "Cannot process volume group")
Operasi
  • 1.27.16-gke.2440000 dan yang lebih baru
  • 1.28.15-gke.1673000 dan yang lebih baru
  • 1.29.13-gke.1038000 dan yang lebih baru
  • 1.30.9 dan yang lebih baru
  • 1.31.7 dan yang lebih baru
  • 1.32.1-gke.1357001 dan yang lebih baru
  • 1.27.16-gke.2691000 dan yang lebih baru
  • 1.28.15-gke.2152000 dan yang lebih baru
  • 1.29.15-gke.1218000 dan yang lebih baru
  • 1.30.11-gke.1190000 dan yang lebih baru
  • 1.31.7-gke.1363000 dan yang lebih baru
  • 1.32.4-gke.1106000 dan yang lebih baru
  • 1.33.0-gke.1552000 dan yang lebih baru

Pod yang mencoba memasang persistent volume NFS pada node COS yang sebelumnya memiliki pemasangan Hanya Baca (RO) hanya akan dipasang dalam mode RO

Untuk GKE versi 1.27 dan yang lebih baru, volume NFS yang menggunakan driver CSI in-tree Kubernetes hanya dapat memasang volume persisten dalam mode RO setelah pemasangan RO sebelumnya pada node yang sama.

Solusi:

Downgrade node pool ke versi yang lebih lama dari versi yang terpengaruh
Operasi
  • Versi 1.32 dari 1.32.1-gke.1357001 hingga, tetapi tidak termasuk, 1.32.4-gke.1106000
  • Semua versi 1.33 sebelum 1.33.0-gke.1552000
  • Rilis 1.32: 1.32.4-gke.1106000 dan yang lebih baru
  • Rilis 1.33: 1.33.0-gke.1552000 dan yang lebih baru

Pod yang mencoba memasang volume persisten NFS pada node Ubuntu tidak akan dapat berjalan.

Untuk GKE versi 1.32 dan yang lebih baru, volume NFS yang menggunakan driver CSI in-tree Kubernetes tidak akan dapat memasang volume persisten di node Ubuntu. Jika hal ini terjadi, Anda mungkin melihat pesan error berikut:

"MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1"
 
Output: Mount failed: mount failed: exit status 127
 
"Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes"

Selain melihat pesan error ini, Pod yang menggunakan volume ini tidak akan dapat muncul.

Solusi:

Downgrade node pool ke versi 1.31.
Operasi >= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1369000
  • 1.28.15-gke.1668000 atau yang lebih baru
  • 1.29.13-gke.1028000 atau yang lebih baru
  • 1.30.8-gke.1287000 atau yang lebih baru
  • 1.31.6-gke.1020000 atau yang lebih baru
  • 1.32.1-gke.1369000 atau yang lebih baru

Pod yang menggunakan syscall terkait io_uring mungkin memasuki status D (disk sleep), yang juga disebut TASK_UNINTERRUPTIBLE, karena bug di kernel Linux. Proses dalam status D tidak dapat diaktifkan oleh sinyal, termasuk SIGKILL.

Jika Pod terpengaruh oleh masalah umum ini, containernya mungkin gagal dihentikan secara normal. Dalam log containerd, Anda mungkin melihat pesan berulang yang mirip dengan berikut ini: Kill container [container-id] yang menunjukkan bahwa sistem berulang kali mencoba menghentikan container.
Secara bersamaan, log kubelet menampilkan pesan error, seperti berikut:

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

atau

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

Gejala ini menunjukkan proses dalam container yang terjebak dalam status tidur yang tidak dapat diinterupsi (status D), sehingga Pod tidak dapat dihentikan dengan benar.

Workload yang menggunakan io_uring secara langsung, atau yang menggunakan io_uring secara tidak langsung melalui runtime bahasa seperti NodeJS, mungkin terpengaruh oleh masalah umum ini. Workload yang terpengaruh memiliki proses dalam status D (disk sleep) di file /proc/<pid>/state, dan menampilkan string io_uring sebagai bagian dari konten /proc/<pid>/stack. Workload NodeJS mungkin dapat menonaktifkan penggunaan io_uring melalui UV_USE_IO_URING=0.

Solusi:

Upgrade node cluster ke versi yang telah diperbaiki atau yang lebih baru.
Operasi 1.28, 1.29, 1.30, 1.31
  • 1.30.8-gke.1261000 dan yang lebih baru
  • 1.31.4-gke.1183000 dan yang lebih baru
  • 1.32.0-gke.1448000 dan yang lebih baru

Workload yang menggunakan streaming Image gagal dengan error autentikasi

Bug dalam fitur streaming Image dapat menyebabkan workload gagal saat serangkaian kondisi tertentu terpenuhi saat container membaca file. Pesan error terkait kegagalan autentikasi mungkin terlihat di log gcfsd.

Untuk memeriksa apakah Anda terpengaruh, telusuri log dengan kueri penelusuran ini: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

Adanya error ini menunjukkan bahwa node terpengaruh.

Jika Anda terpengaruh oleh masalah ini, Anda dapat mengupgrade node pool ke versi GKE yang telah di-patch.

Operasi
  • 1.30.0 hingga 1.30.5-gke.1443001
  • 1.31.0 hingga 1.31.1-gke.1678000
  • 1.30.5-gke.1628000 dan yang lebih baru
  • 1.31.1-gke.1846000 dan yang lebih baru

Peningkatan rasio penghapusan Pod di GKE versi 1.30 dan 1.31

Beberapa versi GKE 1.30 dan GKE 1.31 yang masing-masing menggunakan COS 113 dan COS 117, memiliki kernel yang di-build dengan opsi CONFIG_LRU_GEN_ENABLED=y. Opsi ini mengaktifkan fitur kernel Multi-Gen LRU, yang menyebabkan kubelet salah menghitung penggunaan memori dan dapat menyebabkan kubelet mengeluarkan Pod.

Opsi konfigurasi CONFIG_LRU_GEN_ENABLED dinonaktifkan di cos-113-18244-151-96 dan cos-117-18613-0-76.

Anda mungkin tidak selalu melihat tingkat pengosongan Pod yang tidak biasa karena masalah ini bergantung pada pola penggunaan memori workload. Ada risiko yang lebih tinggi bahwa kubelet akan mengeluarkan Pod untuk workload yang belum menetapkan batas memori di kolom resource. Hal ini karena workload mungkin meminta lebih banyak memori daripada yang dilaporkan kubelet sebagai tersedia.

Jika Anda melihat penggunaan memori aplikasi yang lebih tinggi setelah mengupgrade ke versi GKE yang disebutkan tanpa perubahan lain, Anda mungkin terpengaruh oleh opsi kernel.

Untuk memeriksa apakah ada tingkat pengeluaran Pod yang tidak biasa, analisis metrik berikut dengan Metrics Explorer: kubernetes.io/container_memory_used_bytes dan kubernetes.io/container_memory_request_bytes

Anda dapat menggunakan kueri PromQL berikut. Ganti nilai untuk cluster_name, namespace_name, metadata_system_top_level_controller_type, dan metadata_system_top_level_controller_name dengan nama dan jenis workload yang ingin Anda analisis:

max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

Jika Anda melihat lonjakan yang tidak biasa dalam penggunaan memori yang melebihi memori yang diminta, workload mungkin akan lebih sering dikeluarkan.

Solusi

Jika Anda tidak dapat mengupgrade ke versi yang diperbaiki dan jika Anda menjalankan di lingkungan GKE tempat Anda dapat men-deploy Pod dengan hak istimewa, Anda dapat menonaktifkan opsi LRU Multi-Gen menggunakan DaemonSet.

  1. Update node pool GKE tempat Anda ingin menjalankan DaemonSet dengan anotasi untuk menonaktifkan opsi Multi-Gen LRU. Misalnya, disable-mglru: "true".
  2. Perbarui parameter nodeSelector dalam manifes DaemonSet dengan anotasi yang sama dengan yang Anda gunakan di langkah sebelumnya. Misalnya, lihat file disable-mglru.yaml di repositori GoogleCloudPlatform/k8s-node-tools.
  3. Deploy DaemonSet ke cluster Anda.

Setelah DaemonSet berjalan di semua node pool yang dipilih, perubahan akan segera berlaku dan penghitungan penggunaan memori kubelet akan kembali normal.

Operasi 1.28, 1.29, 1.30, 1.31
  • 1.28.14-gke.1175000 dan yang lebih baru
  • 1.29.9-gke.1341000 dan yang lebih baru
  • 1.30.5-gke.1355000 dan yang lebih baru
  • 1.31.1-gke.1621000 dan yang lebih baru

Pod macet dalam status Terminating

Bug dalam runtime container (containerd) dapat menyebabkan Pod dan container terjebak dalam status Terminating dengan error yang serupa dengan berikut:

OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

Jika Anda terkena dampak masalah ini, Anda dapat mengupgrade node ke versi GKE dengan versi containerd yang telah diperbaiki.

Operasi
  • 1.34 dan yang lebih lama
  • Versi 1.35 sebelum 1.35.6-gke.1005000
  • Versi 1.36 sebelum 1.36.0-gke.2459000
  • 1.35.6-gke.1005000 dan yang lebih baru
  • 1.36.0-gke.2459000 dan yang lebih baru

Bug pada fitur Streaming image dapat menyebabkan container gagal dimulai.

Container yang berjalan di node dengan streaming image diaktifkan pada versi GKE tertentu mungkin gagal dibuat dengan error berikut:

"CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"

Solusi:

Untuk mengatasi masalah ini, upgrade node pool Anda ke versi yang telah diperbaiki (1.35.6-gke.1005000 atau yang lebih baru, atau 1.36.0-gke.2459000 atau yang lebih baru).

Jika tidak dapat mengupgrade, Anda dapat memeriksa lapisan kosong atau lapisan duplikat. Jika Anda tidak dapat menghapus lapisan kosong atau lapisan duplikat, nonaktifkan streaming Image.

Operasi 1.27,1.28,1.29
  • 1.28.9-gke.1103000 dan yang lebih baru
  • 1.29.4-gke.1202000 dan yang lebih baru
  • 1.30: Semua versi

Streaming image gagal karena file tidak ada

Bug dalam fitur Streaming image dapat menyebabkan container gagal karena file yang hilang.

Container yang berjalan pada node dengan streaming Image yang diaktifkan pada versi berikut mungkin gagal dimulai atau dijalankan dengan error yang menginformasikan bahwa file tertentu tidak ada. Berikut adalah contoh error tersebut:

  • No such file or directory
  • Executable file not found in $PATH

Jika terpengaruh oleh masalah ini, Anda dapat menonaktifkan streaming Image.

Jaringan, Upgrade, dan update 1,28

Error konfigurasi TLS Gateway

Kami telah mengidentifikasi masalah terkait konfigurasi TLS untuk Gateway di cluster yang menjalankan GKE versi 1.28.4-gke.1083000. Hal ini memengaruhi konfigurasi TLS yang menggunakan SSLCertificate atau CertificateMap. Jika Anda mengupgrade cluster dengan Gateway yang ada, update yang dilakukan pada Gateway akan gagal. Untuk Gateway baru, load balancer tidak akan disediakan. Masalah ini akan diperbaiki dalam versi patch GKE 1.28 mendatang.

Upgrade dan update 1.27 1.27.8 atau yang lebih baru

Masalah plugin perangkat GPU

Cluster yang menjalankan GPU dan diupgrade dari 1.26 ke versi patch 1.27 sebelum 1.27.8 mungkin mengalami masalah dengan plugin perangkat GPU node (nvidia-gpu-device-plugin). Lakukan langkah-langkah berikut bergantung pada status cluster Anda:

  • Jika cluster Anda menjalankan versi 1.26 dan memiliki GPU, jangan upgrade cluster secara manual hingga versi 1.27.8 tersedia di saluran rilis cluster Anda.
  • Jika cluster Anda menjalankan versi patch 1.27 yang lebih lama dan node terpengaruh, mulai ulang node atau hapus Pod nvidia-gpu-device-plugin secara manual di node (pengelola add-on akan membuat plugin baru yang berfungsi).
  • Jika cluster Anda menggunakan upgrade otomatis, hal ini tidak akan memengaruhi Anda karena upgrade otomatis hanya akan memindahkan cluster ke versi patch yang berisi perbaikan.
Operasi 1.27,1.28
  • 1.27.5-gke.1300 dan yang lebih baru
  • 1.28.1-gke.1400 dan yang lebih baru

Penskalaan otomatis untuk semua workload berhenti

HorizontalPodAutoscaler (HPA) dan VerticalPodAutoscaler (VPA) mungkin berhenti menskalakan otomatis semua workload dalam cluster jika cluster tersebut berisi objek HPA autoscaling/v2 yang salah dikonfigurasi. Masalah ini berdampak pada cluster yang menjalankan versi patch GKE versi 1.27 dan 1.28 yang lebih lama (misalnya, 1.27.3-gke.100).

Solusi:

Perbaiki objek HPA autoscaling/v2 yang salah dikonfigurasi dengan memastikan kolom di spec.metrics.resource.target cocok, misalnya:

  • Jika spec.metrics.resource.target.type adalah Utilization, targetnya harus averageUtilization
  • Jika spec.metrics.resource.target.type adalah AverageValue, targetnya harus averageValue

Untuk mengetahui detail selengkapnya tentang cara mengonfigurasi objek HPA autoscaling/v2, lihat dokumentasi HorizontalPodAutoscaler Kubernetes.

Operasi 1.28,1.29
  • 1.28.7-gke.1026000
  • 1.29.2-gke.1060000

Container Threat Detection gagal di-deploy

Container Threat Detection mungkin gagal di-deploy pada cluster Autopilot yang menjalankan versi GKE berikut:

  • 1.28.6-gke.1095000 hingga 1.28.7-gke.1025000
  • 1.29.1-gke.1016000 hingga 1.29.1-gke.1781000
Jaringan, Upgrade 1.27, 1.28, 1.29, 1.30
  • 1.30.4-gke.1282000 atau yang lebih baru
  • 1.29.8-gke.1157000 atau yang lebih baru
  • 1.28.13-gke.1078000 atau yang lebih baru
  • 1.27.16-gke.1342000 atau yang lebih baru

Masalah konektivitas untuk Pod hostPort setelah upgrade bidang kontrol

Cluster dengan kebijakan jaringan diaktifkan mungkin mengalami masalah konektivitas dengan Pod hostPort. Selain itu, Pod yang baru dibuat mungkin memerlukan waktu tambahan 30 hingga 60 detik untuk siap.

Masalah ini dipicu saat bidang kontrol GKE cluster diupgrade ke salah satu versi GKE berikut

  • 1.30 hingga 1.30.4-gke.1281999
  • 1.29.1-gke.1545000 hingga 1.29.8-gke.1156999
  • 1.28.7-gke.1042000 hingga 1.28.13-gke.1077999
  • 1.27.12-gke.1107000 hingga 1.27.16-gke.1341999

Solusi:

Upgrade atau buat ulang node segera setelah upgrade bidang kontrol GKE.
Jaringan 1.31, 1.32
  • 1.32.1-gke.1729000 atau yang lebih baru
  • 1.31.6-gke.1020000 atau yang lebih baru

Traffic UDP yang rusak antara Pod yang berjalan di node yang sama

Cluster dengan visibilitas intra-node diaktifkan mungkin mengalami gangguan traffic UDP antara Pod yang berjalan di node yang sama.

Masalah ini dipicu saat node cluster GKE diupgrade ke atau dibuat dengan salah satu versi GKE berikut:

  • 1.32.1-gke.1729000 atau yang lebih baru
  • 1.31.6-gke.1020000 atau yang lebih baru

Jalur yang terpengaruh adalah traffic UDP Pod-ke-Pod di node yang sama melalui Hostport atau Service.

Resolusi

Upgrade cluster ke salah satu versi yang telah diperbaiki berikut:

  • 1.32.3-gke.1927000 atau yang lebih baru
  • 1.31.7-gke.1390000 atau yang lebih baru
Operasi 1.29,1.30,1.31
  • 1.29.10-gke.1071000 atau yang lebih baru
  • 1.30.5-gke.1723000 atau yang lebih baru
  • 1.31.2-gke.1115000 atau yang lebih baru

Operator Ray dan enkripsi database Cloud KMS yang tidak kompatibel

Beberapa versi Ray Operator tidak kompatibel dengan enkripsi database Cloud KMS.

Solusi sementara:

Upgrade bidang kontrol cluster ke versi yang diperbaiki atau yang lebih baru.
Upgrade dan update 1.30, 1.31
  • 1.30.8-gke.1051000 atau yang lebih baru
  • 1.31.1-gke.2008000 dan yang lebih baru

Pod Pengendali Pemeliharaan GPU Terjebak dalam Status CrashLoopBackOff

Dengan masalah ini, Pod gpu-maintenance-handler terjebak dalam status `CrashLoopBackOff` di node masing-masing. Status ini mencegah label `upcoming maintenance` diterapkan ke node GKE, yang dapat memengaruhi proses pengosongan node dan pengeluaran pod untuk workload.

"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"

Jika Anda terpengaruh oleh masalah ini, Anda dapat mengatasinya dengan mengupgrade bidang kontrol ke versi GKE yang menyertakan perbaikan.

Operasi 1.33.1-gke.1522000 dan yang lebih baru 1.33.4-gke.1142000 dan yang lebih baru

Pod gagal dimulai di node dengan streaming Image yang diaktifkan

Pada node dengan streaming Image yang diaktifkan, workload mungkin gagal dimulai dengan signature error berikut: Failed to create pod sandbox ... context deadline exceeded

Log port serial node yang terpengaruh juga berisi tanda tangan error berikut: task gcfsd ... blocked for more than X seconds

Adanya dua tanda error ini menunjukkan deadlock di salah satu komponen streaming Image. Kebuntuan ini menghambat Pod untuk berhasil dimulai.

Mitigasi:

Mulai ulang node untuk mitigasi cepat. Perhatikan bahwa node yang dimulai ulang mungkin masih mengalami deadlock lagi. Untuk mitigasi yang lebih kuat, nonaktifkan streaming Image di node pool dengan menjalankan perintah berikut: 

gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming
 Catatan: menonaktifkan streaming Image akan membuat ulang semua node dalam node pool.

Operasi
  • 1.32.4-gke.1198000 dan yang lebih baru
  • Versi 1.33 sebelum 1.33.5-gke.1862000
  • Versi 1.34 sebelum 1.34.1-gke.2541000
  • 1.33.5-gke.1862000 dan yang lebih baru
  • 1.34.1-gke.2541000 dan yang lebih baru

ComputeClass kustom dengan ImageType tidak menggunakan node pool GKE yang ada.

Saat menggunakan ComputeClass kustom yang menentukan kolom ImageType, Autoscaler Cluster berulang kali membuat dan meningkatkan skala node pool baru, bukan meningkatkan skala node pool yang ada. Status ComputeClass tidak responsif.

Solusi:

Upgrade cluster ke salah satu versi yang telah diperbaiki berikut:

  • 1.33.5-gke.1862000 atau yang lebih baru
  • 1.34.1-gke.2541000 atau yang lebih baru

Atau, Anda dapat mengurangi masalah ini dengan tidak menentukan kolom tertentu di ComputeClass kustom.

  • Jika Anda tidak menggunakan ComputeClass kustom Autopilot, jangan tentukan kolom ImageType. Dalam hal ini, nilai yang digunakan adalah setelan tingkat cluster default, yang secara default adalah cos_containerd.
  • Jika Anda menggunakan ComputeClass kustom Autopilot, jangan tentukan kolom nodePoolConfig, yang berada satu tingkat ImageType.

Langkah berikutnya