Skalabilitas

Halaman ini menjelaskan praktik terbaik untuk membuat, mengonfigurasi, dan mengoperasikan GKE pada cluster VMware untuk mengakomodasi workload yang mendekati batas skalabilitas Kubernetes.

Aturan nama cluster

Untuk setiap project Google Cloud:

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

Batas skalabilitas

Pertimbangkan batasan berikut saat mendesain aplikasi Anda di GKE di VMware:

Memahami batas

Karena GKE di VMware adalah sistem kompleks dengan platform integrasi yang besar, skalabilitas cluster melibatkan banyak dimensi yang saling terkait. Misalnya, GKE di VMware dapat menskalakan melalui jumlah node, Pod, atau Layanan. Meregangkan lebih dari satu dimensi sekaligus dapat menyebabkan masalah, bahkan dalam cluster yang lebih kecil. Misalnya, menjadwalkan 110 Pod per node di 500 cluster node dapat melebihi jumlah Pod, Pod per node, dan node.

Lihat nilai minimum Skalabilitas Kubernetes untuk mengetahui detail selengkapnya.

Batas skalabilitas juga sensitif terhadap konfigurasi vSphere dan hardware yang dijalankan cluster Anda. Batasan ini diverifikasi di lingkungan yang kemungkinan berbeda dengan lingkungan Anda. Oleh karena itu, Anda tidak dapat mereproduksi jumlah yang tepat jika lingkungan yang mendasarinya adalah faktor pembatas.

Bersiap untuk mengatur skala

