Masalah umum jaringan GKE

Autopilot Standard

---

Halaman ini mencantumkan masalah umum untuk jaringan 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.

Untuk memfilter masalah umum berdasarkan versi produk, pilih filter dari menu drop-down berikut.

Pilih versi GKE Anda:

1,30 1,29 1,28 1.27

Atau, telusuri masalah Anda:

Versi yang diidentifikasi	Versi tetap	Masalah dan solusi
1.30, 1.31, 1.32		Node yang baru dibuat tidak ditambahkan ke load balancer internal lapisan 4 Load balancer Google Cloud yang dibuat untuk Layanan LoadBalancer internal mungkin melewatkan node yang baru dibuat di grup instance backend. Masalah ini akan paling terlihat pada cluster yang diskalakan ke nol node, lalu diskalakan kembali ke satu atau beberapa node. Solusi: Aktifkan subsetelan GKE dan buat ulang Layanan. Catatan: Setelan sub-GKE tidak dapat dinonaktifkan setelah diaktifkan. Buat Layanan LoadBalancing internal lainnya. Saat disinkronkan, grup instance juga akan diperbaiki untuk Layanan yang terpengaruh. Layanan baru dapat dihapus setelah sinkronisasi. Tambahkan, lalu hapus label node.kubernetes.io/exclude-from-external-load-balancers dari salah satu node. Tambahkan node ke cluster. Anda dapat menghapus node setelah Layanan mulai berfungsi.
1.27,1.28,1.29,1.30,1.31		Pengontrol NEG berhenti mengelola endpoint saat port dihapus dari Layanan Jika pengontrol NEG dikonfigurasi untuk membuat NEG Mandiri untuk Layanan dan salah satu port yang dikonfigurasi kemudian dihapus dari Layanan, pengontrol NEG pada akhirnya akan berhenti mengelola endpoint untuk NEG. Selain Layanan tempat pengguna membuat anotasi NEG Mandiri, hal ini juga memengaruhi Layanan yang direferensikan oleh GKE Gateway, MCI, dan GKE Multi Cluster Gateway. Solusi: Saat menghapus port dari Layanan dengan anotasi NEG Mandiri, anotasi tersebut juga harus diperbarui untuk menghapus port yang dimaksud.
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.
1.27,1.28,1.29	1.26.13-gke.1052000 dan yang lebih baru 1.27.10-gke.1055000 dan yang lebih baru 1.28.6-gke.1095000 dan yang lebih baru 1.29.1-gke.1016000 dan yang lebih baru	Kegagalan pembentukan koneksi secara berkala Cluster pada control plane versi 1.26.6-gke.1900 dan yang lebih baru mungkin mengalami kegagalan pembentukan koneksi yang terputus-putus. Kemungkinan kegagalannya rendah dan tidak memengaruhi semua cluster. Kegagalan akan berhenti sepenuhnya setelah beberapa hari sejak timbulnya gejala.
1.27,1.28,1.29	1.27.11-gke.1118000 atau yang lebih baru 1.28.7-gke.1100000 atau yang lebih baru 1.29.2-gke.1217000 atau yang lebih baru	Masalah resolusi DNS dengan Container-Optimized OS Workload yang berjalan di cluster GKE dengan node berbasis Container-Optimized OS mungkin mengalami masalah resolusi DNS.
1,28	1.28.3-gke.1090000 atau yang lebih baru	Kebijakan Jaringan memutuskan koneksi karena pencarian pelacakan koneksi salah Untuk cluster yang mengaktifkan GKE Dataplane V2, saat Pod klien terhubung ke dirinya sendiri menggunakan Service atau alamat IP virtual dari Load Balancer Jaringan passthrough internal, paket balasan tidak akan diidentifikasi sebagai bagian dari koneksi yang ada karena pencarian conntrack yang salah di dataplane. Ini berarti Kebijakan Jaringan yang membatasi traffic masuk untuk Pod tidak diterapkan dengan benar pada paket. Dampak masalah ini bergantung pada jumlah Pod yang dikonfigurasi untuk Layanan. Misalnya, jika Layanan memiliki 1 Pod backend, koneksi akan selalu gagal. Jika Service memiliki 2 Pod backend, koneksi akan gagal 50% dari waktu tersebut. Solusi: Anda dapat mengurangi masalah ini dengan mengonfigurasi port dan containerPort di manifes Layanan ke nilai yang sama.
1.27,1.28	1.28.3-gke.1090000 atau yang lebih baru 1.27.11-gke.1097000 atau yang lebih baru	Penurunan paket untuk alur koneksi hairpin Untuk cluster yang mengaktifkan GKE Dataplane V2, saat Pod membuat koneksi TCP ke dirinya sendiri menggunakan Service, sehingga Pod menjadi sumber dan tujuan koneksi, pelacakan koneksi eBPF GKE Dataplane V2 akan salah melacak status koneksi sehingga menyebabkan kebocoran entri conntrack. Jika tuple koneksi (protokol, IP sumber/tujuan, dan port sumber/tujuan) bocor, koneksi baru yang menggunakan tuple koneksi yang sama dapat mengakibatkan paket yang ditampilkan dihapus. Solusi: Gunakan salah satu dari solusi sementara berikut: Mengaktifkan penggunaan ulang TCP (keep-alive) untuk aplikasi yang berjalan di Pod yang dapat berkomunikasi dengan dirinya sendiri menggunakan Layanan. Tindakan ini akan mencegah flag TCP FIN dikeluarkan dan menghindari kebocoran entri conntrack. Saat menggunakan koneksi dengan durasi aktif pendek, ekspos Pod akan menggunakan load balancer proxy, seperti Gateway, untuk mengekspos Layanan. Akibatnya, tujuan permintaan koneksi ditetapkan ke alamat IP load balancer sehingga mencegah GKE Dataplane V2 melakukan SNAT ke alamat IP loopback.
Lebih awal dari 1.31.0-gke.1506000	1.31.0-gke.1506000 dan yang lebih baru	Jaringan yang diketik perangkat di multi-jaringan GKE gagal dengan nama jaringan yang panjang Pembuatan cluster gagal dengan error berikut: error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument Solusi: Batasi panjang nama objek jaringan yang diketik perangkat menjadi 41 karakter atau kurang. Jalur lengkap setiap soket domain UNIX disusun, termasuk nama jaringan yang sesuai. Linux memiliki batasan pada panjang jalur socket (di bawah 107 byte). Setelah memperhitungkan direktori, awalan nama file, dan ekstensi .sock, nama jaringan dibatasi hingga maksimum 41 karakter.
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 panel 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 control plane 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 control plane GKE.
1.28, 1.29, 1.30, 1.31		Pod Calico tidak sehat di cluster dengan total node kurang dari 3 dan vCPU yang tidak memadai Pod calico-typha dan calico-node tidak dapat dijadwalkan di cluster yang memenuhi semua kondisi berikut: total kurang dari 3 node, setiap node memiliki 1 vCPU atau kurang yang dapat dialokasikan, dan kebijakan jaringan diaktifkan. Hal ini disebabkan oleh resource CPU yang tidak memadai. Solusi: Menskalakan ke minimum 3 node pool dengan 1 node menggunakan 1 vCPU yang dapat dialokasikan. Ubah ukuran satu node pool menjadi minimal 3 node dengan 1 vCPU yang dapat dialokasikan. Gunakan jenis mesin dengan minimal 2 vCPU yang dapat dialokasikan di kumpulan node dengan satu node.