Halaman ini diterjemahkan oleh Cloud Translation API.

Skalabilitas

Halaman ini menjelaskan praktik terbaik untuk membuat, mengonfigurasi, dan mengoperasikan cluster yang dibuat menggunakan Google Distributed Cloud (khusus software) untuk VMware guna mengakomodasi workload yang mendekati batas skalabilitas Kubernetes.

Aturan penamaan cluster

Untuk setiap Google Cloud project:

Setiap cluster pengguna harus memiliki nama unik di semua cluster admin yang berada dalam satu project. Google Cloud

Batas skalabilitas

Perhatikan batas berikut saat mendesain aplikasi Anda:

Jika cluster lanjutan tidak diaktifkan:
- Setiap cluster admin mendukung hingga 100 cluster pengguna, termasuk cluster pengguna dengan ketersediaan tinggi (HA) dan non-HA, menggunakan mode load balancing yang dipaketkan (MetalLB), atau (load balancer manual).
- Setiap cluster pengguna mendukung hingga:
  - 500 node menggunakan mode load balancing paket (MetalLB)
  - 15.000 Pod
  - 500 Layanan LoadBalancer menggunakan mode load balancing paket (MetalLB).
- Untuk setiap node, Anda dapat membuat maksimal 110 Pod (setiap Pod dapat terdiri dari 1-2 container). Hal ini mencakup Pod yang menjalankan layanan sistem add-on.
Jika cluster lanjutan diaktifkan
- Setiap cluster admin mendukung hingga 100 cluster pengguna, cluster pengguna harus berupa cluster dengan ketersediaan tinggi (HA), menggunakan mode load balancing yang dipaketkan (MetalLB), atau (load balancer manual).
- Setiap cluster pengguna mendukung hingga:
  - 500 node menggunakan mode load balancing paket (MetalLB).
  - 15.000 Pod
  - 500 Layanan LoadBalancer menggunakan mode load balancing paket (MetalLB).
- Untuk setiap node, Anda dapat membuat maksimal 110 Pod (setiap Pod dapat terdiri dari 1-2 container). Hal ini mencakup Pod yang menjalankan layanan sistem add-on.
- Jumlah total node yang mencakup node bidang kontrol cluster admin + semua node bidang kontrol cluster pengguna + worker node tidak boleh melebihi 500 node.

Memahami batas

Karena Google Distributed Cloud adalah sistem yang kompleks dengan permukaan integrasi yang besar, skalabilitas cluster melibatkan banyak dimensi yang saling terkait. Misalnya, Google Distributed Cloud dapat melakukan penskalaan melalui jumlah node, Pod, atau Layanan. Meregangkan lebih dari satu dimensi sekaligus dapat menyebabkan masalah bahkan di cluster yang lebih kecil. Misalnya, menjadwalkan 110 Pod per node dalam cluster 500 node dapat melampaui jumlah Pod, Pod per node, dan node.

Lihat Batas skalabilitas Kubernetes untuk mengetahui detail selengkapnya.

Batas skalabilitas juga sensitif terhadap konfigurasi vSphere dan hardware tempat cluster Anda berjalan. Batas ini diverifikasi di lingkungan yang kemungkinan berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak mereproduksi angka yang sama persis jika lingkungan yang mendasarinya menjadi faktor pembatas.

Bersiap untuk melakukan penskalaan

Saat Anda bersiap untuk menskalakan cluster admin atau cluster pengguna, pertimbangkan persyaratan dan batasan berikut.

Persyaratan CPU, memori, dan penyimpanan

Lihat persyaratan CPU, RAM, dan penyimpanan untuk setiap VM.

Persyaratan I/O disk dan jaringan

Workload yang intensif data dan komponen bidang kontrol tertentu sensitif terhadap latensi I/O disk dan jaringan. Misalnya, 500 IOPS berurutan (misalnya, SSD lokal umum atau perangkat blok virtual berperforma tinggi) biasanya diperlukan untuk performa dan stabilitas etcd dalam cluster dengan puluhan node dan ribuan Pod.

Alamat IP node

