Halaman ini menjelaskan kuota rilis 1.30 Google Distributed Cloud batas untuk project, cluster, dan node Google Cloud.
Batas
Bagian berikut menguraikan beberapa batasan dasar untuk cluster Anda. Lihat batasan yang diperhitungkan saat mendesain aplikasi untuk berjalan di Google Distributed Cloud.
Cluster pengguna maksimum per cluster admin
Cluster admin mengelola siklus proses untuk cluster pengguna dan yang terkait node. Cluster admin mengontrol operasi cluster pengguna yang penting, seperti cluster pembuatan, reset cluster atau node, upgrade cluster, dan update cluster. Tujuan jumlah total node cluster pengguna adalah salah satu faktor utama yang membatasi performa dan keandalan.
Berdasarkan pengujian yang sedang berlangsung, cluster admin dapat secara andal mendukung maksimum 100 cluster pengguna yang masing-masing memiliki 10 node dengan total 1.000 node.
Jumlah maksimum pod per cluster pengguna
Sebaiknya batasi jumlah pod per cluster pengguna hingga 15.000 atau lebih sedikit. Misalnya, jika cluster Anda memiliki 200 node, Anda harus membatasi jumlah pod per node menjadi 75 atau kurang. Demikian pula, jika Anda ingin menjalankan 110 pod per {i>node<i}, Anda harus membatasi jumlah {i>node<i} dalam cluster Anda menjadi 136 atau lebih sedikit. Tabel berikut memberikan contoh konfigurasi yang 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 pod per rekomendasi cluster pengguna akan lebih diprioritaskan daripada rekomendasi untuk pod per node dan node per cluster pengguna pada: bagian.
Jumlah maksimum node per cluster pengguna
Kami menguji Google Distributed Cloud untuk menjalankan workload dengan maksimal 500 node. Namun, untuk memastikan performa dan keandalan yang optimal, sebaiknya Anda melebihi 200 node per cluster saat menjalankan workload dalam produksi.
| Jenis cluster | Node minimum | Node maksimum yang direkomendasikan | Node maksimum absolut |
|---|---|---|---|
| Pengguna, Mandiri, atau Hybrid | 1 | 200 | 500 |
Untuk cluster node tunggal, Anda harus menghapus
Taint node-role.kubernetes.io/master:NoSchedule untuk menjalankan beban kerja pada node.
Untuk mengetahui detailnya, lihat
Taint dan toleransi Kubernetes.
Jumlah maksimum pod per node
Google Distributed Cloud mendukung konfigurasi pod maksimum per node di
setelan nodeConfig.PodDensity.MaxPodsPerNode untuk konfigurasi cluster
file. Tujuan
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 klaster sejumlah
100.000 endpoint. Jumlah ini adalah jumlah semua pod yang dirujuk oleh
layanan Kubernetes. Jika dua layanan merujuk ke kumpulan pod yang sama,
situasi ini dianggap sebagai dua
kumpulan titik akhir yang terpisah. nftable yang mendasari
implementasi pada RHEL menyebabkan keterbatasan ini; itu bukan batasan intrinsik
Google Distributed Cloud.
Mitigasi
Untuk RHEL, tidak ada mitigasi. Untuk sistem Ubuntu dan Debian, sebaiknya
beralih dari nftables default ke versi lama
iptables aktif
cluster skala besar.
GKE Dataplane V2
Google Distributed Cloud menggunakan GKE Dataplane V2, sebuah cluster dataplane yang diimplementasikan dengan Cilium dan eBPF, yang dioptimalkan untuk Kubernetes berjejaring (netrworking){b>.<b}
Batas NetworkPolicy GKE Dataplane V2
GKE Dataplane V2 menggunakan Cilium untuk mengelola resource NetworkPolicy Kubernetes. Tujuan
batas berikut berlaku untuk cluster Google Distributed Cloud Anda:
| Dimensi | Batas yang didukung |
|---|---|
| Tingkat perubahan maksimum untuk label namespace | Maksimal satu perubahan per jam untuk setiap namespace.
Biasanya, batas ini tidak diperlukan. Selama perubahan tidak sering, seperti setiap detik, atau jumlah identitas Silium (kumpulan label unik) tidak mendekati batas: 16.000 kumpulan label dengan izinkan semua kebijakan jaringan, atau 65.535 kumpulan label per cluster. |
| Jumlah maksimum endpoint Layanan per cluster | 100.000 endpoint adalah batas yang telah diuji dan direkomendasikan. Kode {i>hardcode<i} batas untuk endpoint Layanan adalah 262.000. |
| Jumlah maksimum kebijakan dan aturan jaringan | Maksimal 40.000 kebijakan jaringan dan 80.000 aturan. Sebagai contoh, Anda dapat menentukan 40.000 kebijakan jaringan dengan masing-masing dua aturan, atau Anda dapat menetapkan 20.000 kebijakan masing-masing dengan empat aturan. |
| Tingkat perubahan maksimum untuk kebijakan jaringan | Maksimal 20 perubahan (pembuatan atau penghapusan) per detik. |
| Jumlah maksimum kumpulan label pod unik | 65.535 (216-1). Batas 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 berikut ini: identitas keamanan, porta, dan protokol. |
Batas eBPF GKE Dataplane V2
Jumlah maksimum entri dalam 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 Anda memantau jumlah entri sebenarnya yang digunakan oleh cluster Anda untuk memastikan bahwa 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 gunakan pipeline pemantauan Anda sendiri untuk mengumpulkan metrik
dari DaemonSet anetd. Pantau kondisi berikut untuk mengidentifikasi
kapan jumlah entri yang 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 LoadBalancer dan Layanan NodePort
Batas port untuk Layanan LoadBalancer dan NodePort adalah 2.768. Default
rentang portnya adalah 30000-32767. Jika melebihi batas, Anda tidak dapat membuat
Layanan LoadBalancer atau NodePort dan Anda tidak dapat menambahkan port node baru untuk
layanan yang ada.
Secara default, Kubernetes mengalokasikan port node ke Services jenis LoadBalancer.
Alokasi ini dapat dengan cepat menghabiskan porta {i>node<i} yang tersedia dari 2.768
yang dialokasikan ke cluster Anda. Untuk menyimpan port node, nonaktifkan port node load balancer
alokasi dengan menetapkan kolom allocateLoadBalancerNodePorts ke false di
spesifikasi Layanan LoadBalancer.
Setelan ini mencegah Kubernetes mengalokasikan port node ke LoadBalancer
Layanan. Untuk 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 yang dipaket
Jumlah koneksi yang diizinkan untuk setiap node yang digunakan untuk load balancing yang dipaketkan (MetalLB) adalah 28.000. Rentang porta {i>ephemeral<i} {i>default<i} untuk koneksi ini adalah 32768-60999. Jika Anda melebihi batas koneksi, permintaan ke LoadBalancer Layanan mungkin gagal.
Jika Anda perlu mengekspos layanan load balancer yang mampu menangani dalam jumlah besar (misalnya untuk Ingress), sebaiknya Anda mempertimbangkan metode load balancing alternatif untuk menghindari batasan ini dengan MetalLB.
Kuota cluster
Secara default, Anda dapat mendaftarkan maksimal 250 cluster dengan keanggotaan global per fleet. Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirimkan permintaan ke meningkatkan kuota Anda 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 bagaimana meningkatkan klaster. Untuk mengetahui informasi selengkapnya, lihat Meningkatkan skala cluster Google Distributed Cloud.
Tidak menemukan apa yang Anda cari? Klik Kirim masukan dan beri tahu kami apa yang kurang.