Menggunakan GKE Dataplane V2

Autopilot Standard

---

Halaman ini menjelaskan cara mengaktifkan GKE Dataplane V2 untuk cluster Google Kubernetes Engine (GKE).

Cluster Autopilot baru memiliki GKE Dataplane V2 yang diaktifkan pada versi 1.22.7-gke.1500 dan yang lebih baru serta versi 1.23.4-gke.1500 dan yang lebih baru. Jika Anda mengalami masalah saat menggunakan GKE Dataplane V2, lanjutkan ke Pemecahan masalah.

Membuat cluster GKE dengan GKE Dataplane V2

Anda dapat mengaktifkan GKE Dataplane V2 saat membuat cluster baru dengan GKE versi 1.20.6-gke.700 dan yang lebih baru menggunakan gcloud CLI atau Kubernetes Engine API. Anda juga dapat mengaktifkan GKE Dataplane V2 di Pratinjau saat membuat cluster baru menggunakan GKE versi 1.17.9 dan yang lebih baru

Peringatan: GKE Dataplane V2 dilengkapi dengan kebijakan jaringan Kubernetes bawaan. Ini berarti Anda tidak perlu mengaktifkan kebijakan jaringan di cluster yang menggunakan GKE Dataplane V2. Jika Anda mencoba mengaktifkan atau menonaktifkan penegakan kebijakan jaringan secara eksplisit di cluster yang menggunakan GKE Dataplane V2, permintaan akan gagal dan disertai dengan munculnya pesan error Enabling NetworkPolicy for clusters with DatapathProvider=ADVANCED_DATAPATH is not allowed..

Konsol

Untuk membuat cluster baru dengan GKE Dataplane V2, lakukan tugas berikut:

1. Buka halaman Google Kubernetes Engine di Konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Klik Buat.

3. Klik Konfigurasikan untuk mengonfigurasi cluster Standard.

4. Di bagian Networking, pilih kotak centang Aktifkan Dataplane V2. Opsi Aktifkan Kebijakan Jaringan Kubernetes akan dinonaktifkan saat Anda memilih Aktifkan Dataplane V2 karena penerapan kebijakan jaringan disertakan dalam GKE Dataplane V2.

5. Klik Create.

gcloud

Untuk membuat cluster baru dengan GKE Dataplane V2, gunakan perintah berikut:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --release-channel CHANNEL_NAME \
    --location COMPUTE_LOCATION

Ganti kode berikut:

• CLUSTER_NAME: nama cluster baru.
• CHANNEL_NAME: saluran rilis yang menyertakan GKE versi 1.20.6-gke.700 atau yang lebih baru. Jika memilih untuk tidak menggunakan saluran rilis, Anda juga dapat menggunakan tanda --cluster-version, bukan --release-channel, dengan menentukan versi 1.20.6-gke.700 atau yang lebih baru.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster baru.

API

Untuk membuat cluster baru dengan GKE Dataplane V2, tentukan kolom datapathProvider di objek networkConfig di permintaan create cluster Anda.

Cuplikan JSON berikut menunjukkan konfigurasi yang diperlukan untuk mengaktifkan GKE Dataplane V2:

"cluster":{
   "initialClusterVersion":"VERSION",
   "ipAllocationPolicy":{
      "useIpAliases":true
   },
   "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
   },
   "releaseChannel":{
      "channel":"CHANNEL_NAME"
   }
}

Ganti kode berikut:

• VERSION: versi cluster Anda yang harus berupa GKE 1.20.6-gke.700 atau yang lebih baru.
• CHANNEL_NAME: saluran rilis yang menyertakan GKE versi 1.20.6-gke.700 atau yang lebih baru.

Memecahkan masalah pada GKE Dataplane V2

Bagian ini menunjukkan cara menyelidiki dan menyelesaikan masalah pada GKE Dataplane V2.

1. Pastikan GKE Dataplane V2 telah diaktifkan:

   kubectl -n kube-system get pods -l k8s-app=cilium -o wide
   

   Jika GKE Dataplane V2 berjalan, output-nya akan menyertakan Pod dengan awalan anetd-. anetd adalah pengontrol jaringan untuk GKE Dataplane V2.

2. Jika masalah ini terkait dengan penerapan kebijakan jaringan atau layanan, periksa log Pod anetd. Gunakan pemilih log berikut di Cloud Logging:

   resource.type="k8s_container"
   labels."k8s-pod/k8s-app"="cilium"
   resource.labels.cluster_name="CLUSTER_NAME"
   

3. Jika pembuatan Pod gagal, periksa log kubelet untuk mendapatkan petunjuk. Gunakan pemilih log berikut di Cloud Logging:

   resource.type="k8s_node"
   log_name=~".*/logs/kubelet"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   Ganti CLUSTER_NAME dengan nama cluster, atau hapus seluruhnya untuk melihat log semua cluster.

Masalah umum

Rentang port Kebijakan Jaringan tidak diterapkan

Jika Anda menentukan kolom endPort di Kebijakan Jaringan di cluster yang telah mengaktifkan GKE Dataplane V2, kolom tersebut tidak akan diterapkan.