Setiap node memerlukan satu alamat IP yang ditetapkan secara statis atau DHCP.

Misalnya, 307 alamat IP diperlukan dalam penyiapan dengan satu cluster pengguna non-HA dengan 50 node dan satu cluster pengguna HA dengan 250 node.

Tabel berikut menunjukkan perincian alamat IP:

Node type	Jumlah alamat IP
VM bidang kontrol cluster admin	3
VM bidang kontrol cluster pengguna 1 (non-HA)	1
VM node pekerja cluster pengguna 1	50
VM bidang kontrol cluster pengguna 2 (HA)	3
VM node pekerja cluster pengguna 2	250
Total	307

Menjalankan banyak cluster pengguna di cluster admin

Saat Anda bersiap untuk menjalankan banyak cluster pengguna di cluster admin, lakukan langkah-langkah berikut saat membuat cluster admin.

Blok CIDR Pod di cluster admin

Blok CIDR Pod adalah blok CIDR untuk semua Pod di cluster admin. Hal ini dikonfigurasi melalui kolom network.podCIDR di admin-cluster.yaml.

Dari rentang ini, blok /24 yang lebih kecil ditetapkan ke setiap node. Jika semua cluster pengguna Anda telah mengaktifkan Controlplane V2, maka cluster admin Anda hanya memiliki tiga node, dan ada banyak alamat IP Pod yang tersedia. Namun, setiap kali Anda membuat cluster pengguna yang menggunakan kubeception alih-alih Controlplane V2, satu atau tiga node akan ditambahkan ke cluster admin:

Setiap cluster pengguna kubeception dengan ketersediaan tinggi (HA) menambahkan tiga node ke cluster admin.
Setiap cluster pengguna kubeception non-HA menambahkan satu node ke cluster admin.

Jika Anda memerlukan cluster admin N node, Anda harus memastikan blok CIDR Pod cukup besar untuk mendukung N blok /24.

Tabel berikut menjelaskan jumlah maksimum node yang didukung oleh berbagai ukuran blok CIDR Pod:

Ukuran blok CIDR Pod	Jumlah maksimum node yang didukung
/18	64
/17	128
/16	256
/15	512

Blok CIDR Pod default cluster admin adalah 192.168.0.0/16, yang mendukung 256 node.

Di cluster admin dengan 100 cluster pengguna kubeception HA, ada 3 node bidang kontrol cluster admin dan 300 node bidang kontrol cluster pengguna. Jumlah total node adalah 303 (lebih dari 256). Oleh karena itu, Anda harus memperbarui blok CIDR Pod menjadi /15 untuk mendukung hingga 100 cluster pengguna kubeception HA.

Untuk mengonfigurasi blok CIDR Pod, tetapkan kolom network.podCIDR di file konfigurasi cluster admin.

Blok CIDR layanan di cluster admin

Blok CIDR Service adalah blok CIDR untuk semua Layanan di cluster admin. Konfigurasi dilakukan melalui kolom network.serviceCIDR di admin-cluster.yaml.

Tabel berikut menjelaskan jumlah maksimum Layanan yang didukung oleh berbagai ukuran blok CIDR Layanan:

Ukuran blok CIDR layanan	Jumlah maksimum Layanan yang didukung
/24	256
/23	512
/22	1.024

Nilai defaultnya adalah 10.96.232.0/24, yang mendukung 256 layanan.

Setiap cluster pengguna kubeception menggunakan 6 Layanan, dan bidang kontrol cluster admin menggunakan 14 Layanan. Oleh karena itu, untuk menjalankan 100 cluster pengguna kubeception, Anda harus mengubah blok CIDR Layanan di cluster admin agar menggunakan rentang /22.

Cloud Logging dan Cloud Monitoring untuk cluster pengguna kubeception

Cloud Logging dan Cloud Monitoring membantu Anda melacak resource.

Penggunaan CPU dan memori komponen logging dan pemantauan yang di-deploy di cluster admin akan diskalakan sesuai dengan jumlah cluster pengguna kubeception.

Tabel berikut menjelaskan jumlah CPU dan memori node cluster admin yang diperlukan untuk menjalankan sejumlah besar cluster pengguna kubeception:

