Masalah umum jaringan GKE

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 menurut versi produk, pilih filter Anda dari menu drop-down berikut.

Pilih versi GKE Anda:

Atau, telusuri masalah Anda:

Versi yang diidentifikasi Versi tetap Masalah dan solusi
1.31, 1.32, 1.33
  • 1.33.1-gke.1107000 dan yang lebih baru

Gangguan load balancer Ingress dan Service pada cluster dengan jaringan lama

Ketidakcocokan dengan jaringan lama menyebabkan backend load balancer yang dikelola GKE yang di-deploy menggunakan Ingress atau Layanan terlepas. Hal ini menyebabkan load balancer tidak memiliki backend aktif, yang pada gilirannya menyebabkan semua permintaan masuk ke load balancer tersebut dibatalkan.

Masalah ini memengaruhi cluster GKE yang menggunakan jaringan lama dan menggunakan versi 1.31 atau yang lebih baru.

Untuk mengidentifikasi cluster GKE dengan jaringan lama, jalankan perintah berikut: 

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

Cluster dengan jaringan lama akan mendapatkan output kosong untuk perintah ini.

Solusi:

Karena jaringan lama sudah tidak digunakan lagi selama beberapa waktu, solusi yang lebih disarankan adalah memigrasikan jaringan lama Anda ke jaringan VPC. Anda dapat melakukannya dengan mengonversi jaringan lama yang berisi cluster GKE. Jika Anda tidak dapat melakukan migrasi ini saat ini, hubungi Cloud Customer Care.

1.30, 1.31, 1.32
  • 1.30.10-gke.1070000 dan yang lebih baru
  • 1.31.5-gke.1068000 dan yang lebih baru
  • 1.32.1-gke.1002000 dan yang lebih baru

Node yang baru dibuat tidak ditambahkan ke load balancer internal layer 4

Load balancer Google Cloud yang dibuat untuk Service LoadBalancer internal mungkin tidak menyertakan 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 Sementara:

  • Aktifkan subsetelan GKE dan buat ulang Layanan.

    Catatan: Subsetelan 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 Service tempat pengguna membuat anotasi NEG Mandiri, hal ini juga memengaruhi Service yang dirujuk oleh Gateway GKE, MCI, dan Multi Cluster Gateway GKE.

Solusi:

Saat menghapus port dari Service dengan anotasi NEG Mandiri, anotasi juga perlu diperbarui untuk menghapus port yang dimaksud.

1,28

Error konfigurasi TLS Gateway

Kami telah mengidentifikasi masalah saat mengonfigurasi 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 pembuatan koneksi secara berkala

Cluster pada versi bidang kontrol 1.26.6-gke.1900 dan yang lebih baru mungkin mengalami kegagalan pembuatan koneksi secara berkala.

Kemungkinan kegagalan 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 dengan GKE Dataplane V2 yang diaktifkan, 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 di paket.

Dampak masalah ini bergantung pada jumlah Pod yang dikonfigurasi untuk Service. Misalnya, jika Service 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 Service 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 dengan GKE Dataplane V2 yang diaktifkan, saat Pod membuat koneksi TCP ke dirinya sendiri menggunakan Service, sehingga Pod tersebut menjadi sumber sekaligus 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 Service. Tindakan ini akan mencegah flag FIN TCP dikeluarkan dan menghindari kebocoran entri conntrack.
  • Saat menggunakan koneksi dengan durasi aktif pendek, ekspos Pod akan menggunakan load balancer proxy, seperti Gateway, untuk mengekspos Service. 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 hingga 41 karakter atau kurang. Jalur lengkap setiap soket domain UNIX disusun, termasuk nama jaringan yang sesuai. Linux memiliki batasan pada panjang jalur soket (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 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.
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 terganggu antar-Pod yang berjalan di node yang sama

Cluster 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:

  • 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 Layanan.

Resolusi

Upgrade cluster ke salah satu versi tetap berikut:

  • 1.32.3-gke.1927000 atau yang lebih baru
  • 1.31.7-gke.1390000 atau yang lebih baru
1.28, 1.29, 1.30, 1.31

Pod Calico tidak dalam kondisi baik di cluster dengan total kurang dari 3 node 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 atau kurang vCPU yang dapat dialokasikan, dan kebijakan jaringan diaktifkan. Hal ini disebabkan oleh kurangnya resource CPU.

Solusi Sementara:

  • Lakukan penskalaan ke minimal 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 pada kumpulan node dengan satu node.