Halaman ini menjelaskan praktik terbaik untuk membuat, mengonfigurasi, dan mengoperasikan cluster Google Distributed Cloud guna mengakomodasi 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 batasan berikut saat mendesain aplikasi Anda di GKE di VMware:
Setiap cluster admin mendukung hingga 100 cluster pengguna, termasuk cluster pengguna dengan ketersediaan tinggi (HA) dan non-HA, menggunakan mode load balancing paket (Seesaw atau MetalLB), atau mode load balancing terintegrasi (F5).
Setiap cluster pengguna mendukung hingga:
500 node menggunakan mode load balancing paket (Seesaw atau MetalLB), atau 250 node yang menggunakan mode load balancing terintegrasi (F5)
15.000 Pod
500 Layanan LoadBalancer menggunakan mode load balancing yang dipaketkan (Seesaw atau MetalLB), atau 250 Layanan LoadBalancer menggunakan mode load balancing terintegrasi (F5).
Untuk setiap node, Anda dapat membuat maksimal 110 Pod (setiap Pod dapat terdiri dari 1-2 container). Hal ini termasuk Pod yang menjalankan layanan sistem add-on.
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 melakukan penskalaan melalui jumlah node, Pod, atau Layanan. Meregangkan lebih dari satu dimensi sekaligus dapat menyebabkan masalah, bahkan pada cluster yang lebih kecil. Misalnya, menjadwalkan 110 Pod per node dalam 500 cluster node dapat melebihi jumlah Pod, Pod per node, dan node.
Lihat Batas Skalabilitas Kubernetes untuk mengetahui detail selengkapnya.
Batas skalabilitas juga sensitif terhadap konfigurasi vSphere dan hardware yang menjalankan cluster Anda. Batasan ini diverifikasi dalam lingkungan yang mungkin berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak mereproduksi jumlah persisnya jika lingkungan yang mendasarinya merupakan faktor pembatas.
Bersiap untuk menskalakan
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 latensi I/O jaringan dan disk. Misalnya, 500 IOPS berurutan (misalnya, SSD lokal standar atau perangkat blok virtual berperforma tinggi) biasanya diperlukan untuk performa dan stabilitas etcd dalam sebuah cluster dengan puluhan node dan ribuan Pod.
Alamat IP node
Setiap node GKE di VMware memerlukan satu DHCP atau alamat IP yang ditetapkan secara statis.
Misalnya, 307 alamat IP diperlukan dalam konfigurasi satu cluster pengguna non-HA dengan 50 node dan satu cluster pengguna dengan ketersediaan tinggi (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 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-langkah berikut saat membuat cluster admin.
Blok 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 untuk setiap node. Jika semua cluster pengguna Anda mengaktifkan Controlplane V2, berarti 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 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 dari cluster admin adalah 192.168.0.0/16, yang mendukung 256 node.
Dalam cluster admin dengan 100 cluster pengguna kubeception 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 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.
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 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 dapat menggunakan rentang /22.
Cloud Logging dan Cloud Monitoring
Cloud Logging dan Cloud Monitoring membantu Anda melacak resource.
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 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 terlebih dahulu mengubah ukuran memori node cluster admin dari 16 GB menjadi 90 GB.
GKE Hub
Secara default, Anda dapat mendaftarkan maksimum 15 cluster pengguna.
Untuk mendaftarkan lebih banyak cluster di GKE Hub, Anda dapat mengirimkan permintaan untuk menambah kuota di Konsol Google Cloud:
Menjalankan banyak node dan pod dalam cluster pengguna
Selagi Anda bersiap 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. Konfigurasi ini dikonfigurasi melalui kolom network.podCIDR di user-cluster.yaml.
Dari rentang ini, blok yang lebih kecil /24 ditetapkan untuk setiap {i>node<i}. 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 Layanan adalah blok CIDR untuk semua Layanan di cluster pengguna. Properti 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 dalam cluster pengguna.
Tabel berikut menunjukkan CPU dan memori yang dibutuhkan 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-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 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, kami merekomendasikan 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 Anda melacak resource.
Penggunaan CPU dan memori agen dalam cluster yang di-deploy dalam skala cluster pengguna dalam hal jumlah node dan Pod dalam 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 meningkatkan skala cluster, tetapkan permintaan dan batas resource sesuai dengan perkiraan
rata-rata penggunaan komponen ini. Tabel berikut menunjukkan estimasi
jumlah penggunaan rata-rata
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,8G | 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,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 kumpulan node untuk mengakomodasi komponen, lalu secara bertahap meningkatkan skala cluster ke ukuran yang lebih besar.
Anda dapat memilih untuk mempertahankan kumpulan node dengan cukup besar bagi komponen pemantauan dan 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 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 dikonfigurasi di load balancer.
Untuk load balancing paket (Seesaw), ada juga batasan 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 Service, node, dan health check untuk Load balancing paket (Seesaw) dan Load balancing terintegrasi (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 Lihat F5 untuk informasi selengkapnya. Jumlah ini dipengaruhi oleh beberapa faktor seperti nomor model hardware F5, CPU/memori instance virtual, dan lisensi Anda.
Komponen sistem penskalaan otomatis
GKE di VMware akan otomatis menskalakan komponen sistem di cluster pengguna sesuai dengan jumlah node tanpa 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 komponen sistem berikut menggunakan addon-resizer:
kube-state-metrics adalah Deployment yang berjalan pada node worker cluster yang memproses 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 (milidetik) 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 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 pekerja 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 di GKE di VMware. Pod berjalan sebagai Deployment pada node pekerja cluster pengguna. GKE di VMware 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/dikurangi. Jika memiliki cluster
Nnode danCcore, Anda dapat mengharapkanmax(N/16, C/256)replika.calico-typha adalah komponen untuk mendukung jaringan Pod di GKE di VMware. Pod berjalan sebagai Deployment pada node pekerja cluster pengguna. GKE di VMware 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 cluster ingress, dan berjalan sebagai Deployment pada node worker cluster pengguna. Bergantung pada jumlah traffic masuk yang ditangani, GKE di VMware menggunakan Autoscaler Pod Horizontal untuk menskalakan jumlah replika berdasarkan penggunaan CPU-nya, dengan minimum 2 replika dan maksimum 5 replika.
Proxy jaringan (KNP) konnectivity menyediakan proxy level TCP untuk keluar dari node bidang kontrol cluster pengguna. Load balancer ini akan menghubungkan traffic keluar pengguna kube-apiserver yang ditujukan ke node cluster pengguna. Agen konnektivitas dijalankan sebagai Deployment pada node pekerja cluster pengguna. Google Distributed Cloud secara otomatis menskalakan jumlah replika agen konvektif berdasarkan jumlah node dalam cluster.
Jumlah node (N) Jumlah replika agen konnektivitas 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 akan 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 tahap dari 150 menjadi 350 menjadi 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 disk dan jaringan.
Optimalkan performa I/O datastore vSphere yang digunakan untuk VM bidang kontrol dengan mengikuti rekomendasi berikut:
- Ikuti persyaratan hardware dll..
- Gunakan SSD atau semua penyimpanan flash.
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_secondsetcd_disk_wal_fsync_duration_seconds
Mengoptimalkan performa I/O boot disk node
Pod menggunakan penyimpanan sementara untuk operasi internalnya, seperti menyimpan file sementara. Penyimpanan efemeral dipakai oleh lapisan yang dapat ditulis, direktori log, dan volume emptyDir dari container. Penyimpanan efemeral berasal dari GKE pada sistem file node VMware, yang didukung oleh boot disk node.
Karena tidak adanya isolasi I/O penyimpanan pada node Kubernetes, aplikasi yang menggunakan I/O yang sangat tinggi pada penyimpanan efemeralnya dapat menyebabkan ketidakstabilan node dengan membuat komponen sistem yang kekurangan energi 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 aset 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.