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 nama cluster

Untuk setiap project Google Cloud:

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

Batas skalabilitas

Pertimbangkan batasan berikut saat mendesain aplikasi:

Memahami batasan

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

Lihat Nilai minimum skalabilitas Kubernetes untuk detail selengkapnya.

Batas skalabilitas juga sensitif terhadap konfigurasi dan hardware vSphere cluster Anda berjalan. Batasan ini diverifikasi di lingkungan yang mungkin berbeda dari Anda. Oleh karena itu, Anda mungkin tidak mereproduksi jumlah yang sama persis ketika lingkungan yang mendasarinya adalah faktor pembatas.

Mempersiapkan 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 intensif data dan komponen bidang kontrol tertentu sensitif terhadap dan latensi I/O jaringan dan disk. Misalnya, 500 IOPS berurutan (misalnya, SSD lokal standar atau perangkat blok virtual berperforma tinggi) biasanya yang diperlukan untuk performa dan stabilitas etcd di cluster yang memiliki puluhan node dan ribuan Pod.

Alamat IP node

Setiap {i>node<i} memerlukan satu DHCP atau alamat IP 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 menampilkan perincian 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 cluster pengguna 2 250
Total 307

Menjalankan banyak cluster pengguna dalam cluster admin

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

Blok CIDR pod di cluster admin

Blok CIDR Pod adalah blok CIDR untuk semua Pod di cluster admin. Penting dikonfigurasikan 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 memiliki Pesawat Kontrol V2 maka cluster admin Anda hanya memiliki tiga node, dan ada banyak Alamat IP pod tersedia. Namun, setiap kali Anda membuat cluster pengguna yang menggunakan kubeception bukan Controlplane V2, satu atau tiga node ditambahkan ke cluster admin:

  • Setiap cluster pengguna kubeception ketersediaan tinggi (HA) menambahkan tiga node ke ke cluster admin.

  • Setiap cluster pengguna kubeception non-HA menambahkan satu node ke cluster admin.

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

Tabel berikut ini 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 dari cluster admin adalah 192.168.0.0/16, mendukung 256 node.

Dalam sebuah klaster admin dengan 100 cluster pengguna Kubernetes, ada 3 admin node bidang kontrol cluster dan 300 node bidang kontrol cluster pengguna. Total jumlah {i>node <i}adalah 303 (lebih dari 256). Oleh karena itu, Anda harus mengupdate CIDR Pod ke /15 untuk mendukung hingga 100 klaster pengguna Kubernetes HA.

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

Blok CIDR layanan di cluster admin

Blok CIDR Service 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 ukuran blok CIDR Layanan yang berbeda:

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 kontrol cluster admin menggunakan 14 Layanan. Oleh karena itu, untuk menjalankan 100 kubeception user Anda harus mengubah blok CIDR Layanan di cluster admin untuk menggunakan rentang /22.

Cloud Logging dan Cloud Monitoring

Cloud Logging dan Cloud Monitoring membantu melacak resource Anda.

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

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

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 16 GB memori, Anda dapat menjalankan 0 hingga 10 kelompok pengguna {i>kubeception<i}. Untuk membuat lebih dari 20 cluster pengguna kubeception, Anda harus terlebih dahulu mengubah ukuran memori node cluster admin dari 16 GB hingga 90 GB.

GKE Hub

Secara default, Anda dapat mendaftarkan maksimal 250 cluster dengan keanggotaan global per fleet. Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirimkan permintaan ke meningkatkan kuota Anda 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 bersiap menjalankan banyak node dan pod di cluster pengguna, lakukan tindakan langkah-langkah berikut saat membuat cluster pengguna.

Blok CIDR pod di cluster pengguna

Blok CIDR Pod adalah blok CIDR untuk semua Pod dalam cluster pengguna. Penting dikonfigurasikan melalui kolom network.podCIDR di user-cluster.yaml.

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

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. Sebagai misalnya, untuk membuat cluster dengan 500 node, Anda harus mengubah blok CIDR Pod di cluster pengguna untuk menggunakan rentang /15.

Blok CIDR layanan di cluster pengguna

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

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

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 jumlah node dalam cluster pengguna.

Tabel berikut membahas CPU dan memori yang diperlukan oleh cluster pengguna node bidang kontrol, 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-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 dengan memori minimal 16 GB.

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

Dataplane v2

Untuk cluster pengguna 500 node yang menggunakan Dataplane V2, kami merekomendasikan memori 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 di cluster pengguna melakukan penskalaan 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 Anda meningkatkan cluster, tetapkan batas dan permintaan resource sesuai dengan estimasi penggunaan rata-rata komponen-komponen ini. Tabel berikut menampilkan estimasi untuk jumlah rata-rata penggunaan untuk setiap komponen:

Jumlah node Nama container Estimasi 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,6G
51 hingga 100 prometheus-server 160 mnt 500m 1,8G 5,5G
stackdriver-prometheus-sidecar 200 mnt 500m 1,9G 5,7G
101 hingga 250 prometheus-server 400m 2.500 m 6,5G 16 g
stackdriver-prometheus-sidecar 400m 1.300 m 7,5G 12 g
250 hingga 500 prometheus-server 1.200 m 2.600 m 22 g 25 g
stackdriver-prometheus-sidecar 400m 2.250 m 65 gr 78 g

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

Anda dapat memilih untuk mempertahankan kumpulan {i>node<i} yang cukup besar untuk pemantauan dan komponen logging untuk mencegah pod lain 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 dikeluarkan karena komponen pemantauan untuk konsumsi resource.

Load Balancer

