Skalabilitas

Halaman ini menjelaskan praktik terbaik untuk membuat, mengonfigurasi, dan mengoperasikan cluster yang dibuat menggunakan Google Distributed Cloud (khusus software) untuk VMware guna menampung beban kerja 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 batas berikut saat mendesain aplikasi Anda:

Memahami batas

Karena Google Distributed Cloud adalah sistem kompleks dengan platform integrasi yang besar, skalabilitas cluster melibatkan banyak dimensi yang saling terkait. Misalnya, Google Distributed Cloud dapat diskalakan melalui jumlah node, Pod, atau Layanan. Memperluas lebih dari satu dimensi sekaligus dapat menyebabkan masalah bahkan dalam cluster yang lebih kecil. Misalnya, menjadwalkan 110 Pod per node dalam cluster node 500 dapat membebani 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 dapat mereproduksi angka yang tepat jika lingkungan yang mendasarinya adalah faktor pembatas.

Menyiapkan 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

Beban kerja yang intensif data dan komponen bidang kontrol tertentu sensitif terhadap latensi I/O disk dan jaringan. 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 memerlukan satu alamat IP DHCP atau yang ditetapkan secara statis.

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 pengelompokan alamat IP:

Jenis node 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 2 cluster pengguna 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. 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, 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, bukan 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 memerlukan cluster admin node N, Anda harus memastikan blok CIDR Pod cukup besar untuk mendukung blok /24 N.

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 ke /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 Layanan adalah blok CIDR untuk semua Layanan di cluster admin. 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 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 untuk menggunakan rentang /22.

Cloud Logging dan Cloud Monitoring

Cloud Logging dan Cloud Monitoring membantu Anda melacak resource.

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

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

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 dari 16 GB menjadi 90 GB terlebih dahulu.

GKE Hub

Secara default, Anda dapat mendaftarkan maksimal 250 cluster dengan langganan 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 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. Ini dikonfigurasi melalui kolom network.podCIDR di user-cluster.yaml.

Dari rentang ini, blok /24 yang lebih kecil ditetapkan ke setiap node. 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.

Blok CIDR layanan di cluster pengguna

Blok CIDR Layanan adalah blok CIDR untuk semua Layanan di cluster pengguna. Kolom 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 platform kontrol cluster pengguna diskalakan sesuai dengan jumlah node di cluster pengguna.

Tabel berikut memberikan CPU dan memori yang diperlukan oleh node kontrol-platform 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 control plane 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 berskala dalam hal 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 menskalakan cluster, tetapkan permintaan dan batas resource sesuai dengan estimasi penggunaan rata-rata komponen ini. Tabel berikut menunjukkan estimasi untuk 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 100m 390m 650 JT 1,3G
stackdriver-prometheus-sidecar 100m 340m 1,5 G 1,6 G
51 hingga 100 prometheus-server 160m 500m 1,8 G 5,5G
stackdriver-prometheus-sidecar 200m 500m 1,9 G 5,7 G
101 hingga 250 prometheus-server 400m 2.500 m 6,5G 16G
stackdriver-prometheus-sidecar 400m 1.300 m 7,5G 12G
250 hingga 500 prometheus-server 1.200 m 2.600 m 22G 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 node pool untuk mengakomodasi komponen, lalu secara bertahap menskalakan cluster ke ukuran yang lebih besar.

Anda dapat memilih untuk mempertahankan node pool yang cukup besar untuk komponen pemantauan dan logging agar pod lain tidak dijadwalkan ke node pool. 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 dihapus karena penggunaan resource komponen pemantauan.

Load Balancer

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

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

Untuk load balancing yang dipaketkan (Seesaw), ada juga batas jumlah health check. Jumlah pemeriksaan kesehatan bergantung pada jumlah node dan jumlah traffic Jasa lokal. Layanan lokal traffic adalah Layanan yang menetapkan externalTrafficPolicy ke Local.

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

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

1 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.

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

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

  • Google Distributed Cloud secara otomatis melakukan penskalaan vertikal dengan menskalakan permintaan/batas CPU dan memori dari komponen sistem berikut menggunakan addon-resizer:

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

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

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

      1 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 600 Mi.

    • metrics-server adalah deployment yang berjalan di node pekerja cluster yang digunakan oleh pipeline penskalaan otomatis bawaan Kubernetes. Permintaan dan batas CPU serta memori disederhanakan 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. Aplikasi ini berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud 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 ditingkatkan/diturunkan. Jika memiliki cluster dengan N node dan C core, Anda dapat mengharapkan replika max(N/16, C/256).

    • calico-typha adalah komponen untuk mendukung jaringan Pod. Aplikasi ini berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud 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 oleh gateway masuk, Google Distributed Cloud menggunakan Horizontal Pod Autoscaler untuk menskalakan jumlah replika berdasarkan penggunaan CPU-nya, dengan minimum 2 replika dan maksimum 5 replika.

    • Proxy jaringan konektivitas (KNP) menyediakan proxy tingkat TCP untuk eksekusi keluar dari node bidang kontrol cluster pengguna. Tunnel ini menyalurkan traffic keluar kube-apiserver pengguna yang dituju ke node cluster pengguna. Agen konektivitas berjalan sebagai Deployment di node pekerja cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika agen konektivitas 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

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 yang intensif I/O. Tidak ada isolasi I/O antara operasi clone dan operasi I/O beban kerja. Jika ada terlalu banyak node yang dibuat secara bersamaan, operasi clone memerlukan waktu yang lama untuk selesai dan dapat memengaruhi performa serta stabilitas cluster dan 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 dalam tahap dari 150 menjadi 350 menjadi 500, yang 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 platform kontrol dengan mengikuti rekomendasi berikut:

  • Latensi beberapa ratus milidetik menunjukkan bottleneck pada disk atau I/O jaringan dan dapat menyebabkan 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 ditulisi, direktori log, dan volume emptyDir penampung. Penyimpanan efemeral berasal dari sistem file node, yang didukung oleh disk booting node.

Karena tidak ada isolasi I/O penyimpanan di node Kubernetes, aplikasi yang menggunakan I/O yang sangat tinggi pada penyimpanan sementaranya berpotensi menyebabkan ketidakstabilan node dengan mengurangi komponen sistem seperti Kubelet dan daemon Docker dari resource.

Pastikan karakteristik performa I/O 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 overcommit memori. Rasio yang kurang 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.