Halaman ini menjelaskan praktik terbaik yang dapat Anda ikuti saat merencanakan dan mendesain cluster berukuran sangat besar.
Alasan merencanakan cluster GKE besar
Setiap sistem komputer termasuk Kubernetes memiliki beberapa batasan arsitektur. Melebihi batas dapat memengaruhi performa cluster, atau dalam beberapa kasus bahkan dapat menyebabkan periode nonaktif. Ikuti praktik terbaik dan jalankan tindakan yang direkomendasikan untuk memastikan cluster Anda dapat menjalankan workload dengan andal dalam skala besar.
Batasan cluster GKE besar
Saat GKE menskalakan cluster ke sejumlah besar node, GKE akan berupaya mengubah jumlah resource yang tersedia agar sesuai dengan kebutuhan sistem Anda sekaligus tetap berada dalam tujuan tingkat layanan (SLO)-nya. Google Cloud mendukung cluster besar. Namun, berdasarkan kasus penggunaan, Anda harus mempertimbangkan batasan cluster besar untuk merespons lebih baik persyaratan skala infrastruktur Anda.
Bagian ini menjelaskan batasan dan pertimbangan saat mendesain cluster GKE besar berdasarkan jumlah node yang diharapkan.
Cluster dengan hingga 5.000 node
Saat mendesain arsitektur cluster untuk diskalakan hingga 5.000 node, pertimbangkan kondisi berikut:
- Hanya tersedia untuk cluster regional.
- Hanya tersedia untuk cluster yang menggunakan Private Service Connect.
- Untuk bermigrasi dari cluster zonal ke cluster regional, Anda harus membuat ulang cluster untuk membuka level kuota node yang lebih tinggi.
Jika Anda ingin menskalakan cluster di luar 5.000 node, hubungi Cloud Customer Care untuk meningkatkan ukuran cluster dan batas kuota.
Cluster dengan lebih dari 5.000 node
GKE mendukung cluster Standard besar hingga 15.000 node. Pada versi 1.31 dan yang lebih baru, GKE mendukung cluster besar hingga 65.000 node. Batas 65.000 dimaksudkan untuk digunakan menjalankan workload AI berskala besar.
Jika Anda ingin menskalakan cluster ke 15.000 atau 65.000 node, selesaikan tugas berikut:
Pertimbangkan batasan berikut:
- Autoscaler cluster tidak didukung. Sebagai gantinya, skalakan node pool Anda ke atas atau ke bawah menggunakan GKE API.
- Multi-jaringan tidak didukung.
- Layanan dengan lebih dari 100 Pod harus headless.
- Setiap Pod harus berjalan di node-nya sendiri, kecuali DaemonSet sistem. Untuk menentukan penjadwalan Pod di node tertentu, Anda dapat menggunakan afinitas atau anti-afinitas Pod Kubernetes.
- Untuk bermigrasi dari cluster zona ke cluster regional, Anda harus membuat ulang cluster untuk membuka level kuota node yang lebih tinggi.
- Untuk bermigrasi ke cluster yang menggunakan Private Service Connect, Anda harus membuat ulang cluster untuk membuka tingkat kuota node yang lebih tinggi.
Hubungi Layanan Pelanggan Cloud untuk meningkatkan ukuran cluster dan batas kuota menjadi 15.000 node atau 65.000 node, bergantung pada kebutuhan penskalaan Anda.
Praktik terbaik untuk membagi workload antara beberapa cluster
Anda dapat menjalankan workload di satu cluster berukuran besar. Pendekatan ini lebih mudah dikelola, lebih hemat biaya, dan memberikan pemanfaatan resource yang lebih baik daripada menggunakan banyak cluster. Namun, dalam beberapa kasus, Anda perlu mempertimbangkan untuk membagi workload menjadi sejumlah cluster:
- Tinjau Kasus penggunaan multi-cluster untuk mempelajari lebih lanjut persyaratan umum dan skenario penggunaan multi-cluster.
- Selain itu, dari sudut pandang skalabilitas, bagi cluster Anda jika cluster tersebut dapat melebihi salah satu batas yang dijelaskan di bawah atau salah satu kuota GKE. Dengan begitu, Anda dapat menghindari potensi terlampauinya batas GKE, mengurangi risiko terjadinya periode nonaktif, atau masalah keandalan lainnya.
Jika Anda memutuskan untuk membagi cluster, gunakan Pengelolaan fleet untuk menyederhanakan pengelolaan fleet multi-cluster.
Batasan dan praktik terbaik
Untuk memastikan arsitektur Anda mendukung cluster GKE yang berskala besar, tinjau batasan berikut dan praktik terbaik terkait. Jika batas ini terlampaui, penurunan performa cluster atau masalah keandalan dapat terjadi.
Praktik terbaik ini berlaku untuk semua cluster Kubernetes default tanpa ekstensi yang diinstal. Memperluas cluster Kubernetes dengan webhook atau definisi resource kustom (CRD) merupakan praktik yang umum, tetapi dapat membatasi kemampuan Anda untuk menskalakan cluster.
Tabel berikut menjelaskan kuota dan batas GKE utama. Anda juga perlu memahami batasan Kubernetes open source untuk cluster berskala besar.
Persyaratan versi GKE yang disebutkan dalam tabel berlaku baik untuk node maupun bidang kontrol.
| Batas GKE | Deskripsi | Praktik terbaik |
|---|---|---|
| Ukuran database etcd | Ukuran maksimum database etcd adalah 6 GB. Jika Anda menjalankan cluster yang sangat besar dengan puluhan ribu resource, instance etcd Anda dapat melebihi batas ini. Anda dapat memeriksa tingkat penggunaan untuk cluster di konsol Google Cloud. | Jika batas ini terlampaui, GKE dapat menandai instance etcd Anda sebagai tidak responsif. Hal ini menyebabkan bidang kontrol cluster menjadi tidak responsif.
Jika Anda melampaui batas ini, hubungi dukungan Google Cloud. |
| Ukuran total objek etcd per jenis | Ukuran total semua objek dari jenis resource yang ditentukan tidak boleh melebihi 800 MB. Misalnya, Anda dapat membuat instance Pod berukuran 750 MB dan Secret 750 MB, tetapi Anda tidak dapat membuat Secret berukuran 850 MB. Jika Anda membuat objek yang berukuran lebih dari 800 MB, Kubernetes atau pengontrol kustom akan gagal diinisialisasi dan terjadilah gangguan. |
Pertahankan ukuran total semua objek dari setiap jenis yang disimpan di etcd di bawah 800 MB. Hal ini berlaku terutama pada cluster yang menggunakan banyak Secret atau ConfigMaps berukuran besar, atau CRD bervolume tinggi. |
| Jumlah Service untuk cluster tempat GKE Dataplane V2 tidak diaktifkan | Performa iptable yang digunakan kube-proxy akan menurun jika salah satu hal berikut terjadi:
Batas ini akan ditiadakan jika GKE Dataplane V2 diaktifkan. |
Pertahankan jumlah Service di cluster tetap di bawah 10.000. Untuk mempelajari lebih lanjut, lihat Mengekspos aplikasi menggunakan Service. |
| Jumlah Service per namespace | Jumlah variabel lingkungan yang dihasilkan untuk Service mungkin melebihi batas shell. Hal ini dapat menyebabkan Pod mengalami error saat sistem dimulai. |
Pertahankan jumlah Service per namespace di bawah 5.000. Anda dapat menonaktifkan pengisian variabel lingkungan secara otomatis. Lihat dokumentasi tentang cara menetapkan Untuk mempelajari lebih lanjut, lihat Mengekspos aplikasi menggunakan Service. |
| Jumlah Pod di belakang satu Service untuk cluster tempat GKE Dataplane V2 tidak diaktifkan |
Setiap node menjalankan kube-proxy yang menggunakan watch untuk memantau setiap perubahan Service. Makin besar cluster, makin banyak data terkait perubahan yang diproses oleh agen. Hal ini sangat kentara pada cluster yang memiliki lebih dari 500 node. Informasi tentang endpoint dibagi di antara Objek endpoint masih tersedia untuk komponen, tetapi endpoint dengan lebih dari 1.000 Pod akan otomatis terpotong. |
Pertahankan jumlah Pod di belakang satu Service di bawah 10.000. Untuk mempelajari lebih lanjut, lihat Mengekspos aplikasi menggunakan Service. |
| Jumlah Pod di belakang satu Service untuk cluster tempat GKE Dataplane V2 diaktifkan |
GKE Dataplane V2 berisi batas jumlah Pod yang diekspos oleh satu Service. Batas yang sama berlaku untuk cluster Autopilot karena cluster ini menggunakan GKE Dataplane V2. |
Di GKE versi 1.23 dan yang lebih lama, pertahankan jumlah Pod di belakang satu Service di bawah 1.000. Di GKE versi 1.24 dan yang lebih baru, pertahankan jumlah Pod di belakang satu Service di bawah 10.000. Untuk mempelajari lebih lanjut, lihat Mengekspos aplikasi menggunakan Service. |
| Data DNS per Service headless |
Jumlah data DNS per Service Headless dibatasi baik untuk kube-dns maupun Cloud DNS. |
Pertahankan jumlah data DNS per Service headless di bawah 1.000 untuk kube-dns dan 3.500/2.000 (IPv4/IPv6) untuk Cloud DNS. |
| Jumlah semua endpoint Service | Jumlah endpoint di semua Service mungkin mencapai batas. Hal ini dapat meningkatkan latensi pemrograman atau menyebabkan ketidakmampuan untuk memprogram endpoint baru sama sekali. |
Pertahankan jumlah semua endpoint di semua layanan di bawah 260.000. GKE Dataplane V2, yang merupakan dataplane default untuk GKE Autopilot, mengandalkan peta eBPF yang saat ini dibatasi maksimal 260.000 endpoint untuk semua Service. |
| Jumlah objek Horizontal Pod Autoscaler per cluster |
Setiap Horizontal Pod Autoscaler (HPA) diproses setiap 15 detik. Objek HPA lebih dari 300 dapat menyebabkan penurunan performa secara linear. |
Pertahankan jumlah objek HPA di bawah batas ini; jika tidak, Anda dapat mengalami penurunan frekuensi pemrosesan HPA secara linier. Misalnya, di GKE versi 1.22 dengan 2.000 HPA, satu HPA akan diproses ulang setiap 1 menit 40 detik. Untuk mempelajari lebih lanjut, lihat penskalaan otomatis berdasarkan pemanfaatan resource dan skalabilitas penskalaan otomatis Pod horizontal. |
| Jumlah Pod per node | GKE memiliki batas ketat 256 Pod per node. Hal ini dengan asumsi setiap Pod terdiri atas rata-rata dua container atau kurang. Jika Anda meningkatkan jumlah container per Pod, batas ini mungkin akan lebih rendah karena GKE mengalokasikan lebih banyak resource per container. |
Sebaiknya gunakan worker node dengan minimal satu vCPU per 10 pod. Untuk mempelajari lebih lanjut, lihat mengupgrade cluster atau node pool secara manual. |
| Tingkat perubahan pod |
Kubernetes memiliki batas internal yang memengaruhi tingkat pembuatan atau penghapusan Pod (churn Pod) sebagai respons terhadap permintaan penskalaan. Faktor lain seperti menghapus pod yang merupakan bagian dari Service juga dapat memengaruhi tingkat churn Pod ini. Untuk cluster dengan maksimal 500 node, Anda dapat memperkirakan tingkat rata-rata sebesar 20 pod dibuat per detik dan 20 pod dihapus per detik. Untuk cluster dengan lebih dari 500 node, Anda dapat memperkirakan tingkat rata-rata sebesar 100 pod dibuat per detik dan 100 pod dihapus per detik. |
Pertimbangkan batas tingkat pembuatan dan penghapusan Pod ini saat merencanakan cara menskalakan workload Anda. Pod berbagi throughput penghapusan yang sama dengan jenis resource lainnya (misalnya EndpointSlices). Anda dapat menurunkan throughput penghapusan saat menentukan Pod sebagai bagian dari Service. Agar Autoscaler Cluster dapat menghapus pod secara efektif dari node yang kurang dimanfaatkan, hindari PodDisruptionBudgets yang terlalu ketat dan masa tenggang penghentian yang panjang. Tolerasi karakter pengganti juga tidak disarankan, karena dapat menyebabkan workload dijadwalkan di node yang sedang dalam proses penghapusan. |
| Jumlah watch yang terbuka | Node membuat watch untuk setiap Secret dan ConfigMaps yang Anda konfigurasi untuk Pod. Jumlah gabungan watch yang dibuat oleh semua node dapat menghasilkan beban yang signifikan pada bidang kontrol cluster. Memiliki lebih dari 200.000 watch per cluster dapat memengaruhi waktu inisialisasi cluster. Masalah ini dapat menyebabkan bidang kontrol sering dimulai ulang. |
Tentukan node yang lebih besar untuk mengurangi kemungkinan terjadinya dan tingkat keparahan masalah yang disebabkan oleh banyaknya watch. Kepadatan pod yang lebih tinggi (node berukuran besar yang lebih sedikit) dapat mengurangi jumlah watch dan memitigasi tingkat keparahan masalah. Untuk mempelajari lebih lanjut, lihat perbandingan seri mesin. |
| Jumlah Secret per cluster jika enkripsi secret lapisan aplikasi diaktifkan | Cluster harus mendekripsi semua Secret saat dimulai jika enkripsi secret lapisan aplikasi diaktifkan. Jika Anda menyimpan lebih dari 30.000 secret, cluster Anda mungkin menjadi tidak stabil saat dimulai atau diupgrade, sehingga menyebabkan pemadaman workload. | Simpan tidak lebih dari 30.000 Secret saat menggunakan enkripsi secret lapisan aplikasi. Untuk mempelajari lebih lanjut, lihat mengenkripsi secret di lapisan aplikasi. |
| Bandwidth log per node |
Ada batasan jumlah maksimum log yang dikirim oleh setiap node ke Cloud Logging API. Batas default-nya bervariasi antara 100 Kbps dan 500 Kbps, bergantung pada beban. Anda dapat menaikkan batas ini sebesar 10 Mbps dengan men-deploy konfigurasi Agen logging dengan throughput tinggi. Jika melebihi batas ini, entri log dapat terhapus. |
Konfigurasi logging Anda agar tetap dalam batas default atau konfigurasi Agen logging dengan throughput tinggi. Untuk mempelajari lebih lanjut, lihat Meningkatkan throughput Agen logging. |
| Batas Pencadangan untuk GKE |
Anda dapat menggunakan Pencadangan untuk GKE jika ingin mencadangkan dan memulihkan workload GKE. Pencadangan untuk GKE memiliki batasan yang perlu Anda perhatikan saat menentukan rencana pencadangan. |
Tinjau batas Pencadangan untuk GKE. Jika workload Anda dapat melebihi batas ini, sebaiknya buat beberapa rencana pencadangan untuk mempartisi cadangan Anda dan tetap berada di bawah batas tersebut. |
| Batas Config Connector |
Anda dapat menggunakan Config Connector untuk mengelola resource Google Cloud melalui Kubernetes. Config Connector memiliki dua mode operasi:
|
Untuk mengetahui detail tentang batas resource, lihat pedoman skalabilitas Pengontrol Konfigurasi. Untuk informasi tentang cara mengelola resource dalam jumlah besar, lihat Praktik terbaik Config Connector. |