Jumlah cluster pengguna kubeception	CPU node cluster admin	Memori node cluster admin
0 hingga 10	4 CPU	16 GB
11 hingga 20	4 CPU	32 GB
20 hingga 100	4 CPU	90GB

Misalnya, jika ada 2 node cluster admin dan masing-masing memiliki 4 CPU dan memori 16 GB, Anda dapat menjalankan 0 hingga 10 cluster pengguna kubeception. Untuk membuat lebih dari 20 cluster pengguna kubeception, Anda harus mengubah ukuran memori node cluster admin terlebih dahulu dari 16 GB menjadi 90 GB.

Mengelola node cluster admin saat cluster lanjutan diaktifkan

Penggunaan CPU dan memori komponen siklus proses yang di-deploy dalam cluster admin akan diskalakan sesuai dengan jumlah total semua node (Jumlah total node yang mencakup node bidang kontrol cluster admin + semua node bidang kontrol cluster pengguna + node pekerja)

Tabel berikut menjelaskan jumlah CPU dan memori node cluster admin yang diperlukan untuk menjalankan sejumlah besar semua node yang dikelolanya:

Jumlah total node	CPU node cluster admin	Memori node cluster admin
0 hingga 20	4 CPU	16 GB
21 hingga 100	8 CPU	16 GB
101 sampai 500	16 CPU	32 GB

Misalnya, jika ada 3 node cluster admin dan masing-masing memiliki 4 CPU dan memori 16 GB, Anda dapat menjalankan satu cluster pengguna HA dengan 14 node pekerja. Untuk membuat lebih dari 20 cluster pengguna lanjutan, dengan setiap cluster pengguna memiliki lebih dari 10 node, Anda harus mengubah ukuran memori node cluster admin dari 16 GB menjadi 32 GB terlebih dahulu.

GKE Hub

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 :

Buka Kuota

Untuk mengetahui informasi selengkapnya tentang kuota cluster berdasarkan setelan keanggotaan, lihat Kuota alokasi.

Menjalankan banyak node dan pod di cluster pengguna

Saat Anda bersiap untuk menjalankan banyak node dan pod di cluster pengguna, lakukan langkah-langkah berikut saat membuat cluster pengguna.

Blok CIDR Pod di cluster pengguna

Blok CIDR Pod adalah blok CIDR untuk semua Pod di cluster pengguna. Hal ini dikonfigurasi melalui kolom network.podCIDR di user-cluster.yaml.

Dari rentang ini, blok /24 yang lebih kecil ditetapkan ke setiap node. Jika Anda memerlukan cluster N node, Anda harus memastikan blok ini cukup besar untuk mendukung blok N /24.

Tabel berikut menjelaskan jumlah maksimum node yang didukung oleh berbagai ukuran blok CIDR Pod:

Ukuran blok CIDR Pod	Jumlah maksimum node yang didukung
/18	64
/17	128
/16	256
/15	512

Blok CIDR Pod default adalah 192.168.0.0/16, yang mendukung 256 node. Misalnya, untuk membuat cluster dengan 500 node, Anda harus mengubah blok CIDR Pod di cluster pengguna agar menggunakan rentang /15.

Blok CIDR layanan di cluster pengguna

Blok CIDR Layanan adalah blok CIDR untuk semua Layanan di cluster pengguna. Fitur ini dikonfigurasi melalui kolom network.serviceCIDR di user-cluster.yaml.

Tabel berikut menjelaskan jumlah maksimum Layanan yang didukung oleh berbagai ukuran blok CIDR Layanan:

Ukuran blok CIDR layanan	Jumlah maksimum Layanan yang didukung
/21	2.048
/20	4.096
/19	8.192
/18	16.384

Node bidang kontrol cluster pengguna

Penggunaan memori komponen bidang kontrol cluster pengguna diskalakan sesuai dengan jumlah node di cluster pengguna.

Tabel berikut memberikan CPU dan memori yang diperlukan oleh node bidang kontrol cluster pengguna, bergantung pada ukuran cluster pengguna:

