GKE Dataplane V2

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

Halaman ini mengasumsikan bahwa Anda mengetahui jaringan di dalam cluster GKE.

Ringkasan GKE Dataplane V2

GKE Dataplane V2 adalah bidang data yang dioptimalkan untuk jaringan Kubernetes. GKE Dataplane V2 menyediakan hal berikut:

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

Program eBPF kustom

GKE Dataplane V2 menggunakan program eBPF untuk mengelola traffic jaringan, termasuk perutean, load balancing, dan penegakan kebijakan jaringan. Karena program ini penting untuk konektivitas jaringan, GKE tidak mendukung penginstalan program eBPF kustom di node yang menggunakan GKE Dataplane V2. Program eBPF kustom dapat mengganggu program GKE Dataplane V2 dan dapat mengganggu jaringan cluster.

Keuntungan GKE Dataplane V2

GKE Dataplane V2 menawarkan manfaat berikut:

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 15.000 500 500
Jumlah Pod per cluster 400.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 Service untuk melacak Service mana yang merujuk pada Pod mana sebagai backend-nya. Jumlah backend Pod untuk setiap Service yang dijumlahkan di seluruh Service harus sesuai dengan peta Service, yang dapat berisi hingga 260.000 entri. Jika batas ini terlampaui, cluster Anda mungkin tidak berfungsi sebagaimana mestinya.

Batas node

Jumlah maksimum node per cluster bergantung pada lokasi cluster GKE Dataplane V2 Anda:

  • Cluster regional: Hingga 5.000, 15.000, atau 65.000 node per cluster. Tidak semua peningkatan node bersifat otomatis. Bergantung pada jumlah node target, ada persyaratan infrastruktur tertentu, dan Anda mungkin perlu menghubungi Cloud Customer Care. Penskalaan hingga 65.000 node memerlukan mode yang dioptimalkan untuk penskalaan Dataplane V2, yang menonaktifkan penerapan kebijakan jaringan. Untuk mengetahui informasi mendetail, lihat Persyaratan dan batas ukuran cluster.
  • Cluster zonal: Hingga 1.000 node.

Untuk mencapai batas penskalaan node di atas 5.000 node dalam cluster regional, lingkungan Anda harus memenuhi kondisi berikut:

  • Cluster Anda harus mengaktifkan Private Service Connect. Untuk memeriksa apakah cluster Anda menggunakan Private Service Connect, lihat Cluster dengan Private Service Connect.
  • Cluster yang menggunakan CRD CiliumNetworkPolicy dibatasi hingga batas cluster zonal hingga 1.000 node. Gunakan CRD CiliumClusterwideNetworkPolicy sebagai gantinya untuk mendukung penskalaan 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 mengetahui informasi selengkapnya, lihat Skalabilitas.

Dukungan Maglev

Untuk cluster GKE yang menjalankan versi 1.36.0-gke.2882000 dan yang lebih baru, Anda dapat mengonfigurasi Layanan untuk menggunakan algoritma hashing yang konsisten Maglev untuk pemilihan backend.

Secara default, Layanan Kubernetes menggunakan algoritma random untuk memilih backend. Algoritma random dapat menyebabkan koneksi yang sehat dialihkan dan direset saat set Pod backend berubah (misalnya, selama peristiwa penskalaan). Maglev memitigasi hal ini dengan terus merutekan traffic ke backend yang ditetapkan untuk koneksi selama backend tersebut tetap responsif, meskipun Pod lain ditambahkan atau dihapus.

Manfaat menggunakan algoritma Maglev

Menggunakan algoritma Maglev memberikan manfaat berikut:

  • Fitur ini dapat meningkatkan stabilitas koneksi dengan mengarahkan traffic untuk koneksi ke backend yang sama.
  • Hal ini dapat mengurangi masalah koneksi saat Pod backend ditambahkan atau dihapus—misalnya, selama Pod dimulai ulang.

Batasan penggunaan algoritma Maglev

Menggunakan algoritma Maglev mungkin membutuhkan banyak resource:

  • Hal ini dapat menyebabkan peningkatan penggunaan memori pada anetd di setiap cluster. Untuk mengetahui informasi selengkapnya, lihat bagian berikutnya, "Pertimbangan penggunaan memori Maglev".
  • Hal ini mungkin terkait dengan penggunaan CPU anetd yang lebih tinggi (hingga tiga kali lebih banyak) selama perubahan backend.

Pertimbangan penggunaan memori Maglev

Untuk melacak koneksi dan backend, algoritma Maglev menggunakan tabel hash: algoritma ini melakukan hashing pada 5-tuple paket (alamat IP sumber, alamat IP tujuan, port sumber, port tujuan, dan protokol).

Ukuran tabel referensi dikonfigurasi menjadi 16.381 entri. Karena setiap entri berukuran 4 byte, Layanan yang dikonfigurasi untuk menggunakan algoritma Maglev memerlukan 65,5 KB (16.381 × 4 byte) memori yang dapat dialokasikan setiap node.

Jumlah layanan dengan Maglev yang diaktifkan Penggunaan memori tambahan
100 6,5 MB
1.000 65 MB
10.000 650 MB

Menerapkan algoritma Maglev

Untuk menerapkan algoritma Maglev ke Service jenis NodePort atau LoadBalancer, tambahkan anotasi gke.networking.io/lb-algorithm: "maglev" ke metadata Service selama pembuatan Service.

Contoh:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Anotasi gke.networking.io/lb-algorithm berlaku selama pembuatan Layanan. Untuk mengubah algoritma Service yang ada, Anda harus menghapus dan membuat ulang Service. Mengubah nilai anotasi tanpa membuat ulang akan menyebabkan perilaku yang tidak konsisten. anetd pada node baru mencoba menggunakan algoritma yang baru dikonfigurasi, sementara Pod yang ada terus menggunakan algoritma sebelumnya.

Men-deploy workload dengan SCTP

Anda dapat men-deploy workload yang menggunakan Stream Control Transmission Protocol (SCTP) di cluster yang diaktifkan dengan GKE Dataplane V2. SCTP adalah protokol lapisan transport yang menyediakan transmisi berorientasi pesan yang andal. Untuk mengetahui informasi selengkapnya, lihat Men-deploy workload dengan SCTP.

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.
  • Load Balancer Jaringan passthrough internal yang dibuat secara manual yang terkait dengan Service jenis NodePort tidak didukung.
  • 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.
  • 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.

  • Penggunaan memori yang dilaporkan oleh Pod agen GKE Dataplane V2 (anetd) bergantung pada total memori yang tersedia di node. Node yang memiliki total memori yang lebih tinggi melaporkan penggunaan memori yang lebih tinggi untuk Pod anetd. Pod anetd sebenarnya tidak menggunakan lebih banyak memori; penggunaan yang dilaporkan meningkat karena metrik ini mencakup reservasi memori peta eBPF.

    Di GKE, reservasi memori untuk peta eBPF terbesar adalah 0,25% dari total memori node. Memori tambahan mungkin dicadangkan untuk fitur khusus GKE lainnya.

  • 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 dihentikan 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 ketidakcocokan Retina.

  • Paket ICMP yang terfragmentasi tidak didukung dan akan dihentikan oleh GKE Dataplane V2.

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 berikutnya