Halaman ini menjelaskan praktik terbaik yang dapat Anda ikuti saat merencanakan dan merancang klaster yang berukuran sangat besar.
Perlunya merencanakan cluster GKE yang besar
Setiap sistem komputer termasuk Kubernetes memiliki beberapa batasan arsitektur. Melebihi batas dapat memengaruhi performa cluster, atau dalam kasus yang sama 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.
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) adalah hal yang umum, tetapi dapat membatasi kemampuan Anda untuk menskalakan cluster tersebut.
Tabel berikut menjelaskan kuota dan batas GKE utama. Anda juga harus membiasakan diri dengan antarmuka {i>open source<i} Batas Kubernetes untuk cluster skala 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 Layanan 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 {i>dataplane<i} default untuk GKE Autopilot, mengandalkan peta eBPF yang saat ini dibatasi hingga 260.000 endpoint di semua Layanan. |
| 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:
|
Setiap instance Config Connector memiliki permintaan CPU 0,1 dan batas memori 512 MB. Oleh karena itu, penskalaan tidak berjalan dengan baik pada resource terkelola dalam jumlah besar. Sebaiknya Anda tidak memiliki lebih dari 25.000 resource Google Cloud per satu instance Config Connector. Batasan ini hanya untuk referensi karena jumlah memori yang digunakan bergantung pada jenis resource dan kasus penggunaan tertentu. Saat mengelola resource terkelola dalam jumlah lebih besar, sebaiknya gunakan mode namespace untuk membatasi jumlah resource yang ditangani oleh setiap instance Config Connector. Sebaiknya gunakan maksimal 500 namespace dengan Config Connector dalam mode namespace.
Setiap instance Config Connector akan membuka banyak koneksi watch ke kube-apiserver. Instance dalam jumlah besar ini dapat membebani bidang kontrol cluster GKE, terutama selama upgrade bidang kontrol, saat koneksi watch perlu diinisialisasi ulang. Sebaiknya gunakan banyak cluster GKE untuk mengelola jumlah resource yang tidak dapat dibagi agar sesuai dengan batas yang ditentukan di atas. Lihat pedoman skalabilitas Pengontrol Konfigurasi untuk detail lebih lanjut. |