Jumlah node cluster pengguna	CPU node bidang kontrol	Memori node bidang kontrol
0 hingga 20	3 CPU	5 GB
21 hingga 75	3 CPU	6GB
76 hingga 250	4 CPU	8 GB
251 hingga 500	4 CPU	16 GB

Misalnya, untuk membuat lebih dari 250 node di cluster pengguna, Anda harus menggunakan node bidang kontrol cluster pengguna dengan memori minimal 16 GB.

Spesifikasi node bidang kontrol cluster pengguna dapat diubah melalui kolom masterNode di user-cluster.yaml.

Dataplane v2

Untuk cluster pengguna 500 node yang menggunakan Dataplane V2, sebaiknya gunakan memori 120 GB dan 32 core CPU untuk node bidang kontrol cluster pengguna.

Cloud Logging dan Cloud Monitoring

Cloud Logging dan Cloud Monitoring membantu Anda melacak resource.

Penggunaan CPU dan memori agen dalam cluster yang di-deploy di cluster pengguna akan diskalakan berdasarkan jumlah node dan Pod di cluster pengguna.

Komponen logging dan pemantauan cloud seperti prometheus-server dan stackdriver-prometheus-sidecar memiliki penggunaan resource CPU dan memori yang berbeda berdasarkan jumlah node dan jumlah Pod. Sebelum Anda menskalakan cluster, tetapkan permintaan dan batas resource sesuai dengan perkiraan penggunaan rata-rata komponen ini. Tabel berikut menunjukkan perkiraan jumlah penggunaan rata-rata untuk setiap komponen:

Jumlah node	Nama container	Perkiraan penggunaan CPU		Perkiraan penggunaan memori
Jumlah node	Nama container	0 pod/node	30 pod/node	0 pod/node	30 pod/node
3 hingga 50	prometheus-server	100m	390m	650 JUTA	1.3G
3 hingga 50	stackdriver-prometheus-sidecar	100m	340m	1,5G	1,6 G
51 hingga 100	prometheus-server	160m	500m	1,8 G	5.5G
51 hingga 100	stackdriver-prometheus-sidecar	200m	500m	1,9 G	5.7G
101 hingga 250	prometheus-server	400m	2.500 m	6,5 G	16G
101 hingga 250	stackdriver-prometheus-sidecar	400m	1.300 m	7,5G	12G
250 hingga 500	prometheus-server	1.200 m	2.600 m	22G	25G
250 hingga 500	stackdriver-prometheus-sidecar	400m	2250m	65G	78G

Pastikan Anda memiliki node yang cukup besar untuk menjadwalkan komponen Cloud Logging dan Cloud Monitoring. Salah satu cara untuk melakukannya adalah dengan membuat cluster kecil terlebih dahulu, mengedit resource komponen Cloud Logging dan Cloud Monitoring sesuai dengan tabel di atas, membuat node pool untuk mengakomodasi komponen, lalu menskalakan cluster secara bertahap ke ukuran yang lebih besar.

Anda dapat memilih untuk mempertahankan kumpulan node yang cukup besar untuk komponen pemantauan dan pencatatan log guna mencegah pod lain dijadwalkan ke kumpulan node. Untuk melakukannya, Anda harus menambahkan taint berikut ke node pool:

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

Hal ini mencegah komponen lain dijadwalkan di kumpulan node dan mencegah workload pengguna dikeluarkan karena konsumsi resource komponen pemantauan.

Load Balancer

Layanan yang dibahas di bagian ini mengacu pada Layanan Kubernetes dengan jenis LoadBalancer.

Ada batasan jumlah node dalam cluster Anda, dan jumlah Layanan yang dapat Anda konfigurasi di load balancer.

Untuk load balancing gabungan (Seesaw), ada juga batasan jumlah health check. Jumlah pemeriksaan kesehatan bergantung pada jumlah node dan jumlah layanan lokal traffic. Layanan lokal traffic adalah Layanan yang externalTrafficPolicy-nya ditetapkan ke Local.

Tabel berikut menjelaskan jumlah maksimum Layanan, node, dan pemeriksaan kondisi untuk Load balancing gabungan (Seesaw) dan Load balancing terintegrasi (F5):

	Load balancing gabungan (Seesaw)	Load balancing terintegrasi (F5)
