Halaman ini menjelaskan praktik terbaik untuk membuat, mengonfigurasi, dan mengoperasikan cluster yang dibuat menggunakan software Google Distributed Cloud khusus 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 berada dalam satu project Google Cloud .
Batas skalabilitas
Pertimbangkan batasan berikut saat mendesain aplikasi Anda:
Jika advanced cluster tidak diaktifkan:
Setiap cluster admin mendukung hingga 100 cluster pengguna, termasuk cluster pengguna dengan ketersediaan tinggi (HA) dan non-HA, menggunakan mode load balancing paket (MetalLB), atau (load balancer manual).
Setiap cluster pengguna mendukung hingga:
500 node yang menggunakan mode load balancing paket (MetalLB)
15.000 Pod
500 Service LoadBalancer menggunakan mode load balancing paket (MetalLB).
Untuk setiap node, Anda dapat membuat maksimum 110 Pod (setiap Pod dapat terdiri dari 1-2 container). Hal ini termasuk Pod yang menjalankan layanan sistem add-on.
Jika advanced cluster diaktifkan
Setiap cluster admin mendukung hingga 100 cluster pengguna, cluster pengguna harus berupa cluster ketersediaan tinggi (HA), menggunakan mode load balancing yang dipaketkan (MetalLB), atau (load balancer manual).
Setiap cluster pengguna mendukung hingga:
500 node yang menggunakan mode load balancing paket (MetalLB).
15.000 Pod
500 Service LoadBalancer menggunakan mode load balancing paket (MetalLB).
Untuk setiap node, Anda dapat membuat maksimum 110 Pod (setiap Pod dapat terdiri dari 1-2 container). Hal ini termasuk 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 platform integrasi yang besar, skalabilitas cluster melibatkan banyak dimensi yang saling terkait. Misalnya, Google Distributed Cloud dapat diskalakan melalui jumlah node, Pod, atau Service. Meregangkan lebih dari satu dimensi sekaligus dapat menyebabkan masalah, bahkan dalam cluster yang lebih kecil. Misalnya, menjadwalkan 110 Pod per node dalam cluster 500 node dapat melampaui jumlah Pod, Pod per node, dan node.
Baca 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 mungkin berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak mereproduksi angka yang sama persis jika lingkungan yang mendasarinya adalah 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 memerlukan banyak data dan komponen bidang kontrol tertentu sensitif terhadap latensi I/O disk dan jaringan. Misalnya, 500 IOPS berurutan (misalnya, SSD lokal standar 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 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 menunjukkan perincian alamat IP:
| Jenis node | Jumlah alamat IP |
|---|---|
| VM bidang kontrol cluster admin | 3 |
| VM bidang kontrol cluster pengguna 1 (non-HA) | 1 |
| VM worker node cluster pengguna 1 | 50 |
| VM bidang kontrol cluster pengguna 2 (HA) | 3 |
| VM worker node 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 dalam 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 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 cluster admin adalah 192.168.0.0/16, yang mendukung 256 node.
Dalam cluster admin dengan 100 cluster pengguna kubeception dengan ketersediaan tinggi (HA), terdapat 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 mengupdate blok CIDR Pod ke /15 untuk mendukung hingga 100 cluster pengguna kubeception dengan ketersediaan tinggi (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 Service di cluster admin.
Konfigurasinya dilakukan melalui kolom network.serviceCIDR di
admin-cluster.yaml.
Tabel berikut menjelaskan jumlah maksimum Service yang didukung oleh berbagai ukuran blok CIDR Service:
| Ukuran blok CIDR Service | Jumlah maksimum Layanan yang didukung |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1.024 |
Nilai defaultnya adalah 10.96.232.0/24, yang mendukung 256 service.
Setiap cluster pengguna kubeception menggunakan 6 Service, dan bidang kontrol cluster admin menggunakan 14 Service. Oleh karena itu, untuk menjalankan 100 cluster pengguna kubeception, Anda harus mengubah blok CIDR Service 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 penggunaan memori komponen logging dan pemantauan yang di-deploy di cluster admin 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.
Node cluster admin saat cluster lanjutan diaktifkan
Penggunaan CPU dan memori komponen siklus proses yang di-deploy di cluster admin diskalakan sesuai dengan jumlah total semua node (Jumlah total node yang mencakup node bidang kontrol cluster admin + semua node bidang kontrol cluster pengguna + worker node)
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 dengan ketersediaan tinggi (HA) yang memiliki 14 worker node. 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 terlebih dahulu dari 16 GB menjadi 32 GB.
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 :
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. 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 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 Service adalah blok CIDR untuk semua Service di cluster pengguna. Ini
dikonfigurasi melalui kolom network.serviceCIDR di user-cluster.yaml.
Tabel berikut menjelaskan jumlah maksimum Service yang didukung oleh berbagai ukuran blok CIDR Service:
| Ukuran blok CIDR Service | 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 dalam 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 dalam 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 penggunaan memori agen dalam cluster yang di-deploy di cluster pengguna diskalakan berdasarkan jumlah node dan Pod di 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 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 | ||
|---|---|---|---|---|---|
| 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,5G | 1,6G | |
| 51 hingga 100 | prometheus-server | 160m | 500m | 1,8 G | 5,5G |
| stackdriver-prometheus-sidecar | 200m | 500m | 1,9G | 5,7 G | |
| 101 hingga 250 | prometheus-server | 400m | 2.500 m | 6,5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1.300 m | 7,5 G | 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 meningkatkan skala cluster secara bertahap ke ukuran yang lebih besar.
Anda dapat memilih untuk mempertahankan node pool yang cukup besar untuk komponen pemantauan dan logging guna mencegah pod lain dijadwalkan ke node pool. Untuk melakukannya, Anda harus menambahkan taint berikut ke node pool:
taints:
- effect: NoSchedule
key: node-role.gke.io/observabilityHal ini mencegah komponen lain dijadwalkan di node pool dan mencegah workload pengguna dikeluarkan karena konsumsi resource komponen pemantauan.
Load Balancer
Service yang dibahas di bagian ini mengacu pada Service Kubernetes dengan jenis LoadBalancer.
Ada batasan jumlah node dalam cluster, dan jumlah Service yang dapat Anda konfigurasi di load balancer.
Untuk load balancing yang dipaketkan (Seesaw), ada juga batasan jumlah health check. Jumlah health check bergantung pada jumlah node dan jumlah Service lokal traffic. Service lokal traffic adalah Service yang memiliki externalTrafficPolicy yang ditetapkan ke Local.
Tabel berikut menjelaskan jumlah maksimum Service, node, dan health check untuk Load balancing paket (Seesaw) dan Load balancing terintegrasi (F5):
| Load balancing yang dipaketkan (Seesaw) | Load balancing terintegrasi (F5) | |
|---|---|---|
| Max Services | 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 Service 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 otomatis menskalakan komponen sistem di cluster pengguna sesuai dengan jumlah node tanpa perlu mengubah konfigurasi. Anda dapat menggunakan informasi di bagian ini untuk perencanaan resource.
Google Distributed Cloud 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 worker node 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, 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 + 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 600Mi.
metrics-server adalah deployment yang berjalan di worker node cluster yang digunakan oleh pipeline penskalaan otomatis bawaan Kubernetes. Permintaan dan batas CPU serta 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. Layanan ini berjalan sebagai Deployment di worker node 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
Nnode danCcore, Anda dapat mengharapkanmax(N/16, C/256)replika.calico-typha adalah komponen untuk mendukung jaringan Pod. Layanan ini berjalan sebagai Deployment di 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 < N < 200 2 N >= 200 3 atau lebih Istio ingress-gateway adalah komponen untuk mendukung ingress cluster, dan berjalan sebagai Deployment di worker node 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 minimum 2 replika dan maksimum 5 replika.
Proxy jaringan konnectivity (KNP) menyediakan proxy tingkat TCP untuk egress dari node bidang kontrol cluster pengguna. Fitur ini membuat tunnel traffic egress kube-apiserver pengguna yang ditujukan ke node cluster pengguna. Agen Konnectivity berjalan sebagai Deployment di worker node cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika agen konnectivity berdasarkan jumlah node dalam cluster.
Jumlah node (N) Jumlah replika agen konnectivity 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 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 workload. Jika ada terlalu banyak node yang dibuat secara bersamaan, operasi clone akan memerlukan waktu lama untuk diselesaikan 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 secara bertahap 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 kesehatan cluster dan sensitif terhadap latensi I/O disk dan jaringan.
Optimalkan performa I/O datastore vSphere yang digunakan untuk VM bidang kontrol dengan mengikuti rekomendasi berikut:
- Ikuti persyaratan hardware etcd.
- Gunakan SSD atau penyimpanan flash penuh.
Latensi beberapa ratus milidetik menunjukkan bottleneck pada disk atau I/O 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_secondsetcd_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 digunakan oleh lapisan yang dapat ditulisi 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 pada node Kubernetes, aplikasi yang menggunakan I/O yang sangat tinggi pada penyimpanan efemeralnya berpotensi menyebabkan ketidakstabilan node dengan menghabiskan resource komponen sistem seperti Kubelet dan daemon docker.
Pastikan karakteristik performa I/O datastore tempat boot disk disediakan dapat memberikan performa yang tepat untuk penggunaan penyimpanan sementara dan traffic logging aplikasi.
Memantau pertentangan resource fisik
Perhatikan rasio vCPU terhadap pCPU dan overcommitment memori. Rasio yang kurang optimal atau pertentangan memori di host fisik dapat menyebabkan penurunan performa VM. Anda harus memantau penggunaan resource fisik di level host dan mengalokasikan resource yang cukup untuk menjalankan cluster besar.