Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Kuota dan batas

Halaman ini menjelaskan kuota dan batas rilis 1.29 Google Distributed Cloud untuk project, cluster, dan node Google Cloud.

Batas

Bagian berikut menguraikan beberapa batasan dasar untuk cluster Anda. Pertimbangkan batasan ini saat mendesain aplikasi untuk berjalan di Google Distributed Cloud.

Cluster pengguna maksimum 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 yang sedang berlangsung, cluster admin dapat secara andal mendukung maksimum 100 cluster pengguna yang masing-masing memiliki 10 node untuk total 1.000 node.

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 menjadi 75 atau kurang. Demikian pula, jika ingin menjalankan 110 pod per node, Anda harus membatasi jumlah node dalam cluster 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 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 maksimal 500 node. Namun, untuk memastikan performa dan keandalan yang optimal, sebaiknya Anda tidak 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 workload pada node. Untuk mengetahui detailnya, baca taint dan toleransi Kubernetes.

Jumlah maksimum pod per node

Google Distributed Cloud mendukung konfigurasi pod maksimum 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 level cluster untuk 100.000 endpoint. Jumlah ini adalah jumlah semua pod yang dirujuk oleh layanan Kubernetes. Jika dua layanan mereferensikan kumpulan pod yang sama, situasi ini dihitung sebagai dua kumpulan endpoint terpisah. Implementasi nftable yang mendasarinya pada RHEL menyebabkan batasan 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 iptables lama pada cluster skala besar.

GKE Dataplane V2

Google Distributed Cloud menggunakan GKE Dataplane V2, dataplane cluster yang diimplementasikan dengan Cilium dan eBPF, yang dioptimalkan untuk jaringan Kubernetes.

Batas `NetworkPolicy` GKE Dataplane V2

GKE Dataplane V2 menggunakan Cilium untuk mengelola resource NetworkPolicy Kubernetes. 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 terjadi, misalnya setiap detik, atau jumlah identitas Cilium (kumpulan label unik) tidak mendekati batas: 16.000 set label dengan kebijakan jaringan allow all, atau 65.535 set label per cluster.
Jumlah maksimum endpoint Layanan per cluster	100.000 endpoint adalah batas yang telah diuji dan direkomendasikan. Batas hardcode untuk endpoint Service adalah 262.000.
Jumlah maksimum kebijakan dan aturan jaringan	Maksimal 40.000 kebijakan jaringan dan 80.000 aturan. Misalnya, Anda dapat menetapkan 40.000 kebijakan jaringan dengan dua aturan masing-masing, atau menetapkan 20.000 kebijakan dengan empat aturan masing-masing.
Tingkat perubahan maksimum untuk kebijakan jaringan	Maksimal 20 perubahan (pembuatan atau penghapusan) per detik.
Jumlah maksimum kumpulan label pod unik	65.535 (2¹⁶-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 hal berikut: identitas keamanan, port, 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 pantau 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 juga pipeline pemantauan Anda 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 LoadBalancer dan Layanan NodePort

Batas port untuk Layanan LoadBalancer dan NodePort adalah 2.768. Rentang port default adalah 30000-32767. Jika melebihi batas, Anda tidak dapat membuat Layanan LoadBalancer atau NodePort baru, dan 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 port node yang tersedia dari 2.768 yang dialokasikan ke cluster Anda. Untuk menyimpan port node, nonaktifkan alokasi port node load balancer dengan menetapkan kolom allocateLoadBalancerNodePorts ke false di spesifikasi LoadBalancer Service. Setelan ini mencegah Kubernetes mengalokasikan port node ke Layanan LoadBalancer. Untuk mengetahui informasi selengkapnya, baca 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 paket load balancing (MetalLB) adalah 28.000. Rentang port efemeral default untuk koneksi ini adalah 32768-60999. Jika Anda melebihi batas koneksi, permintaan ke Layanan LoadBalancer mungkin 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 keterbatasan ini dengan MetalLB.

Kuota cluster

Anda dapat mendaftarkan maksimal 15 cluster secara default. Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirim permintaan untuk meningkatkan kuota di Konsol Google Cloud:

Buka Quotas

Informasi penskalaan

Informasi dalam dokumen ini relevan untuk merencanakan cara meningkatkan skala cluster Anda. 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 belum disertakan.