Masalah umum jaringan GKE

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.29, 1.30, 1.31, 1.32, 1.33 1,34

Kontainer cilium-agent dalam Pod anetd mengalami error setelah menghapus kebijakan jaringan FQDN

Cluster dengan GKE Dataplane V2 yang diaktifkan mungkin mengalami error sementara pada penampung cilium-agent, sehingga menyebabkan waktu rekonsiliasi yang lebih lama untuk peristiwa yang harus diprogram di bidang data. Masalah ini disebabkan oleh dereferensi pointer nol saat penghapusan Kebijakan Jaringan FQDN.

Masalah ini dipicu oleh penghapusan kebijakan jaringan FQDN. Saat masalah terjadi, penampung Cilium-agent dalam Pod anetd akan menampilkan pesan error yang mirip dengan berikut: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x33e237d]


Solusi:

Untuk mengurangi masalah ini, alih-alih menghapus kebijakan FQDN, Anda dapat menambalnya agar tidak berpengaruh dengan memastikan tidak ada Pod yang tunduk padanya:

      kubectl patch fqdnnetpol -n namespace policy-name --patch '
      spec:
        podSelector:
          matchLabels:
            miss: me
      '

Resolusi

Upgrade versi cluster ke versi 1.34
1.28, 1.29, 1.30, 1.31, 1.32, 1.33

Kebocoran alamat IP Pod pada node dengan GKE Dataplane V2

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

  • 1.33 dan yang lebih baru
  • 1.32 dan yang lebih baru
  • 1.31.2-gke.1115000 atau yang lebih baru
  • 1.30.8-gke.1051001 atau yang lebih baru
  • 1.29.10-gke.1059000 atau yang lebih baru
  • 1.28.15-gke.1024000 atau yang lebih baru

Saat masalah ini terjadi, Pod baru yang dijadwalkan di node yang terpengaruh akan gagal dimulai dan menampilkan pesan error yang mirip dengan berikut ini: failed to assign an IP address to container.


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
  • 1.33.1-gke.1107000 dan yang lebih baru
  • 1.32.8-gke.1108000 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 alternatif:

  • 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.31,1.32
  • 1.31.7-gke.1158000 dan yang lebih baru
  • 1.32.3-gke.1499000 dan yang lebih baru

Masalah Gateway API karena storedVersions dihapus dari status CRD

Kube-Addon-Manager di GKE secara keliru menghapus v1alpha2 storedVersion dari status CRD Gateway API seperti gateway, httpRoute, gatewayClass, dan referenceGrant. Masalah ini terjadi bahkan saat cluster masih memiliki instance CRD tersebut yang disimpan dalam format v1alpha2. Jika versi cluster GKE diupgrade tanpa storedVersions, panggilan Gateway API akan gagal. Panggilan yang gagal juga dapat merusak pengontrol yang menerapkan Gateway API.

Cluster Anda mungkin berisiko jika memenuhi semua kondisi berikut:

  • Gateway API diaktifkan di cluster Anda.
  • Anda pernah menginstal CRD Gateway API versi v1alpha2.
  • Cluster Anda telah berjalan di versi GKE yang terpengaruh.

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 v1beta1. Contoh berikut memperbarui CRD gatewayClass:

  1. Periksa keberadaan versi penyimpanan v1alpha2: 
    kubectl get crd gatewayclasses.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"
  2. Sesuaikan versi penyimpanan ke v1beta1 dengan menjalankan perintah berikut di semua resource GatewayClass yang ada di cluster: 
    kubectl annotate gatewayclass gateway-class-name bump-storage-version="yes"
  3. Hapus versi penyimpanan v1alpha2 dan tetapkan versi penyimpanan ke v1beta1: 
    kubectl patch customresourcedefinitions gatewayclasses.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'
  4. Lakukan upgrade seperti biasa.
1,32
  • 1.32.3-gke.1170000 dan yang lebih baru

Pod baru gagal diinisialisasi dan macet di ContainerCreating

Pod baru gagal dibuat dan macet dalam status ContainerCreating. Saat masalah ini terjadi, container layanan mencatat hal berikut: 

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 initialClusterVersion menggunakan perintah berikut: 

  gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'

