GKE Dataplane V2

Halaman ini memberikan ringkasan tentang fungsi GKE Dataplane V2 dan cara kerjanya.

Sebelum membaca halaman ini, pastikan Anda sudah memahami jaringan di dalam cluster GKE.

Ringkasan GKE Dataplane V2

GKE Dataplane V2 adalah dataplane yang dioptimalkan untuk jaringan Kubernetes. GKE Dataplane V2 menyediakan:

  • Pengalaman pengguna yang konsisten untuk jaringan.
  • Visibilitas aktivitas jaringan secara real-time.
  • Arsitektur lebih sederhana yang memudahkan pengelolaan dan pemecahan masalah cluster.

GKE Dataplane V2 diaktifkan secara default untuk semua cluster Autopilot baru.

Cara kerja GKE Dataplane V2

GKE Dataplane V2 diimplementasikan menggunakan eBPF. Saat paket tiba di node GKE, program eBPF yang diinstal di kernel akan memutuskan cara merutekan dan memproses paket. Tidak seperti pemrosesan paket dengan iptables, program eBPF dapat menggunakan metadata khusus Kubernetes dalam paket. Hal ini memungkinkan GKE Dataplane V2 memproses paket jaringan dalam kernel secara lebih efisien dan melaporkan kembali tindakan yang dianotasi ke ruang pengguna untuk logging.

Diagram berikut menunjukkan jalur paket melalui node menggunakan GKE Dataplane V2:

Jalur paket melalui node menggunakan GKE Dataplane V2.

GKE men-deploy pengontrol GKE Dataplane V2 sebagai DaemonSet bernama anetd ke setiap node dalam cluster. anetd menginterpretasikan objek Kubernetes dan memprogram topologi jaringan di eBPF. Pod anetd berjalan di namespace kube-system.

GKE Dataplane V2 dan NetworkPolicy

GKE Dataplane V2 diimplementasikan menggunakan Cilium. Bidang data lama untuk GKE diimplementasikan menggunakan Calico.

Kedua teknologi ini mengelola NetworkPolicy Kubernetes. Cilium menggunakan eBPF dan Calico Container Network Interface (CNI) menggunakan iptables di kernel Linux.

Keuntungan GKE Dataplane V2

Skalabilitas

GKE Dataplane V2 memiliki karakteristik skalabilitas yang berbeda dengan bidang data lama.

Untuk versi GKE yang mana GKE Dataplane V2 tidak menggunakan kube-proxy dan tidak mengandalkan iptables untuk perutean layanan, GKE menghapus beberapa bottleneck iptables terkait, seperti jumlah Service.

GKE Dataplane V2 mengandalkan peta eBPF yang dibatasi hingga 260.000 endpoint di semua layanan.

Keamanan

Kubernetes NetworkPolicy selalu aktif dalam cluster dengan GKE Dataplane V2. Anda tidak perlu menginstal dan mengelola add-on software pihak ketiga seperti Calico untuk menerapkan kebijakan jaringan.

Operasi

Saat Anda membuat cluster dengan GKE Dataplane V2, logging kebijakan jaringan sudah terintegrasi. Konfigurasikan CRD logging di cluster Anda untuk melihat kapan koneksi diizinkan dan ditolak oleh Pod Anda.

Konsistensi

GKE Dataplane V2 memberikan pengalaman jaringan yang konsisten.

Untuk informasi selengkapnya, lihat Ketersediaan GKE Dataplane V2.

Spesifikasi teknis GKE Dataplane V2

GKE Dataplane V2 mendukung cluster dengan spesifikasi berikut:

Spesifikasi GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
Jumlah node per cluster 7.500 500 500
Jumlah Pod per cluster 200.000 15.000 27.500
Jumlah Pod di belakang satu Service 10.000 1.000 1.000
Jumlah Layanan IP Cluster 10.000 1.000 1.000
Jumlah Layanan LoadBalancer per cluster 750 500 1.000

GKE Dataplane V2 mengelola peta Layanan untuk melacak Layanan mana yang merujuk pada Pod sebagai backend-nya. Jumlah backend Pod untuk setiap Layanan yang dijumlahkan di seluruh Layanan harus sesuai dengan peta Layanan, yang dapat berisi hingga 260.000 entri. Jika batas ini terlampaui, cluster Anda mungkin tidak berfungsi sebagaimana mestinya.

Peningkatan batas node menjadi 7.500 di versi 1.31

Mulai Kubernetes versi 1.31, batas 5.000 node per cluster GKE Dataplane V2 telah dinaikkan menjadi 7.500. Kondisi yang sebelumnya diberlakukan pada cluster (batas 5.000 node) masih berlaku.

Peningkatan batas node menjadi 5.000 di versi 1.23

Mulai Kubernetes versi 1.23, batas 500 node per cluster GKE Dataplane V2 telah dinaikkan menjadi 5.000, dengan kondisi tambahan berikut diberlakukan pada cluster:

  • Cluster yang menggunakan Private Service Connect. Untuk memeriksa apakah cluster Anda menggunakan Private Service Connect, lihat Cluster dengan Private Service Connect.
  • Khusus cluster regional
  • Hanya cluster yang dibuat dengan GKE versi 1.23 atau yang lebih baru yang mengalami peningkatan batas 5.000 node. Cluster yang dibuat dengan versi GKE sebelumnya mungkin memerlukan penghapusan kuota ukuran cluster. Hubungi dukungan untuk mendapatkan bantuan.
  • Cluster yang menggunakan CRD Cilium (CiliumNetworkPolicy dan CiliumClusterwideNetworkPolicy) tidak dapat diskalakan hingga 5.000 node.

