Halaman ini mencantumkan masalah umum GKE. Halaman ini ditujukan bagi 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 khusus untuk versi 1.28 dan yang lebih lama akan dihapus.
Jika Anda adalah bagian dari Program Developer Google, 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 solusi |
|---|---|---|---|
| Operasi | 1.33 versi 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 dinamisSaat menyediakan instance Lustre secara dinamis, pembuatan instance akan gagal dengan error Solusi: Upgrade cluster GKE ke versi 1.33.4-gke.1036000 atau yang lebih baru. Jika menggunakan channel Stabil, versi yang lebih baru mungkin belum tersedia. Dalam hal ini, Anda dapat memilih versi secara manual dari saluran Reguler atau Cepat yang menyertakan perbaikan. |
| Operasi |
|
1.33.3-gke.1266000 dan yang lebih baru |
Error input/output saat mengganti nama atau memindahkan file menggunakan driver CSI Cloud Storage FUSESaat menggunakan driver CSI Cloud Storage FUSE versi yang terpengaruh, mengganti nama atau memindahkan file di bucket Cloud Storage mungkin gagal dengan error I/O. Solusi: Tambahkan definisi image sidecar tertentu ke manifes Pod Anda untuk sementara. Di bagian # 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 tetap atau yang lebih baru, Anda harus menghapus seluruh blok |
| Logging dan pemantauan | Semua versi | Ditentukan Nanti |
Kondisi race di DaemonSet
|
| Upgrade | 1.33 | 1.33.2-gke.1043000 |
Membatasi jumlah file terbuka dengan containerd 2.0Untuk node pool yang menjalankan GKE versi 1.33, yang menggunakan containerd 2.0, batas lunak default untuk file terbuka ( Ini adalah perubahan pada containerd itu sendiri (lihat containerd PR #8924) yang menghapus Workload yang mengharapkan batas sementara default yang lebih tinggi (misalnya, yang secara implisit mengandalkan default yang lebih tinggi sebelumnya) mungkin mengalami kegagalan, seperti error Solusi: Upgrade dari versi patch 1.33 yang lebih lama ke 1.33.2-gke.1043000 atau yang lebih baru. Solusi: Tingkatkan batas file terbuka untuk workload Anda menggunakan salah satu metode berikut:
|
| Upgrade | 1.31.5-gke.1169000, 1.32.1-gke.1376000 | 1.31.7-gke.1164000, 1.32.3-gke.1512000 |
Status CRD.storedVersions tidak valid untuk CRD terkelolaBeberapa CRD yang dikelola GKE mungkin memiliki kolom Masalah ini memengaruhi cluster yang memenuhi kedua hal berikut:
Solusi: Solusi yang direkomendasikan adalah menunda upgrade cluster hingga masalah tersebut teratasi. Atau, jika Anda mengetahui bahwa cluster Anda berisi objek CRD versi yang tidak didukung, Anda dapat menambahkan versi ini ke kolom |
| Operasi, logging, dan pemantauan | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Metrik tidak ada atau penskalaan otomatis beban kerja tidak berfungsiAnda mungkin melihat kesenjangan dalam data metrik pada versi yang terpengaruh setelah ukuran cluster bertambah lebih dari lima node. Masalah ini juga dapat 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 terpengaruh, Anda dapat mendowngrade satu versi patch atau mengupgrade ke versi tetap yang lebih baru. |
| Operasi |
Batas ukuran dan lampiran Google Cloud HyperdiskBiasanya, Pod yang tidak dapat dijadwalkan dengan berhasil karena batas lampiran volume node akan memicu penyediaan otomatis node baru. Saat menjalankan workload yang menggunakan produk Hyperdisk dijadwalkan ke node yang menjalankan VM C3, penyediaan otomatis node tidak terjadi dan pod dijadwalkan ke node yang sudah penuh. Workload dijadwalkan ke node meskipun tidak ada lampiran disk yang tersedia. Beban kerja 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 Hyperdisk memicu penyediaan otomatis pada bentuk VM lainnya. Sebaiknya gunakan bentuk yang hanya mendukung 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 dihentikan secara paksa karena kehabisan memori (OOMKilled) di node TPU/GPUPada node TPU GKE (misalnya Solusi: Jika Anda mengamati peristiwa |
|
| Operasi |
|
|
Pengubahan ukuran volume mungkin macet karena status NodePendingResize yang tidak terhubung pada PVC.Cluster pada versi 1.32 yang memiliki node pada versi 1.31 atau yang lebih lama akan gagal memperbarui status PersistentVolumeClaim selama pengubahan ukuran. Status yang salah ini mencegah operasi pengubahan ukuran berikutnya dimulai, sehingga mencegah pengubahan ukuran lebih lanjut. PVC dalam status ini memiliki kolom Jika PVC dibuat saat cluster Anda menggunakan versi yang terpengaruh, Anda mungkin melihat masalah ini tetap terjadi setelah cluster Anda diupgrade ke versi tetap yang diketahui. Dalam skenario ini, PVC Anda perlu di-patch untuk menghapus kolom Solusi: PVC yang macet karena status tidak jelas dapat di-patch untuk menghapus status tersebut. Anda dapat menggunakan perintah patch seperti berikut untuk menghapus status tidak terikat: 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 |
|
|
Driver PDCSI mungkin mencatat secara berlebihanCluster GKE pada versi 1.32 tertentu dapat memancarkan pesan log yang berlebihan dari driver PDCSI. Pencatatan log yang berlebihan ini akan menggunakan kuota Cloud Logging Write API. Solusi: Anda dapat mengurangi logging yang berlebihan ini dengan menambahkan filter pengecualian. Untuk mengecualikan pesan log agar tidak di-ingest ke 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 |
|
|
Pod yang mencoba memasang volume persisten NFS pada node COS yang sebelumnya memiliki pemasangan Hanya Baca (RO) hanya akan dipasang dalam mode ROUntuk 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 di node yang sama. Solusi: Downgrade node pool ke versi yang lebih lama dari versi yang terpengaruh |
| Operasi |
|
|
Pod yang mencoba memasang volume persisten NFS di node Ubuntu tidak akan dapat berjalan.Untuk volume NFS GKE versi 1.32 dan yang lebih baru yang menggunakan driver CSI bawaan 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" 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.1302000 |
|
Pod yang menggunakan syscall terkait io_uring mungkin macet dalam status Terminating
Pod yang menggunakan syscall terkait io_uring dapat 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
Jika Pod terpengaruh oleh masalah umum ini, kontainernya mungkin gagal dihentikan secara normal. Dalam log containerd, Anda mungkin melihat pesan berulang yang mirip dengan berikut ini:
atau
Gejala ini menunjukkan proses dalam container yang macet dalam mode tidur yang tidak dapat diinterupsi (status D), yang mencegah penghentian Pod yang tepat.
Beban kerja 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. Beban kerja yang terpengaruh memiliki proses dalam status D (disk sleep) di file Solusi: Upgrade node cluster ke versi yang telah diperbaiki atau yang lebih baru. |
| Operasi | 1.28, 1.29, 1.30, 1.31 |
|
Beban kerja yang menggunakan streaming Image gagal dengan error autentikasiBug dalam fitur streaming Image dapat menyebabkan workload gagal saat serangkaian kondisi tertentu terpenuhi saat penampung membaca file. Pesan error terkait kegagalan autentikasi mungkin terlihat di log gcfsd.
Untuk memeriksa apakah Anda terpengaruh, telusuri log dengan kueri penelusuran ini:
Keberadaan 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 |
|
|
Peningkatan tingkat penghapusan Pod pada GKE versi 1.30 dan 1.31
Beberapa versi GKE 1.30 dan GKE 1.31 yang menggunakan COS 113 dan COS 117, masing-masing, memiliki kernel yang dibuat
dengan opsi
Opsi konfigurasi Anda mungkin tidak selalu melihat rasio penghapusan Pod yang tidak biasa karena masalah ini bergantung pada pola penggunaan memori beban kerja. 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 yang lebih tinggi pada aplikasi setelah mengupgrade ke versi GKE yang disebutkan tanpa perubahan lain, maka Anda mungkin terpengaruh oleh opsi kernel.
Untuk memeriksa apakah ada tingkat penghapusan Pod yang tidak biasa, analisis metrik berikut dengan
Metrics Explorer:
Anda dapat menggunakan kueri PromQL berikut. Ganti nilai untuk
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 penggunaan memori yang tidak biasa dan melebihi memori yang diminta, workload mungkin lebih sering dikeluarkan. SolusiJika Anda tidak dapat mengupgrade ke versi yang telah diperbaiki dan jika Anda menjalankan di lingkungan GKE tempat Anda dapat men-deploy Pod istimewa, Anda dapat menonaktifkan opsi LRU Multi-Gen dengan menggunakan DaemonSet.
Setelah DaemonSet berjalan di semua kumpulan node yang dipilih, perubahan akan segera berlaku dan perhitungan penggunaan memori kubelet kembali normal. |
| Operasi | 1.28, 1.29, 1.30, 1.31 |
|
Pod terjebak dalam status TerminatingBug di runtime container (containerd) dapat menyebabkan Pod dan container macet 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.28,1.29 |
|
Streaming gambar gagal karena link simbolisBug dalam fitur Streaming image dapat menyebabkan container gagal dimulai. Container yang berjalan di node dengan streaming image yang 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"
Jika Anda terpengaruh oleh masalah ini, 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 |
|
Streaming gambar gagal karena file tidak adaBug dalam fitur Streaming gambar dapat menyebabkan kegagalan penampung karena file yang hilang. Container yang berjalan di node dengan streaming Image yang diaktifkan pada versi berikut mungkin gagal dimulai atau berjalan dengan error yang menginformasikan bahwa file tertentu tidak ada. Berikut adalah contoh error tersebut:
Jika Anda terpengaruh oleh masalah ini, Anda dapat menonaktifkan streaming Image. |
| Jaringan, Upgrade, dan update | 1,28 |
Error konfigurasi TLS gatewayKami 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
yang lebih lama dari 1.27.8 mungkin mengalami masalah dengan plugin perangkat GPU (
|
| Operasi | 1.27,1.28 |
|
Penskalaan otomatis untuk semua beban kerja berhenti
HorizontalPodAutoscaler (HPA) dan VerticalPodAutoscaler (VPA) dapat
menghentikan penskalaan otomatis semua workload dalam cluster jika cluster tersebut berisi
objek HPA Solusi:
Perbaiki objek HPA
Untuk mengetahui detail selengkapnya tentang cara mengonfigurasi objek HPA |
| Operasi | 1.28,1.29 |
|
Container Threat Detection gagal di-deployDeteksi Ancaman Kontainer mungkin gagal di-deploy pada cluster Autopilot yang menjalankan versi GKE berikut:
|
| Jaringan, Upgrade | 1.27, 1.28, 1.29, 1.30 |
|
Masalah konektivitas untuk Pod
|
| Jaringan | 1.31, 1.32 |
|
Traffic UDP yang terganggu antar-Pod yang berjalan di node yang samaCluster dengan visibilitas intra-node diaktifkan mungkin mengalami masalah traffic UDP antar-Pod yang berjalan di node yang sama. Masalah ini dipicu saat node cluster GKE diupgrade ke atau dibuat dengan salah satu versi GKE berikut:
Jalur yang terpengaruh adalah traffic UDP Pod-ke-Pod di node yang sama melalui Hostport atau Layanan. Resolusi Upgrade cluster ke salah satu versi tetap berikut:
|
| Operasi | 1.29,1.30,1.31 |
|
Enkripsi database Cloud KMS dan Ray Operator yang tidak kompatibelBeberapa versi Ray Operator tidak kompatibel dengan enkripsi database Cloud KMS. Solusi Sementara: Upgrade bidang kontrol cluster ke versi tetap atau yang lebih baru. |
| Upgrade dan update | 1.30, 1.31 |
|
Pod GPU Maintenance Handler Macet dalam Status CrashLoopBackOffDengan masalah ini, Pod gpu-maintenance-handler terjebak dalam status `CrashLoopBackOff` di masing-masing node. Status ini mencegah label `upcoming maintenance` diterapkan ke node GKE, yang dapat memengaruhi proses pengurasan node dan pengusiran 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 menyelesaikannya 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 tanda tangan error berikut:
Log port serial node yang terpengaruh juga berisi tanda tangan error berikut:
Kehadiran dua tanda tangan error ini menunjukkan kebuntuan di salah satu komponen streaming Gambar. Kebuntuan ini menghambat Pod agar berhasil dimulai. Mitigasi: Mulai ulang node untuk mitigasi cepat. Perhatikan bahwa node yang dimulai ulang mungkin masih mengalami kebuntuan 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 |
Langkah berikutnya
Jika Anda tidak dapat menemukan solusi untuk masalah Anda dalam dokumentasi, lihat Mendapatkan dukungan untuk mendapatkan bantuan lebih lanjut, termasuk saran tentang topik berikut:
- Membuka kasus dukungan dengan menghubungi Layanan Pelanggan Cloud.
- Mendapatkan dukungan dari komunitas dengan
mengajukan pertanyaan di StackOverflow
dan menggunakan tag
google-kubernetes-engineuntuk menelusuri masalah serupa. Anda juga dapat bergabung ke#kubernetes-enginechannel Slack untuk mendapatkan dukungan komunitas lainnya. - Membuka bug atau permintaan fitur menggunakan issue tracker publik.