Layanan yang dibahas pada bagian ini merujuk 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 yang dipaketkan (Seesaw), ada juga batas jumlah health check. Jumlah health check bergantung pada jumlah node dan jumlah traffic Jasa dan Servis. {i>Traffic lokal Service<i} adalah Layanan yang memiliki externalTrafficPolicy yang ditetapkan ke Local.

Tabel berikut menjelaskan jumlah maksimum Layanan, node, dan respons pemeriksaan Paket load balancing (Seesaw) dan Load balancing terintegrasi (F5):

Load balancing paket (Seesaw) Load balancing terintegrasi (F5)
Layanan Maksimum 500 250 2
Node maksimum 500 250 2
Health check maksimal N + (L * N) <= 10K, dengan N adalah jumlah node, dan L adalah jumlah traffic jasa dan servis 1 T/A 2

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

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

Komponen sistem penskalaan otomatis

Google Distributed Cloud secara otomatis menskalakan komponen sistem pada aktivitas pengguna cluster sesuai dengan jumlah {i>node<i} tanpa perlu Anda ubah konfigurasi standar. Anda dapat menggunakan informasi di bagian ini untuk referensi perencanaan.

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

    • kube-state-metrics adalah Deployment yang berjalan pada worker node cluster yang memproses server Kubernetes API dan menghasilkan metrik terkait status objek. Permintaan CPU dan memori serta membatasi skala berdasarkan jumlah node.

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

      Jumlah node Sekitar1 permintaan/batas CPU (mili) Sekitar1 permintaan/batas memori (Mi)
      3 hingga 5 105 110
      6 hingga 500 100 + num_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 150m/150m dan permintaan/batas memori diatur ke 200Mi/200Mi. Di cluster dengan 250 node, permintaan/batas CPU diatur ke 350 m/350 m dan permintaan/batas memori diatur ke 600Mi.

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

  • Google Distributed Cloud secara otomatis melakukan penskalaan horizontal di admin dan klaster pengguna dengan menskalakan jumlah replika komponen sistem berikut:

    • core-dns adalah solusi DNS yang digunakan untuk penemuan layanan. Menjalankan sebagai Deployment pada worker node 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 meningkat/berkurang. Jika memiliki cluster yang terdiri dari N node dan C inti, Anda dapat max(N/16, C/256) replika akan diperlukan.

    • calico-typha adalah komponen untuk mendukung jaringan Pod. Menjalankan sebagai Deployment pada worker node 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 < T < 200 2
      N >= 200 3 atau lebih

    • Istio ingress-gateway adalah komponen untuk mendukung traffic masuk cluster, dan berjalan sebagai Deployment pada worker cluster pengguna node. Tergantung pada jumlah lalu lintas gateway masuk yang ditangani, Google Distributed Cloud menggunakan Horizontal Pod Autoscaler untuk melakukan penskalaan jumlah replika berdasarkan penggunaan CPU mereka, dengan minimal 2 replika, dan maksimum 5 replika.

    • Proxy jaringan konnectivity (KNP) menyediakan proxy level TCP untuk traffic keluar dari node bidang kontrol cluster pengguna. Alat ini melakukan tunneling kube-apiserver keluar traffic yang ditujukan ke cluster pengguna node. Agen Konnektivitas berjalan sebagai Deployment pada worker cluster pengguna node. Google Distributed Cloud secara otomatis menskalakan replika agen konektivitas berdasarkan jumlah node dalam cluster.

      Jumlah node (N) Jumlah replika agen konektivitas
      1 <= N <= 6 N
      6 < T < 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 node OS menjadi file {i>disk<i} baru, yang merupakan operasi {i> vSphere<i} intensif I/O. Tidak ada I/O isolasi antara operasi clone dan operasi I/O workload. Jika ada terlalu banyak node yang dibuat bersamaan, operasi clone memerlukan waktu penyelesaian yang lama serta dapat memengaruhi performa dan stabilitas cluster dan workload yang ada.

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

Mengoptimalkan performa I/O disk etcd

dll. adalah penyimpanan nilai kunci yang digunakan sebagai penyimpanan pendukung untuk semua cluster layanan otomatis dan data skalabel. Performa dan stabilitasnya sangat penting untuk kesehatan cluster dan sensitif terhadap latensi I/O disk dan jaringan.

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

  • Latensi beberapa ratus milidetik menunjukkan bottleneck pada disk atau jaringan I/O dan dapat menghasilkan klaster yang tidak sehat. Pantau dan setel pemberitahuan nilai minimum untuk metrik latensi I/O dll. 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 data sementara . Penyimpanan ephemeral digunakan oleh lapisan container yang dapat ditulis, yaitu log direktori, dan volume emptyDir. Penyimpanan efemeral berasal dari sistem file node, yang didukung oleh {i>boot disk<i} dari node.

Karena tidak ada isolasi I/O penyimpanan pada node Kubernetes, aplikasi yang mengonsumsi I/O yang sangat tinggi pada penyimpanan efemeralnya berpotensi menyebabkan {i>node<i} akibat kelaparan komponen sistem seperti Kubelet dan {i>daemon Docker <i}dari Google Cloud Platform.

Pastikan bahwa karakteristik performa I/O datastore di mana yang disediakan dapat memberikan kinerja yang tepat untuk penggunaan penyimpanan efemeral dan lalu lintas {i>logging<i} oleh aplikasi.

Memantau pertentangan resource fisik

Perhatikan rasio vCPU terhadap pCPU dan komitmen memori yang berlebihan. J yang kurang optimal atau pertentangan memori di host fisik dapat menyebabkan VM penurunan performa. Anda harus memantau pemanfaatan sumber daya fisik di dan mengalokasikan sumber daya yang cukup untuk menjalankan cluster besar Anda.