Layanan LoadBalancer di Google Distributed Cloud

Jumlah Layanan LoadBalancer yang didukung di Google Distributed Cloud bergantung pada mode load balancer yang digunakan. Google Distributed Cloud mendukung 500 Layanan LoadBalancer saat menggunakan mode load balancing paket (Seesaw) dan 250 saat menggunakan mode load balancing terintegrasi dengan F5. Untuk informasi selengkapnya, lihat Skalabilitas.

Batasan

GKE Dataplane V2 memiliki batasan berikut:

  • GKE Dataplane V2 hanya dapat diaktifkan saat membuat cluster baru. Cluster yang ada tidak dapat diupgrade untuk menggunakan GKE Dataplane V2.
  • Pada GKE versi yang lebih lama dari 1.20.12-gke.500, jika mengaktifkan GKE Dataplane V2 dengan NodeLocal DNSCache, Anda tidak dapat mengonfigurasi Pod dengan dnsPolicy: ClusterFirstWithHostNet, atau Pod Anda akan mengalami error resolusi DNS.
  • Mulai GKE versi 1.21.5-gke.1300, GKE Dataplane V2 tidak mendukung CiliumNetworkPolicy atau CiliumClusterwideNetworkPolicy CRD API. Mulai GKE versi 1.28.6-gke.1095000 dan 1.29.1-gke.1016000, Anda dapat mengaktifkan CiliumClusterwideNetworkPolicy di cluster baru atau yang sudah ada.
  • Load Balancer Jaringan passthrough internal yang dibuat secara manual yang terkait dengan Service jenis NodePort tidak didukung.
  • Karena GKE Dataplane V2 mengoptimalkan pemrosesan paket kernel eBPF menggunakan eBPF, performa Pod Anda mungkin terpengaruh jika Anda memiliki beban kerja dengan churn Pod yang tinggi. Fokus utama GKE Dataplane V2 adalah untuk mencapai eBPF yang optimal.
  • Ada masalah umum pada Service multi-cluster dengan beberapa port (TCP/UDP) di GKE Dataplane V2. Untuk informasi selengkapnya, lihat Service MCS dengan beberapa port.
  • GKE Dataplane V2 menggunakan cilium, bukan kube-proxy, untuk mengimplementasikan Service Kubernetes. kube-proxy dikelola dan dikembangkan oleh komunitas Kubernetes, sehingga fitur baru untuk Service kemungkinan besar akan diimplementasikan di kube-proxy sebelum diimplementasikan di cilium untuk GKE Dataplane V2. Salah satu contoh fitur Layanan yang pertama kali diimplementasikan di kube-proxy adalah KEP-1669: Endpoint Penghentian Proxy.
  • Untuk Layanan NodePort yang menjalankan versi 1.25 atau yang lebih lama menggunakan rentang SNAT dan PUPI default, Anda harus menambahkan rentang PUPI Pod di nonMasqueradeCIDRs di ConfigMap ip-masq-agent untuk menghindari masalah konektivitas.
  • Dalam kasus tertentu, Pod agen GKE Dataplane V2 (anetd) dapat menggunakan resource CPU dalam jumlah yang signifikan, hingga dua atau tiga vCPU per instance. Hal ini terjadi saat ada volume koneksi TCP tinggi yang dibuka dan ditutup dengan cepat pada node. Untuk mengurangi masalah ini, sebaiknya terapkan keep-alive untuk panggilan HTTP dan penggabungan koneksi untuk workload yang relevan.
  • Cluster GKE Dataplane V2 yang menjalankan panel kontrol versi 1.27 atau yang lebih lama tidak mendukung kolom .spec.internalTrafficPolicy Layanan. Kebijakan traffic internal yang efektif untuk layanan adalah Cluster; backend di node mana pun dianggap sebagai kandidat untuk resolusi Layanan. Untuk mengetahui informasi selengkapnya tentang kolom ini, lihat Kebijakan Traffic Internal Layanan.
  • GKE Dataplane V2 menggunakan eBPF untuk mengelola traffic jaringan cluster Anda. Jika Anda menginstal aplikasi pihak ketiga yang juga menggunakan eBPF, aplikasi tersebut dapat mengganggu GKE Dataplane V2. Misalnya, menggunakan Retina dengan GKE Dataplane V2 dapat mencegah Pod Anda terhubung ke Layanan. Hal ini terjadi karena program eBPF Retina dapat mengganggu cara GKE Dataplane V2 merutekan traffic. Jika Anda melihat pesan error yang menunjukkan bahwa traffic dihapus karena mencoba menjangkau alamat IP Layanan secara langsung, Anda mungkin mengalami masalah ini. Hal ini karena Pod tidak diizinkan untuk mengakses alamat IP Layanan secara langsung dan traffic harus melalui mekanisme perutean Dataplane V2. Untuk mengetahui informasi selengkapnya, lihat Masalah inkompatibilitas Retina.

GKE Dataplane V2 dan kube-proxy

GKE Dataplane V2 tidak menggunakan kube-proxy kecuali pada node pool Windows Server pada GKE versi 1.25 dan yang lebih lama.

Penerapan kebijakan jaringan tanpa GKE Dataplane V2

Lihat Menggunakan penerapan kebijakan jaringan untuk mendapatkan petunjuk cara mengaktifkan penerapan kebijakan jaringan di cluster yang tidak menggunakan GKE Dataplane V2.

Langkah selanjutnya