Jika cluster GKE telah mengaktifkan logging, penampung cilium-agent mencatat pesan unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key di Logs Explorer menggunakan kueri berikut: 

   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 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 yang mengaktifkan GKE Dataplane V2, saat Pod membuat koneksi TCP ke dirinya sendiri menggunakan Service, sehingga Pod 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 di 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 sehat 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 resource CPU yang tidak memadai.

Solusi alternatif:

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

Gangguan Multi-Cluster Gateway (MCG) pada cluster zona selama upgrade bidang kontrol

Deployment yang menggunakan Multi-Cluster Gateway (MCG) di cluster zona GKE mungkin 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 alternatif:

  • Solusi yang direkomendasikan adalah bermigrasi dari cluster GKE zonal ke cluster GKE regional. Cluster regional memiliki bidang kontrol dengan ketersediaan tinggi, yang menghilangkan satu titik kegagalan yang memicu masalah ini selama upgrade atau mulai ulang.

Dalam kondisi tertentu, gerbang kesiapan dapat menampilkan "positif palsu" status siap, sebelum health check ingress melaporkan status sehat, sehingga menghasilkan peristiwa error seperti berikut pada objek Ingress:

NEG is not attached to any BackendService with health checking. Marking condition "cloud.google.com/load-balancer-neg-ready" to True.

Masalah ini menyebabkan Load Balancer melaporkan error 503 (failed_to_pick_backend) ke traffic saat GKE melakukan update bertahap pada workload deployment.

Memiliki jumlah Pod yang relatif kecil (misalnya, 2) dibandingkan dengan jumlah NEG akan meningkatkan risiko kondisi persaingan ini. NEG dibuat untuk setiap region, dengan satu NEG per zona, yang biasanya menghasilkan tiga NEG. Jika ada sejumlah Pod yang relatif lebih besar, sehingga setiap NEG selalu memiliki beberapa Pod sebelum update berkelanjutan dimulai, kondisi persaingan ini sangat kecil kemungkinannya untuk dipicu.

Solusi:

Cara terbaik untuk mencegah kondisi persaingan ini adalah dengan memiliki lebih banyak backend di Network Endpoint Group. Pastikan strategi update bertahap dikonfigurasi untuk memastikan setidaknya 1 Pod selalu berjalan. Misalnya, jika hanya 2 Pod yang berjalan normal, contoh konfigurasi dapat terlihat seperti ini:

strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 0
     maxSurge: 1

Contoh sebelumnya adalah saran. Anda harus memperbarui strategi berdasarkan beberapa faktor, seperti jumlah replika.

Sampah GKE membersihkan load balancer berbasis container setiap dua menit. Jika cluster dihapus sebelum load balancer sepenuhnya dihapus, Anda harus menghapus NEG load balancer secara manual.

Solusi:

Lihat NEG di project Anda dengan menjalankan perintah berikut:

gcloud compute network-endpoint-groups list

Di output perintah, cari NEG yang relevan.

Untuk menghapus NEG, jalankan perintah berikut, dengan mengganti <var>NEG_NAME</var> dengan nama NEG:

gcloud compute network-endpoint-groups delete <var>NEG_NAME</var>

Masalah ini tidak terjadi pada cluster yang menggunakan masukan kesiapan Pod untuk mengelola peluncuran workload. Saat Anda men-deploy workload ke cluster, atau saat mengupdate workload yang sudah ada, load balancer berbasis container dapat memerlukan waktu lebih lama untuk menerapkan endpoint baru daripada yang diperlukan untuk menyelesaikan peluncuran workload.


Solusi:

Konfigurasi nilai minReadySeconds dan terminationGracePeriodSeconds workload menjadi 60 detik atau lebih untuk memastikan layanan tidak terganggu karena peluncuran workload.

  • terminationGracePeriodSeconds memungkinkan Pod dimatikan secara tuntas dengan menunggu koneksi dihentikan setelah Pod dijadwalkan untuk dihapus.
  • minReadySeconds menambahkan periode latensi setelah Pod dibuat.

Anda mungkin berharap konfigurasi initialDelaySeconds di readinessProbe Pod akan dipatuhi oleh load balancer berbasis container. Namun, readinessProbe diterapkan oleh kubelet, dan konfigurasi initialDelaySeconds akan mengontrol health check kubelet, bukan load balancer berbasis container. Load balancing berbasis container memiliki health check load balancing-nya sendiri.