Mulai GKE 1.22, Anda dapat menggunakan Kubernetes Network Policy API untuk menentukan berbagai port tempat Kebijakan Jaringan diterapkan. API ini didukung dalam cluster dengan Kebijakan Jaringan Calico, tetapi tidak didukung di cluster yang menggunakan GKE Dataplane V2.

Anda dapat memverifikasi perilaku objek NetworkPolicy dengan membacanya kembali setelah selesai menulisnya ke server API. Jika objek masih berisi kolom endPort, fitur ini akan diterapkan. Jika kolom endPort tidak ada, fitur tidak akan diterapkan. Untuk semua kasus, objek yang disimpan di server API adalah sumber tepercaya untuk Kebijakan Jaringan.

Untuk mengetahui informasi selengkapnya, lihat KEP-2079: Kebijakan Jaringan untuk mendukung Rentang Port.

Pod menampilkan pesan error failed to allocate for range 0: no IP addresses available in range set

Versi GKE yang terpengaruh: 1.22 hingga 1.25

Cluster GKE yang menjalankan node pool yang menggunakan container dan mengaktifkan GKE Dataplane V2 dapat mengalami masalah kebocoran alamat IP dan menghabiskan semua alamat IP Pod pada node. Pod yang dijadwalkan di node yang terpengaruh akan menampilkan pesan error yang mirip dengan berikut ini:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Untuk mengetahui informasi selengkapnya tentang masalah tersebut, lihat masalah container #5768.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

• 1.22.17-gke.3100 atau yang lebih baru.
• 1.23.16-gke.200 atau yang lebih baru.
• 1.24.9-gke.3200 atau yang lebih baru.
• 1.25.6-gke.200 atau yang lebih baru.

Solusi untuk cluster GKE standar

Anda dapat mengurangi masalah ini dengan menghapus alamat IP Pod yang bocor untuk node tersebut.

Untuk menghapus alamat IP Pod yang bocor, Anda harus mendapatkan kredensial autentikasi untuk cluster lalu menjalankan langkah-langkah berikut untuk membersihkan satu node, jika Anda tahu namanya.

1. Simpan skrip shell berikut ke file bernama cleanup.sh:

   for hash in $(sudo find /var/lib/cni/networks/gke-pod-network -iregex '/var/lib/cni/networks/gke-pod-network/[0-9].*' -exec head -n1 {} \;); do hash="${hash%%[[:space:]]}"; if [ -z $(sudo ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then sudo grep -ilr $hash /var/lib/cni/networks/gke-pod-network; fi; done | sudo xargs -r rm
   

2. Jalankan skrip di node cluster:

   gcloud compute ssh --zone "ZONE" --project "PROJECT" NODE_NAME --command "$(cat cleanup.sh)"
   

   Ganti NODE_NAME dengan nama node.

Anda juga dapat menjalankan versi DaemonSet skrip ini agar berjalan secara paralel di semua node sekaligus:

1. Simpan manifes berikut ke file bernama cleanup-ips.yaml:

   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
         containers:
         - name: cleanup-ipam
           image: gcr.io/gke-networking-test-images/ubuntu-test:2022
           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
         volumes:
         - name: host-ipam
           hostPath:
             path: /var/lib/cni/networks/gke-pod-network
         - name: host-ctr
           hostPath:
             path: /run/containerd
   

2. Jalankan daemonset di cluster:

   kubectl apply -f cleanup-ips.yaml
   

   Anda harus memiliki akses kubectl sebagai administrator cluster untuk menjalankan perintah ini.

3. Periksa log DaemonSet yang sedang berjalan:

   kubectl -n kube-system logs -l name=cleanup-ipam
   

Kebijakan Jaringan memutuskan koneksi karena pencarian pelacakan koneksi salah

Saat Pod klien terhubung ke dirinya sendiri melalui Service atau alamat IP virtual dari Load Balancer Jaringan passthrough internal, paket balasan tidak akan diidentifikasi sebagai bagian dari koneksi yang ada karena pencarian koneksi 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.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

• 1.28.3-gke.1090000 atau yang lebih baru.

Solusi

Anda dapat mengurangi masalah ini dengan mengonfigurasi port dan containerPort di manifes Service ke nilai yang sama.

Penurunan paket untuk alur koneksi hairpin

Saat Pod membuat koneksi TCP ke dirinya sendiri menggunakan Service—Pod tersebut menjadi sumber sekaligus tujuan koneksi—maka 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.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

• 1.28.3-gke.1090000 atau yang lebih baru
• 1.27.11-gke.1097000 atau yang lebih baru

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 melalui Service. 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 Service. Akibatnya, tujuan permintaan koneksi ditetapkan ke alamat IP load balancer sehingga mencegah GKE Dataplane V2 melakukan SNAT ke alamat IP loopback.

Langkah selanjutnya

• Gunakan logging kebijakan jaringan untuk mencatat ketika koneksi ke Pod diizinkan atau ditolak oleh kebijakan jaringan cluster Anda.
• Pelajari cara kerja GKE Dataplane V2.