Halaman ini menjelaskan kuota dan batas Google Distributed Cloud (khusus software) di bare metal untuk Google Cloud project, cluster, dan node.
Batas
Bagian berikut menguraikan beberapa batas dasar untuk cluster Anda. Pertimbangkan batas ini saat mendesain aplikasi Anda untuk dijalankan di Google Distributed Cloud.
Jumlah maksimum cluster pengguna per cluster admin
Cluster admin mengelola siklus proses untuk cluster pengguna dan node terkaitnya. Cluster admin mengontrol operasi cluster pengguna yang penting, seperti pembuatan cluster, reset cluster atau node, upgrade cluster, dan update cluster. Jumlah total node cluster pengguna adalah salah satu faktor utama yang membatasi performa dan keandalan.
Berdasarkan pengujian berkelanjutan, cluster admin dapat mendukung maksimum 100 cluster pengguna yang masing-masing memiliki 10 node dengan total 1.000 node secara andal.
Jumlah maksimum pod per cluster pengguna
Sebaiknya batasi jumlah pod per cluster pengguna hingga 15.000 atau kurang. Misalnya, jika cluster Anda memiliki 200 node, Anda harus membatasi jumlah pod per node hingga 75 atau kurang. Demikian pula, jika Anda ingin menjalankan 110 pod per node, Anda harus membatasi jumlah node di cluster Anda menjadi 136 atau kurang. Tabel berikut memberikan contoh konfigurasi yang direkomendasikan dan tidak direkomendasikan.
| Pod per node | Node per cluster | Pod per Cluster | Hasil |
|---|---|---|---|
| 110 | 200 | 22.000 | Terlalu banyak pod, tidak direkomendasikan |
| 110 | 136 | 14.960 | Dalam batas |
| 100 | 150 | 15.000 | Dalam batas |
| 75 | 200 | 15.000 | Dalam batas |
Jumlah maksimum rekomendasi pod per cluster pengguna lebih diutamakan daripada rekomendasi untuk pod per node dan node per cluster pengguna di bagian berikut.
Jumlah maksimum node per cluster pengguna
Kami menguji Google Distributed Cloud untuk menjalankan workload dengan hingga 500 node. Namun, untuk memastikan performa dan keandalan yang optimal, sebaiknya Anda tidak melebihi 200 node per cluster saat menjalankan beban kerja dalam produksi.
| Jenis cluster | Node minimum | Jumlah node maksimum yang direkomendasikan | Node maksimum mutlak |
|---|---|---|---|
| Pengguna, Mandiri, atau Hybrid | 1 | 200 | 500 |
Untuk cluster satu node, Anda harus menghapus taint node-role.kubernetes.io/master:NoSchedule untuk menjalankan workload di node.
Untuk mengetahui detailnya, lihat
Taint dan toleransi Kubernetes.
Jumlah maksimum pod per node
Google Distributed Cloud mendukung konfigurasi jumlah maksimum pod per node dalam setelan nodeConfig.PodDensity.MaxPodsPerNode pada file konfigurasi cluster. Tabel
berikut menunjukkan nilai minimum dan maksimum yang didukung untuk
MaxPodsPerNode, yang mencakup pod yang menjalankan layanan add-on:
| Jenis cluster | Nilai minimum yang diizinkan | Nilai maksimum yang direkomendasikan | Nilai maksimum yang diizinkan |
|---|---|---|---|
| Semua cluster HA dan cluster pengguna non-HA | 32 | 110 | 250 |
| Semua cluster non-HA lainnya | 64 | 110 | 250 |
Jumlah maksimum endpoint
Di Red Hat Enterprise Linux (RHEL), ada batasan tingkat cluster sebanyak 100.000 endpoint. Jumlah ini adalah jumlah semua pod yang dirujuk oleh layanan Kubernetes. Jika dua layanan mereferensikan set pod yang sama, situasi ini dihitung sebagai dua set endpoint terpisah. Implementasi nftable
yang mendasarinya di RHEL menyebabkan batasan ini; ini bukan batasan intrinsik
Google Distributed Cloud.
Mitigasi
Untuk RHEL, tidak ada mitigasi. Untuk sistem Ubuntu dan Debian, sebaiknya beralih dari nftables default ke iptables warisan pada cluster skala besar.
GKE Dataplane V2
Google Distributed Cloud menggunakan GKE Dataplane V2, bidang data cluster yang diimplementasikan dengan Cilium dan eBPF, yang dioptimalkan untuk jaringan Kubernetes.
Batasan NetworkPolicy GKE Dataplane V2
GKE Dataplane V2 menggunakan Cilium untuk mengelola resource NetworkPolicy Kubernetes. Batas
berikut berlaku untuk cluster Anda:
| Dimensi | Batas yang didukung |
|---|---|
| Kecepatan perubahan maksimum untuk label namespace | Maksimal satu perubahan per jam untuk setiap namespace.
Dalam sebagian besar kasus, batas ini tidak diperlukan. Selama perubahan tidak sering terjadi, seperti setiap detik, atau jumlah identitas Cilium (kumpulan label unik) tidak mendekati batas: 16.000 kumpulan label dengan kebijakan jaringan izinkan semua, atau 65.535 kumpulan label per cluster. |
| Jumlah maksimum endpoint Service per cluster | 100.000 endpoint adalah batas yang telah diuji dan direkomendasikan. Batas yang di-hardcode untuk endpoint Layanan adalah 262.000. |
| Jumlah maksimum kebijakan dan aturan jaringan | Maksimal 40.000 kebijakan jaringan dan 80.000 aturan. Misalnya, Anda dapat menentukan 40.000 kebijakan jaringan dengan masing-masing dua aturan, atau Anda dapat menentukan 20.000 kebijakan dengan masing-masing empat aturan. |
| Kecepatan perubahan maksimum untuk kebijakan jaringan | Maksimal 20 perubahan (pembuatan atau penghapusan) per detik. |
| Jumlah maksimum set label pod unik | 65.535 (216-1). Ini adalah batas identitas keamanan Cilium. |
| Jumlah maksimum set label pod unik yang dipilih oleh pemilih kebijakan | 16.000 (ukuran peta eBPF tetap). Entri peta pemilih kebijakan tertentu terdiri dari: security-identity, port, dan protokol. |
Batas eBPF GKE Dataplane V2
Jumlah maksimum entri di lbmap BPF untuk Dataplane V2 adalah 65.536. Peningkatan di area berikut dapat menyebabkan jumlah total entri bertambah:
- Jumlah layanan
- Jumlah port per layanan
- Jumlah backend per layanan
Sebaiknya pantau jumlah entri sebenarnya yang digunakan oleh cluster Anda untuk memastikan Anda tidak melebihi batas. Gunakan perintah berikut untuk mendapatkan entri saat ini:
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
Sebaiknya Anda juga menggunakan pipeline pemantauan sendiri untuk mengumpulkan metrik
dari DaemonSet anetd. Pantau kondisi berikut untuk mengidentifikasi kapan jumlah entri menyebabkan masalah:
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
Batas port Layanan LoadBalancer dan NodePort
Batas port untuk Layanan LoadBalancer dan NodePort adalah 2.768. Rentang port default adalah 30000-32767. Jika Anda melampaui batas, Anda tidak dapat membuat Layanan LoadBalancer atau NodePort baru dan Anda tidak dapat menambahkan port node baru untuk layanan yang ada.
Secara default, Kubernetes mengalokasikan port node ke Service jenis LoadBalancer.
Alokasi ini dapat dengan cepat menghabiskan port node yang tersedia dari 2.768 yang dialokasikan ke cluster Anda. Untuk menghemat port node, nonaktifkan alokasi port node load balancer dengan menetapkan kolom allocateLoadBalancerNodePorts ke false di spesifikasi Layanan LoadBalancer.
Setelan ini mencegah Kubernetes mengalokasikan port node ke Layanan LoadBalancer. Untuk mengetahui informasi selengkapnya, lihat
Menonaktifkan alokasi NodePort load balancer
dalam dokumentasi Kubernetes.
Gunakan perintah berikut untuk memeriksa jumlah port yang dialokasikan:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Batas koneksi node load balancer gabungan
Jumlah koneksi yang diizinkan untuk setiap node yang digunakan untuk load balancing gabungan (MetalLB) adalah 28.000. Rentang port ephemeral default untuk koneksi ini adalah 32768-60999. Jika Anda melebihi batas koneksi, permintaan ke Layanan LoadBalancer dapat gagal.
Jika Anda perlu mengekspos layanan load balancer yang mampu menangani sejumlah besar koneksi (misalnya, untuk Ingress), sebaiknya pertimbangkan metode load balancing alternatif untuk menghindari batasan ini dengan MetalLB.
Kuota cluster
Secara default, Anda dapat mendaftarkan maksimum 250 cluster dengan keanggotaan global per fleet. Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirimkan permintaan untuk meningkatkan kuota di konsol Google Cloud :
Untuk mengetahui informasi selengkapnya tentang kuota cluster berdasarkan setelan keanggotaan, lihat Kuota alokasi.
Informasi penskalaan
Informasi dalam dokumen ini relevan untuk merencanakan cara menskalakan cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Menskalakan cluster Google Distributed Cloud.
Tidak menemukan apa yang Anda cari? Klik Kirim masukan dan beri tahu kami apa yang tidak ada.