Halaman ini mencantumkan masalah umum untuk jaringan 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.
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.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Kebocoran alamat IP Pod pada node dengan GKE Dataplane V2Cluster dengan GKE Dataplane V2 yang diaktifkan mungkin mengalami kehabisan alamat IP Pod pada node. Masalah ini disebabkan oleh bug runtime container yang dapat membocorkan alamat IP yang dialokasikan saat Pod mengalami error CNI sementara selama pembuatan. Masalah ini dipicu saat node cluster GKE diupgrade ke atau dibuat dengan salah satu versi GKE berikut:
Saat masalah ini terjadi, Pod baru yang dijadwalkan di node yang terpengaruh akan gagal dimulai dan menampilkan pesan error yang mirip dengan berikut ini: Solusi: Untuk mengurangi masalah ini, Anda dapat menerapkan DaemonSet mitigasi ke cluster untuk membersihkan resource IP yang bocor: apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32, 1.33 |
|
Gangguan load balancer Ingress dan Service pada cluster dengan jaringan lamaKetidakcocokan 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 |
|
Node yang baru dibuat tidak ditambahkan ke load balancer internal layer 4Load 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:
|
| 1.31,1.32 |
|
Masalah Gateway API karena storedVersions dihapus dari status CRD
Kube-Addon-Manager di GKE secara keliru menghapus Cluster Anda mungkin berisiko jika memenuhi semua kondisi berikut:
Solusi: Solusi yang direkomendasikan adalah menunda upgrade cluster hingga masalah ini teratasi.
Atau, jika Anda perlu mengupgrade versi cluster, Anda harus mengupdate versi penyimpanan untuk semua CRD Gateway API yang terpengaruh ke
|
| 1,32 |
|
Pod baru yang gagal diinisialisasi macet di ContainerCreating
Pod baru gagal dibuat dan macet dalam status Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Masalah ini memengaruhi cluster GKE dalam versi antara 1.32 dan sebelum 1.32.3-gke.1170000, yang dibuat pada versi GKE 1.31 atau 1.32. Penyebab utamanya adalah struktur data dalam memori yang mempertahankan kumpulan identitas Cilium yang dialokasikan tidak disinkronkan dengan benar dengan status server API Kubernetes.
Untuk mengonfirmasi versi GKE yang digunakan untuk membuat cluster, Anda dapat membuat kueri resource gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
Jika cluster GKE telah mengaktifkan logging, container resource.type="k8s_container" resource.labels.container_name="cilium-agent" Solusi: Solusi sementara adalah memulai ulang bidang kontrol. Hal ini dapat dilakukan dengan mengupgrade bidang kontrol ke versi yang sama dengan yang sudah dijalankannya: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27,1.28,1.29,1.30,1.31 |
Pengontrol NEG berhenti mengelola endpoint saat port dihapus dari LayananJika 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 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. |
|
| 1.27,1.28,1.29 |
|
Kegagalan pembuatan koneksi secara berkalaCluster 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 |
|
Masalah resolusi DNS dengan Container-Optimized OSWorkload 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 salahUntuk 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 |
| 1.27,1.28 |
|
Penurunan paket untuk alur koneksi hairpinUntuk 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:
|
| 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 panjangPembuatan cluster gagal dengan error berikut:
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 |
| 1.27, 1.28, 1.29, 1.30 |
|
Masalah konektivitas untuk Pod
|
| 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:
|
| 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 memadaiPod 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:
|
|
Gangguan Multi-Cluster Gateway (MCG) pada cluster zona selama upgrade bidang kontrolDeployment yang menggunakan Multi-Cluster Gateway (MCG) di cluster zonal GKE dapat mengalami gangguan dengan error `503` selama peristiwa yang menyebabkan restart bidang kontrol, seperti upgrade cluster. Hal ini terjadi karena MCG mengandalkan mekanisme lama untuk penemuan Network Endpoint Group (NEG) yang salah melaporkan nol backend saat node dalam cluster zona menjadi tidak tersedia untuk sementara selama restart bidang kontrol. Hal ini menyebabkan load balancer menghapus semua backend, sehingga menyebabkan hilangnya traffic. Solusi Sementara:
|