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
Konsol
Untuk membuat cluster baru dengan GKE Dataplane V2, lakukan tugas berikut:
Buka halaman Google Kubernetes Engine di Konsol Google Cloud.
Klik add_box Buat.
Klik Konfigurasikan untuk mengonfigurasi cluster Standard.
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.
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.
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.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"
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.
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
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:
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
Jalankan daemonset di cluster:
kubectl apply -f cleanup-ips.yaml
Anda harus memiliki akses kubectl sebagai administrator cluster untuk menjalankan perintah ini.
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.