Menggunakan GKE Dataplane V2

Halaman ini menjelaskan cara mengaktifkan dan memecahkan masalah 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

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

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

Masalah konektivitas yang terputus-putus terkait konflik rentang NodePort di cluster GKE Dataplane V2

Di cluster GKE Dataplane V2, masalah konektivitas intermiten dapat terjadi untuk traffic yang disamarkan atau dengan penggunaan port sementara. Masalah ini disebabkan oleh kemungkinan konflik port dengan rentang NodePort yang dicadangkan dan biasanya terjadi dalam skenario berikut:

  • ip-masq-agent kustom: Jika menggunakan ip-masq-agent kustom (versi 2.10 atau yang lebih baru), dengan cluster yang memiliki layanan NodePort atau Load Balancer, Anda mungkin mengamati masalah konektivitas yang terputus-putus karena konflik dengan rentang NodePort. Sejak versi 2.10 dan yang lebih baru, ip-masq-agent memiliki argumen --random-fully yang diterapkan secara internal secara default. Untuk mengurangi hal ini, tetapkan --random-fully=false (berlaku sejak versi 2.11) secara eksplisit di bagian argumen dalam konfigurasi ip-masq-agent Anda. Untuk mengetahui detail konfigurasi, lihat Mengonfigurasi agen penyamaran IP di cluster Standar.

  • Tumpang-Tindih Rentang Port Efemeral: Jika rentang port efemeral yang ditentukan oleh net.ipv4.ip_local_port_range di node GKE Anda tumpang-tindih dengan rentang NodePort (30000-32767), hal ini juga dapat memicu masalah konektivitas. Untuk mencegah masalah ini, pastikan kedua rentang ini tidak tumpang-tindih.

Tinjau konfigurasi ip-masq-agent dan setelan rentang port sementara untuk memastikan keduanya tidak bertentangan dengan rentang NodePort. Jika Anda mengalami masalah konektivitas yang terputus-putus, pertimbangkan kemungkinan penyebab ini dan sesuaikan konfigurasi Anda.

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 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 koneksi yang salah di dataplane. Hal 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 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 berikutnya