Max Services	500	250 ²
Node maks	500	250 ²
Pemeriksaan kesehatan maksimum	N + (L * N) <= 10 ribu, dengan N adalah jumlah node, dan L adalah jumlah layanan lokal traffic ¹	T/A ²

¹ Misalnya, Anda memiliki 100 node dan 99 Layanan lokal traffic. Jumlah health check adalah 100 + (99 * 100) = 10.000, yang berada dalam batas 10 ribu.

² Hubungi F5 untuk mengetahui informasi selengkapnya. Jumlah ini dipengaruhi oleh faktor-faktor seperti nomor model hardware F5, CPU/memori instance virtual, dan lisensi.

Komponen sistem penskalaan otomatis

Google Distributed Cloud otomatis menskalakan komponen sistem di cluster pengguna sesuai dengan jumlah node tanpa perlu Anda mengubah konfigurasi. Anda dapat menggunakan informasi di bagian ini untuk perencanaan sumber daya.

Google Distributed Cloud secara otomatis melakukan penskalaan vertikal dengan menskalakan permintaan/batas CPU dan memori komponen sistem berikut menggunakan addon-resizer:
- kube-state-metrics adalah Deployment yang berjalan di node pekerja cluster yang memantau server Kubernetes API dan menghasilkan metrik tentang status objek. Skala permintaan dan batas CPU serta memori berdasarkan jumlah node.
  
  Tabel berikut menjelaskan permintaan/batas resource yang ditetapkan oleh sistem, mengingat jumlah node dalam cluster:
  
  Jumlah node Perkiraan¹ permintaan/batas CPU (mili) Permintaan/batas memori perkiraan¹ (Mi)
  
  3 hingga 5 105 110
  
  6 hingga 500 100 + num_nodes 100 + (2 * num_nodes)
  
  ¹ Ada margin +-5% untuk mengurangi jumlah mulai ulang komponen selama penskalaan.
  
  Misalnya, dalam cluster dengan 50 node, permintaan/batas CPU ditetapkan ke 150m/150m dan permintaan/batas memori ditetapkan ke 200Mi/200Mi. Dalam cluster dengan 250 node, permintaan/batas CPU ditetapkan ke 350m/350m dan permintaan/batas memori ditetapkan ke 600Mi.
- metrics-server adalah deployment yang berjalan di node pekerja cluster yang digunakan oleh pipeline penskalaan otomatis bawaan Kubernetes. Permintaan dan batas CPU dan memori diskalakan berdasarkan jumlah node.
Google Distributed Cloud secara otomatis melakukan penskalaan horizontal di cluster admin dan cluster pengguna dengan menskalakan jumlah replika komponen sistem berikut:
- core-dns adalah solusi DNS yang digunakan untuk penemuan layanan. Cluster ini berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika sesuai dengan jumlah node dan core CPU dalam cluster. Dengan setiap penambahan/penghapusan 16 node atau 256 core, 1 replika akan ditambah/dikurangi. Jika Anda memiliki cluster dengan N node dan C core, Anda dapat mengharapkan max(N/16, C/256) replika.
- calico-typha adalah komponen untuk mendukung jaringan Pod. Cluster ini berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika calico-typha berdasarkan jumlah node dalam cluster:
  
  Jumlah node (N) Jumlah replika calico-typha
  
  N = 1 1
  1 < N < 200 2
  N >= 200 3 atau lebih
- Istio ingress-gateway adalah komponen untuk mendukung ingress cluster, dan berjalan sebagai Deployment di node pekerja cluster pengguna. Bergantung pada jumlah traffic yang ditangani ingress-gateway, Google Distributed Cloud menggunakan Horizontal Pod Autoscaler untuk menskalakan jumlah replika berdasarkan penggunaan CPU-nya, dengan minimal 2 replika dan maksimal 5 replika.
- Proxy jaringan konnectivity (KNP) menyediakan proxy tingkat TCP untuk keluar dari node bidang kontrol cluster pengguna. Fitur ini membuat tunnel traffic keluar kube-apiserver pengguna yang ditujukan ke node cluster pengguna. Agen Konnectivity berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika agen konnectivity berdasarkan jumlah node dalam cluster.
  
  Jumlah node (N) Jumlah replika agen konektivitas
  
  1 <= N <= 6 N
  6 < N < 10 6
  10 <= N < 100 8
  N >= 100 12 atau lebih