Ketika 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 intensif data dan komponen bidang kontrol tertentu sensitif terhadap latensi I/O jaringan dan disk. Misalnya, 500 IOPS berurutan (misalnya, SSD lokal biasa 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 GKE pada VMware memerlukan satu DHCP atau alamat IP yang ditetapkan secara statis.

Misalnya, 308 alamat IP diperlukan dalam penyiapan dengan satu cluster pengguna non-HA dengan 50 node dan satu cluster pengguna dengan ketersediaan tinggi (HA) dengan 250 node.

Tabel berikut menunjukkan pengelompokan alamat IP:

Jenis node Jumlah alamat IP
VM bidang kontrol cluster admin 1
VM node addon cluster admin 3
VM bidang kontrol cluster pengguna 1 (non-HA) 1
VM cluster 1 node pengguna 50
VM bidang kontrol cluster pengguna 2 (HA) 3
VM cluster pengguna 2 node 250
Total 308

Menjalankan banyak cluster pengguna dalam cluster admin

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

Pemblokiran CIDR pod di cluster admin

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

Dari rentang ini, blok yang lebih kecil /24 ditetapkan ke setiap node. Jika memerlukan cluster admin node N, 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 pada cluster admin adalah 192.168.0.0/16, yang mendukung 256 node.

Dalam sebuah cluster admin dengan 100 cluster pengguna dengan ketersediaan tinggi (HA), (setiap cluster pengguna memiliki 3 node bidang kontrol), ada 1 node bidang kontrol cluster admin, 2 node add-on cluster admin, dan 300 node bidang kontrol cluster pengguna. Jumlah total node adalah 303 (lebih dari 256). Oleh karena itu, Anda harus mengupdate blok CIDR Pod ke /15 untuk mendukung hingga 100 cluster pengguna dengan ketersediaan tinggi (HA).

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

Pemblokiran CIDR layanan di cluster admin

Blok CIDR Layanan adalah blok CIDR untuk semua Layanan di cluster admin. Konfigurasi ini dikonfigurasi 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 menggunakan 6 Layanan, dan bidang kontrol cluster admin menggunakan 14 Layanan. Oleh karena itu, agar dapat menjalankan 100 cluster pengguna, Anda harus mengubah blok CIDR Layanan di cluster admin agar menggunakan rentang /22.

Cloud Logging dan Cloud Monitoring

Cloud Logging dan Cloud Monitoring membantu melacak resource Anda.

Penggunaan CPU dan memori pada komponen logging dan pemantauan yang di-deploy dalam skala cluster admin sesuai dengan jumlah cluster pengguna.

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

Jumlah cluster pengguna 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. Untuk membuat lebih dari 20 cluster pengguna, Anda harus mengubah ukuran memori node cluster admin terlebih dahulu dari 16 GB menjadi 90 GB.

Untuk mengubah memori node add-on cluster admin, edit konfigurasi MachineDeployment:

  1. Jalankan perintah berikut:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    dengan ADMIN_CLUSTER_KUBECONFIG adalah jalur file kubeconfig untuk cluster admin Anda.

  2. Ubah kolom spec.template.spec.providerSpec.value.machineVariables.memory menjadi 32768.

  3. Simpan hasil edit. Node cluster admin dibuat ulang dengan memori 32 GB.

GKE Hub

Secara default, Anda dapat mendaftarkan maksimum 15 cluster pengguna.

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

 [Go to Quotas](https://console.cloud.google.com/apis/api/gkehub.googleapis.com/quotas){: target="console"
 class="button button-primary" track-type="quotas" track-name="consoleLink" track-metadata-end-goal="modifyQuota"}

Menjalankan banyak node dan pod dalam cluster pengguna

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

Pemblokiran CIDR pod di cluster pengguna

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

Dari rentang ini, blok /24 yang lebih kecil ditetapkan ke setiap {i>node<i}. Jika memerlukan cluster node N, 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.

Pemblokiran CIDR layanan di cluster pengguna

Blok CIDR Layanan adalah blok CIDR untuk semua Layanan di cluster pengguna. Class 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

Nilai defaultnya adalah 10.96.0.0/20, yang mendukung 4.096 layanan. Blok CIDR Layanan default memungkinkan Anda membuat cluster dengan 500 Layanan, yang merupakan jumlah maksimum GKE Services jenis LoadBalancer di VMware yang didukung dalam sebuah cluster pengguna.

Node bidang kontrol cluster pengguna

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

Tabel berikut menunjukkan 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 tahun 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 sebesar 120 GB dan 32 core CPU untuk node bidang kontrol cluster pengguna.

Cloud Logging dan Cloud Monitoring

Cloud Logging dan Cloud Monitoring membantu melacak resource Anda.

Penggunaan CPU dan memori agen dalam cluster yang di-deploy pada skala cluster pengguna dalam hal jumlah node dan Pod dalam cluster pengguna.

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

Jumlah node Nama container Perkiraan penggunaan CPU Perkiraan penggunaan memori
0 pod/node 30 pod/node 0 pod/node 30 pod/node
3 hingga 50 prometheus-server 100 mnt 390m 650 JT 1,3G
stackdriver-prometheus-sidecar 100 mnt 340m 1.5G 1,6 gram
51 hingga 100 prometheus-server 160m 500m 1,8 gram 5.5G
stackdriver-prometheus-sidecar 200 mnt 500m 1,9 gram 5,7 gram
101 hingga 250 prometheus-server 400m 2.500 m 6.5G 16 gram
stackdriver-prometheus-sidecar 400m 1.300 m 7.5G 12 gram
250 hingga 500 prometheus-server 1.200 m 2.600 m 22 gram 25G
stackdriver-prometheus-sidecar 400m 2.250 m 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 kumpulan node untuk mengakomodasi komponen, lalu secara bertahap meningkatkan skala cluster ke ukuran yang lebih besar.

Anda dapat memilih untuk mempertahankan kumpulan node yang cukup besar untuk komponen pemantauan dan logging agar pod lain tidak dijadwalkan ke kumpulan node. Untuk melakukannya, Anda harus menambahkan taint berikut ke kumpulan node:

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

Hal ini mencegah komponen lain dijadwalkan pada kumpulan node dan mencegah beban kerja pengguna dihapus karena konsumsi resource komponen pemantauan.

Load Balancer

Layanan yang dibahas di bagian ini merujuk ke 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 paket (Seesaw), ada juga batas jumlah health check. Jumlah health check bergantung pada jumlah node dan jumlah traffic Layanan lokal. Layanan lokal traffic adalah Layanan yang memiliki externalTrafficPolicy yang ditetapkan ke Local.

Tabel berikut menjelaskan jumlah maksimum Layanan, node, dan health check untuk Bundled load balancing (Seesaw) dan Integrated load balancing (F5):

Load balancing paket (Seesaw) Load balancing terintegrasi (F5)
Layanan Maks 500 250 2
Node maks 500 250 2
Health check maks N + (L * N) <= 10K, dengan N adalah jumlah node, dan L adalah jumlah traffic layanan lokal 1 T/A 2

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

2 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

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

  • GKE di VMware otomatis melakukan penskalaan vertikal dengan menskalakan permintaan/batas CPU dan memori pada komponen sistem berikut menggunakan addon-resizer:

    • kube-state-metrics adalah Deployment yang berjalan pada node pekerja cluster yang memantau server Kubernetes API dan menghasilkan metrik tentang status objek. Permintaan CPU dan memori serta batas skala berdasarkan jumlah node.

      Tabel berikut menjelaskan permintaan/batas resource yang ditetapkan oleh sistem, berdasarkan jumlah node dalam cluster:

      Jumlah node Perkiraan1 permintaan/batas CPU (mili) Perkiraan1 permintaan/batas memori (Mi)
      3 hingga 5 105 110
      6 hingga 500 100 + jml_node 100 + (2 * num_node)

      1 Ada margin +-5% untuk mengurangi jumlah komponen yang dimulai ulang selama penskalaan.

      Misalnya, dalam cluster dengan 50 node, permintaan/batas CPU ditetapkan ke 150 m/150 m dan permintaan/batas memori ditetapkan ke 200 Mi/200 Mi. Dalam cluster dengan 250 node, permintaan/batas CPU ditetapkan ke 350 m/350 m dan permintaan/batas memori ditetapkan ke 600 Mi.

    • metrics-server adalah deployment yang berjalan pada node worker cluster yang digunakan oleh pipeline penskalaan otomatis bawaan Kubernetes. Permintaan CPU dan memori serta membatasi skala berdasarkan jumlah node.

  • GKE di VMware 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 pada GKE di VMware. Solusi ini berjalan sebagai Deployment pada node pekerja cluster pengguna. GKE di VMware akan otomatis menskalakan jumlah replika sesuai dengan jumlah node dan inti CPU dalam cluster. Dengan setiap penambahan/penghapusan 16 node atau 256 core, 1 replika ditingkatkan/dikurangi. Jika Anda memiliki cluster N node dan C core, Anda dapat mengharapkan max(N/16, C/256) replika.

    • calico-typha adalah komponen untuk mendukung jaringan Pod pada GKE di VMware. Solusi ini berjalan sebagai Deployment pada node pekerja cluster pengguna. GKE di VMware akan otomatis menskalakan jumlah replika 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 cluster ingress, dan berjalan sebagai Deployment pada node pekerja cluster pengguna. Bergantung pada jumlah traffic ingress-gateway yang ditangani, GKE di VMware menggunakan Horizontal Pod Autoscaler untuk menskalakan jumlah replika berdasarkan penggunaan CPU, dengan minimal 2 replika dan maksimal 5 replika.

    • Proxy jaringan (KNP) konnectivity menyediakan proxy level TCP untuk traffic keluar dari node bidang kontrol cluster pengguna. Layanan ini men-tunnel traffic keluar pengguna kube-apiserver yang ditujukan ke node cluster pengguna. Agen Konnectivity dijalankan sebagai Deployment pada node pekerja cluster pengguna. GKE di VMware akan otomatis menskalakan jumlah replika agen kontras berdasarkan jumlah node dalam cluster.

      Jumlah node (N) Jumlah replika agen kontras
      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 cloning template image OS node ke dalam file disk baru, yang merupakan operasi vSphere intensif I/O. Tidak ada isolasi I/O antara operasi clone dan operasi I/O workload. Jika ada terlalu banyak node yang dibuat secara bersamaan, operasi clone memerlukan waktu lama untuk diselesaikan dan dapat memengaruhi performa serta stabilitas cluster dan beban kerja 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 dalam tahapan dari 150 menjadi 350 hingga 500, yang akan membantu mengurangi beban pada infrastruktur vSphere.

Mengoptimalkan performa I/O disk etcd

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

  • Optimalkan performa I/O datastore vSphere yang digunakan untuk VM bidang kontrol dengan mengikuti rekomendasi berikut:

  • Latensi beberapa ratus milidetik menunjukkan bottleneck pada disk atau I/O jaringan dan dapat menyebabkan cluster yang 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 boot disk node

Pod menggunakan penyimpanan efemeral untuk operasi internalnya, seperti menyimpan file sementara. Penyimpanan efemeral dipakai oleh lapisan writable container, direktori log, dan volume emptyDir. Penyimpanan efemeral berasal dari GKE pada sistem file node VMware, yang didukung oleh boot disk node.

Karena tidak ada isolasi I/O penyimpanan pada node Kubernetes, aplikasi yang menggunakan I/O yang sangat tinggi pada penyimpanan efemeralnya berpotensi menyebabkan ketidakstabilan node dengan membuat komponen sistem seperti Kubelet dan daemon docker resource.

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

Memantau pertentangan resource fisik

Perhatikan rasio vCPU ke pCPU dan overcommitment memori. Rasio yang kurang optimal atau pertentangan memori pada host fisik dapat menyebabkan penurunan performa VM. Anda harus memantau penggunaan resource fisik pada level host dan mengalokasikan resource yang cukup untuk menjalankan cluster besar.