Kuota dan batas

Halaman ini menjelaskan kuota dan batas GKE on Bare Metal rilis 1.16 untuk project, cluster, dan node Google Cloud.

Batas

Bagian berikut menguraikan beberapa batasan dasar untuk cluster Anda. Pertimbangkan batasan ini saat mendesain aplikasi Anda untuk dijalankan di GKE di Bare Metal.

Cluster pengguna maksimum per cluster admin

Cluster admin mengelola siklus proses untuk cluster pengguna dan node terkait. 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 berkelanjutan, cluster admin dapat mendukung secara andal maksimal 100 cluster pengguna yang memiliki 10 node masing-masing dengan 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 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 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 pod per rekomendasi cluster pengguna lebih diutamakan daripada rekomendasi untuk pod per node dan node per cluster pengguna dalam bagian berikut.

Jumlah maksimum node per cluster pengguna

Kami menguji GKE pada Bare Metal untuk menjalankan workload dengan maksimal 500 node. Namun, untuk memastikan performa dan keandalan yang optimal, sebaiknya jangan melebihi 200 node per cluster saat menjalankan beban kerja 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 tersebut. Untuk mengetahui detailnya, lihat taint dan toleransi Kubernetes.

Jumlah maksimum pod per node

GKE di Bare Metal mendukung konfigurasi pod maksimum per node dalam setelan nodeConfig.PodDensity.MaxPodsPerNode dari 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 pengguna dengan ketersediaan tinggi (HA) dan cluster pengguna tanpa ketersediaan tinggi (HA) 32 110 250
Semua cluster non-HA lainnya 64 110 250

Jumlah maksimum endpoint

Di RHEL dan CentOS, ada batasan tingkat cluster sebanyak 100.000 endpoint. Angka ini merupakan jumlah semua pod yang dirujuk oleh service Kubernetes. Jika dua layanan mereferensikan kumpulan pod yang sama, situasi ini dihitung sebagai dua kumpulan endpoint yang terpisah. Implementasi nftable yang mendasarinya pada RHEL dan CentOS menyebabkan batasan ini. Implementasi ini bukan merupakan batasan intrinsik GKE di Bare Metal.

Mitigasi

Untuk RHEL dan CentOS, tidak ada mitigasi. Untuk sistem Ubuntu dan Debian, sebaiknya beralih dari nftables default ke iptables lama pada cluster skala besar.

Batas eBPF Dataplane V2

Jumlah entri maksimum 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 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 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 NodePort Services

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 Anda tidak dapat menambahkan port node baru untuk layanan yang ada.

Secara default, Kubernetes mengalokasikan port node ke Layanan jenis LoadBalancer. Alokasi ini dapat menghabiskan port node yang tersedia dengan cepat dari 2.768 yang dialokasikan untuk 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 LoadBalancer Services. 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 paket

Jumlah koneksi yang diizinkan untuk setiap node yang digunakan untuk paket load balancing (MetalLB) adalah 28.000. Rentang port ephemeral default untuk koneksi ini adalah 32768-60999. Jika Anda melebihi batas koneksi, permintaan ke LoadBalancer Service mungkin akan 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

Anda dapat mendaftarkan maksimum 15 cluster secara default. Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirimkan permintaan untuk menambah kuota di Konsol Google Cloud:

Buka Quotas

Masalah penskalaan

Bagian ini menjelaskan beberapa masalah yang perlu diingat saat menskalakan cluster Anda.

Resource dicadangkan untuk daemon sistem

Mulai versi 1.14, GKE di Bare Metal otomatis mencadangkan resource pada node untuk daemon sistem seperti sshd atau udev. Resource CPU dan memori dicadangkan pada node untuk daemon sistem sehingga daemon ini memiliki resource yang dibutuhkan. Tanpa fitur ini, yang diaktifkan secara default, Pod berpotensi menggunakan sebagian besar resource pada sebuah node, sehingga daemon sistem tidak mungkin menyelesaikan tugasnya.

Secara khusus, GKE di Bare Metal mencadangkan 50 milicore CPU (50 mCPU) dan 280 Mebibyte (280 MiB) memori pada setiap node untuk daemon sistem. Perlu diketahui bahwa unit CPU 'mCPU' adalah singkatan dari "ribuan core", sehingga 50/1000 atau 5% dari core pada setiap node dicadangkan untuk daemon sistem. Jumlah resource yang dicadangkan berukuran kecil dan tidak berdampak signifikan terhadap performa Pod. Namun, kubelet pada sebuah node dapat mengeluarkan Pod jika penggunaan CPU atau memorinya melebihi jumlah yang telah dialokasikan untuk pod tersebut.

performa etcd

Kecepatan {i>disk<i} sangat penting untuk performa dan stabilitas etcd. Disk yang lambat meningkatkan latensi permintaan dll., yang dapat menyebabkan masalah stabilitas cluster. Untuk meningkatkan performa cluster, GKE di Bare Metal menyimpan objek Event dalam instance etcd khusus yang terpisah. Instance etcd standar menggunakan /var/lib/etcd sebagai direktori datanya dan port 2379 untuk permintaan klien. Instance etcd-events menggunakan /var/lib/etcd-events sebagai direktori data dan port 2382 untuk permintaan klien.

Sebaiknya gunakan disk solid-state (SSD) untuk penyimpanan etcd Anda. Untuk performa optimal, pasang disk terpisah ke /var/lib/etcd dan /var/lib/etcd-events. Menggunakan {i>disk<i} khusus memastikan bahwa dua instance {i>etcd<i} tidak berbagi IO {i>disk<i}.

Dokumentasi etcd memberikan rekomendasi hardware tambahan untuk memastikan performa etcd terbaik saat menjalankan cluster Anda dalam produksi.

Untuk memeriksa performa etcd dan disk, gunakan metrik latensi I/O etcd berikut di Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: durasinya harus kurang dari 25 milidetik untuk persentil ke-99 (p99).
  • etcd_disk_wal_fsync_duration_seconds: durasi harus kurang dari 10 milidetik untuk persentil ke-99 (p99).

Untuk mengetahui informasi selengkapnya tentang performa etcd, lihat Apa yang dimaksud dengan peringatan etcd "apply entries take terlalu lama"? dan Apa yang dimaksud dengan peringatan etcd "failed to send out heartbeat on time"?.

Tidak menemukan apa yang Anda cari? Klik Kirim masukan dan beri tahu kami apa saja yang kurang.