Jumlah node	Perkiraan¹ permintaan/batas CPU (mili)	Permintaan/batas memori perkiraan¹ (Mi)
3 hingga 5	105	110
6 hingga 500	100 + num_nodes	100 + (2 * num_nodes)

Jumlah node (N)	Jumlah replika calico-typha
N = 1	1
1 < N < 200	2
N >= 200	3 atau lebih

Jumlah node (N)	Jumlah replika agen konektivitas
1 <= N <= 6	N
6 < N < 10	6
10 <= N < 100	8
N >= 100	12 atau lebih

Praktik terbaik

Bagian ini menjelaskan praktik terbaik untuk menskalakan resource Anda.

Menskalakan cluster Anda secara bertahap

Pembuatan node Kubernetes melibatkan pengkloningan template image OS node ke dalam file disk baru, yang merupakan operasi vSphere yang intensif I/O. Tidak ada isolasi I/O antara operasi clone dan operasi I/O beban kerja. Jika terlalu banyak node yang dibuat secara bersamaan, operasi clone akan membutuhkan waktu lama untuk selesai dan dapat memengaruhi performa dan stabilitas cluster serta workload yang ada.

Pastikan cluster diskalakan secara bertahap, bergantung pada resource vSphere Anda. Misalnya, untuk mengubah ukuran cluster dari 3 menjadi 500 node, pertimbangkan untuk menskalakannya secara bertahap dari 150 menjadi 350, lalu menjadi 500, yang akan membantu mengurangi beban pada infrastruktur vSphere.

Mengoptimalkan performa I/O disk etcd

etcd adalah penyimpanan nilai kunci yang digunakan sebagai penyimpanan pendukung Kubernetes untuk semua data cluster. Performa dan stabilitasnya sangat penting bagi kondisi cluster dan sensitif terhadap latensi I/O disk dan jaringan.

Optimalkan performa I/O datastore vSphere yang digunakan untuk VM control plane dengan mengikuti rekomendasi berikut:
- Ikuti persyaratan hardware etcd.
- Gunakan SSD atau penyimpanan flash.
Latensi beberapa ratus milidetik menunjukkan adanya hambatan pada I/O disk atau jaringan dan dapat mengakibatkan cluster tidak responsif. Pantau dan tetapkan nilai minimum pemberitahuan untuk metrik latensi I/O etcd berikut:
- etcd_disk_backend_commit_duration_seconds
- etcd_disk_wal_fsync_duration_seconds

Mengoptimalkan performa I/O disk booting node

Pod menggunakan penyimpanan efemeral untuk operasi internalnya, seperti menyimpan file sementara. Penyimpanan efemeral digunakan oleh lapisan yang dapat ditulis container, direktori log, dan volume emptyDir. Penyimpanan efemeral berasal dari sistem file node, yang didukung oleh boot disk node.

Karena tidak ada isolasi I/O penyimpanan di node Kubernetes, aplikasi yang menggunakan I/O yang sangat tinggi pada penyimpanan sementara dapat menyebabkan ketidakstabilan node dengan membuat komponen sistem seperti Kubelet dan daemon Docker kekurangan sumber daya.

Pastikan karakteristik performa I/O dari datastore tempat disk booting disediakan dapat memberikan performa yang tepat untuk penggunaan penyimpanan sementara dan traffic logging aplikasi.

Memantau pertentangan resource fisik

Perhatikan rasio vCPU ke pCPU dan overkomitmen memori. Rasio yang tidak optimal atau pertentangan memori di host fisik dapat menyebabkan penurunan performa VM. Anda harus memantau penggunaan resource fisik di tingkat host dan mengalokasikan resource yang cukup untuk menjalankan cluster besar Anda.