Seperti cluster Kubernetes lainnya, GKE pada skalabilitas cluster Bare Metal memiliki banyak dimensi yang saling terkait. Dokumen ini dimaksudkan untuk membantu Anda memahami dimensi utama yang dapat Anda sesuaikan untuk meningkatkan skala cluster tanpa mengganggu beban kerja Anda.
Memahami batas
GKE pada Bare Metal adalah sistem kompleks dengan platform integrasi yang besar. Ada banyak dimensi yang memengaruhi skalabilitas cluster. Misalnya, jumlah node hanyalah salah satu dari banyak dimensi yang dapat diskalakan GKE pada Bare Metal. Dimensi lainnya mencakup jumlah total Pod dan Layanan. Banyak dari dimensi tersebut, seperti jumlah pod per node dan jumlah node per cluster, saling terkait. Untuk mengetahui informasi selengkapnya tentang dimensi yang berpengaruh pada skalabilitas, lihat Batas Skalabilitas Kubernetes di bagian Scalability Special interest Group (SIG) pada repositori Komunitas Kubernetes di GitHub.
Batas skalabilitas juga sensitif terhadap konfigurasi hardware dan node tempat cluster Anda berjalan. Batas yang dijelaskan dalam dokumen ini diverifikasi di lingkungan yang mungkin berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak mereproduksi angka yang sama jika lingkungan yang mendasarinya merupakan faktor pembatas.
Untuk mengetahui informasi selengkapnya tentang batas yang berlaku pada GKE Anda di cluster Bare Metal, lihat Kuota dan batas.
Bersiap untuk meningkatkan skala
Saat Anda bersiap untuk menskalakan GKE pada cluster Bare Metal, pertimbangkan persyaratan dan batasan yang dijelaskan di bagian berikut.
Persyaratan CPU dan memori node bidang kontrol
Tabel berikut menguraikan konfigurasi CPU dan memori yang direkomendasikan bagi node bidang kontrol untuk cluster yang menjalankan beban kerja produksi:
| Jumlah node cluster | CPU bidang kontrol yang direkomendasikan | Memori bidang kontrol yang direkomendasikan |
|---|---|---|
| 1-50 | 8 core | 32 GiB |
| 51-100 | 16 core | 64 GiB |
Jumlah Pod dan Service
Jumlah Pod dan Service yang dapat Anda miliki dalam cluster dikontrol oleh setelan berikut:
clusterNetwork.pods.cidrBlocksmenentukan jumlah Pod yang diizinkan dalam cluster Anda.nodeConfig.podDensity.maxPodsPerNodemenentukan jumlah maksimum Pod yang dapat berjalan di satu node.clusterNetwork.services.cidrBlocksmenentukan jumlah Layanan yang diizinkan di cluster Anda.
CIDR pod dan jumlah node maksimum
Jumlah total alamat IP yang dicadangkan untuk Pod di cluster Anda adalah salah satu faktor pembatas untuk meningkatkan skala cluster Anda. Setelan ini, ditambah dengan setelan untuk pod maksimum per node, menentukan jumlah maksimum node yang dapat Anda miliki di cluster sebelum berisiko kehabisan alamat IP untuk pod.
Pertimbangkan hal berikut:
Jumlah total alamat IP yang dicadangkan untuk Pod di cluster Anda ditentukan dengan
clusterNetwork.pods.cidrBlocks, yang menggunakan rentang alamat IP yang ditentukan dalam notasi CIDR. Misalnya, nilai yang diisi otomatis192.168.0.0/16menentukan rentang 65.536 alamat IP dari192.168.0.0hingga192.168.255.255.Jumlah maksimum Pod yang dapat berjalan di satu node ditentukan dengan
nodeConfig.podDensity.maxPodsPerNode.Berdasarkan pod maksimum per setelan node, GKE pada Bare Metal menyediakan alamat IP kira-kira dua kali lebih banyak ke node. Alamat IP tambahan membantu mencegah penggunaan ulang IP Pod secara tidak sengaja dalam waktu yang singkat.
Membagi jumlah total alamat IP Pod dengan jumlah alamat IP Pod yang disediakan untuk setiap node akan menghasilkan jumlah total node yang dapat Anda miliki dalam cluster.
Misalnya, jika CIDR Pod Anda adalah 192.168.0.0/17, Anda memiliki total 32.768 alamat IP (2(32-17) = 215 = 32.768). Jika Anda menetapkan jumlah maksimum Pod per node ke 250, GKE pada Bare Metal akan menyediakan rentang sekitar 500 alamat IP, yang kurang lebih setara dengan blok CIDR /23 (2(32-23) = 29 = 512).
Jadi, jumlah maksimum node dalam kasus ini adalah 64 (215 alamat/cluster dibagi dengan 29 alamat/node = 2(15-9)
node/cluster = 26 = 64 node/cluster).
clusterNetwork.pods.cidrBlocks dan nodeConfig.podDensity.maxPodsPerNode
tidak dapat diubah, jadi rencanakan dengan hati-hati pertumbuhan cluster Anda di masa mendatang untuk
menghindari kehabisan kapasitas node. Untuk jumlah maksimum yang direkomendasikan untuk Pod per cluster, Pod per node, dan node per cluster berdasarkan pengujian, lihat Batas.
CIDR Layanan
CIDR Layanan dapat diupdate untuk menambahkan Layanan lainnya saat Anda meningkatkan skala cluster. Namun, Anda tidak dapat mengurangi rentang CIDR Layanan. Untuk mengetahui informasi selengkapnya, lihat Meningkatkan Rentang jaringan layanan.
Resource dicadangkan untuk daemon sistem
Secara default, GKE di Bare Metal otomatis mencadangkan resource pada node untuk daemon sistem, seperti sshd atau udev. Resource CPU dan memori dicadangkan
pada node untuk daemon sistem sehingga daemon ini memiliki resource yang
diperlukan. Tanpa fitur ini, Pod berpotensi menggunakan sebagian besar
resource pada sebuah node, sehingga daemon sistem tidak mungkin menyelesaikan
tugasnya.
Secara khusus, GKE di Bare Metal mencadangkan 80 milicore CPU (80 mCPU) dan 280 Mebibyte (280 MiB) memori pada setiap node untuk daemon sistem. Perlu diperhatikan bahwa unit CPU mCPU adalah singkatan dari seperseribu core, sehingga 80/1000 atau 8% dari core pada setiap node dicadangkan untuk daemon sistem. Jumlah resource yang dicadangkan berukuran kecil dan tidak berdampak signifikan terhadap performa Pod. Namun, kubelet pada node dapat mengeluarkan Pod jika penggunaan CPU atau memori oleh CPU atau memori mereka melebihi jumlah yang telah dialokasikan untuk pod.
Networking dengan MetalLB
Anda mungkin ingin meningkatkan jumlah speaker MetalLB untuk memenuhi aspek berikut:
Bandwidth: seluruh bandwidth cluster untuk layanan load balancing bergantung pada jumlah speaker dan bandwidth setiap node speaker. Peningkatan traffic jaringan memerlukan lebih banyak speaker.
Toleransi kesalahan: lebih banyak speaker akan mengurangi dampak keseluruhan dari kegagalan speaker tunggal.
MetalLB memerlukan koneksi Lapisan 2 antar-node load balancing. Dalam hal ini, Anda mungkin dibatasi oleh jumlah node dengan konektivitas Lapisan 2 tempat Anda dapat mengaktifkan speaker MetalLB.
Rencanakan dengan cermat jumlah speaker MetalLB yang ingin Anda miliki di cluster dan tentukan jumlah node Lapisan 2 yang Anda perlukan. Untuk mengetahui informasi selengkapnya, lihat Masalah skalabilitas MetalLB.
Secara terpisah, saat menggunakan mode load balancing yang dipaketkan, node bidang kontrol juga harus berada di jaringan Lapisan 2 yang sama. Load balancing manual tidak memiliki batasan ini. Untuk mengetahui informasi selengkapnya, lihat Mode load balancer manual.
Menjalankan banyak node, Pod, dan Service
Menambahkan node, Pod, dan Service adalah cara untuk meningkatkan skala cluster Anda. Bagian berikut ini membahas beberapa setelan dan konfigurasi tambahan yang harus Anda pertimbangkan saat menambah jumlah node, Pod, dan Layanan di cluster Anda. Untuk informasi tentang batas dimensi ini dan hubungannya satu sama lain, lihat Batas.
Buat cluster tanpa kube-proxy
Untuk membuat cluster berperforma tinggi yang dapat meningkatkan skala agar dapat menggunakan sejumlah besar Layanan dan endpoint, sebaiknya buat cluster tanpa kube-proxy. Tanpa kube-proxy, cluster akan menggunakan GKE Dataplane V2 dalam mode kube-proxy-replacement. Mode ini menghindari pemakaian resource yang diperlukan untuk mempertahankan sekumpulan besar aturan iptables.
Anda tidak dapat menonaktifkan penggunaan kube-proxy untuk cluster yang ada. Konfigurasi
ini harus disiapkan saat cluster dibuat. Untuk mengetahui petunjuk dan informasi lebih lanjut, baca Membuat cluster tanpa kube-proxy.
Konfigurasi CoreDNS
Bagian ini menjelaskan aspek CoreDNS yang memengaruhi skalabilitas untuk cluster Anda.
DNS Pod
Secara default, GKE pada cluster Bare Metal memasukkan Pod dengan resolv.conf yang
terlihat seperti berikut:
nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5
Opsi ndots:5 berarti nama host yang memiliki kurang dari 5 titik tidak
dianggap sebagai nama domain yang sepenuhnya memenuhi syarat (FQDN). Server DNS menambahkan semua domain penelusuran yang ditentukan sebelum mencari nama host yang pertama kali diminta, yang mengurutkan pencarian seperti berikut ini saat me-resolve google.com:
google.com.NAMESPACE.svc.cluster.localgoogle.com.svc.cluster.localgoogle.com.cluster.localgoogle.com.c.PROJECT_ID.internalgoogle.com.google.internalgoogle.com
Setiap pencarian dilakukan untuk IPv4 (data A) dan IPv6 (data AAAA), yang menghasilkan 12 permintaan DNS untuk setiap kueri non-FQDN, yang secara signifikan memperkuat traffic DNS. Untuk mengurangi masalah ini, sebaiknya deklarasikan
nama host yang akan dicari sebagai FQDN dengan menambahkan titik akhir (google.com.). Deklarasi
ini harus dilakukan pada tingkat beban kerja aplikasi. Untuk mengetahui informasi
selengkapnya, lihat halaman
manual resolv.conf.
IPv6
Jika cluster tidak menggunakan IPv6, Anda dapat mengurangi permintaan DNS hingga separuhnya dengan menghilangkan pencarian data AAAA ke server DNS upstream. Jika Anda memerlukan bantuan untuk menonaktifkan pencarian AAAA, hubungi Cloud Customer Care.
Kumpulan node khusus
Karena sifat penting kueri DNS dalam siklus proses aplikasi, sebaiknya
gunakan node khusus untuk Deployment coredns. Deployment ini berada di domain kegagalan yang berbeda dengan aplikasi normal. Jika
Anda memerlukan bantuan dalam menyiapkan node khusus untuk Deployment coredns, hubungi
Cloud Customer Care.
Masalah skalabilitas MetalLB
MetalLB berjalan dalam mode pasif aktif, yang berarti bahwa pada waktu tertentu, hanya ada
satu speaker MetalLB yang menayangkan VIP LoadBalancer tertentu.
Failover
Sebelum GKE on Bare Metal merilis 1.28.0, dalam skala besar, failover MetalLB dapat memerlukan waktu lama dan dapat menimbulkan risiko keandalan pada cluster.
Batas koneksi
Jika ada VIP LoadBalancer tertentu, seperti Layanan Ingress, yang
mengharapkan mendekati atau lebih dari 30 ribu koneksi serentak, kemungkinan
node speaker yang menangani VIP mungkin membuang port
yang tersedia. Karena keterbatasan arsitektur,
tidak ada mitigasi untuk masalah ini dari MetalLB. Pertimbangkan untuk beralih ke load balancing paket dengan BGP sebelum pembuatan cluster atau gunakan class ingress yang berbeda. Untuk informasi selengkapnya, lihat
Konfigurasi masuk.
Speaker load balancer
Secara default, GKE di Bare Metal menggunakan kumpulan node load balancer yang sama untuk bidang kontrol dan bidang data. Jika Anda tidak menentukan kumpulan node load balancer (loadBalancer.nodePoolSpec), kumpulan node bidang kontrol (controlPlane.nodePoolSpec) akan digunakan.
Untuk menambah jumlah speaker saat menggunakan kumpulan node bidang kontrol untuk load balancing, Anda harus meningkatkan jumlah mesin bidang kontrol. Untuk deployment produksi, sebaiknya gunakan tiga node bidang kontrol untuk mendapatkan ketersediaan tinggi. Meningkatkan jumlah node bidang kontrol lebih dari tiga untuk mengakomodasi speaker tambahan mungkin bukan penggunaan resource yang baik.
Konfigurasi masuk
Jika Anda memperkirakan hampir 30 ribu koneksi serentak yang masuk ke satu
VIP Layanan LoadBalancer, MetalLB mungkin tidak dapat mendukungnya.
Anda dapat mempertimbangkan untuk mengekspos VIP melalui mekanisme lain, seperti F5 BIG-IP. Atau, Anda dapat membuat cluster baru menggunakan load balancing paket dengan BGP, yang tidak memiliki batasan yang sama.
Menyesuaikan komponen Cloud Logging dan Cloud Monitoring
Dalam cluster besar, tergantung pada profil aplikasi dan pola traffic, konfigurasi resource default untuk komponen Cloud Logging dan Cloud Monitoring mungkin tidak cukup. Untuk mengetahui petunjuk cara menyesuaikan permintaan resource dan batas komponen kemampuan observasi, lihat Mengonfigurasi resource komponen Stackdriver.
Secara khusus, kube-state-metrics dalam cluster dengan sejumlah besar layanan dan endpoint dapat menyebabkan penggunaan memori yang berlebihan pada kube-state-metrics itu sendiri dan gke-metrics-agent pada node yang sama. Penggunaan resource dari server metrik juga dapat melakukan penskalaan dalam hal node, Pod, dan Layanan. Jika Anda mengalami masalah resource pada komponen ini, hubungi
Cloud Customer Care.
Menggunakan sysctl untuk mengonfigurasi sistem operasi
Sebaiknya Anda menyesuaikan konfigurasi sistem operasi untuk node Anda
agar sesuai dengan kasus penggunaan beban kerja Anda. Parameter fs.inotify.max_user_watches dan
fs.inotify.max_user_instances yang mengontrol jumlah resource inotify
sering kali perlu disesuaikan. Misalnya, jika melihat pesan error seperti berikut, Anda mungkin perlu mencoba melihat apakah parameter tersebut perlu disesuaikan:
The configured user limit (128) on the number of inotify instances has been reached
ENOSPC: System limit for number of file watchers reached...
Penyesuaian biasanya bervariasi berdasarkan jenis beban kerja dan konfigurasi hardware. Anda dapat mengetahui praktik terbaik OS tertentu dengan vendor OS.
Praktik terbaik
Bagian ini menjelaskan praktik terbaik untuk meningkatkan skala cluster Anda.
Menskalakan satu dimensi dalam satu waktu
Untuk meminimalkan masalah dan mempermudah roll back perubahan, jangan menyesuaikan lebih dari satu dimensi pada satu waktu. Peningkatan skala beberapa dimensi secara bersamaan dapat menyebabkan masalah, bahkan pada cluster yang lebih kecil. Misalnya, mencoba meningkatkan jumlah Pod yang dijadwalkan per node menjadi 110 sekaligus menambah jumlah node di cluster menjadi 250 kemungkinan tidak akan berhasil karena jumlah Pod, jumlah Pod per node, dan jumlah node direntangkan terlalu jauh.
Menskalakan cluster secara bertahap
Peningkatan skala cluster dapat memerlukan banyak resource. Untuk mengurangi risiko kegagalan operasi cluster atau workload cluster terganggu, sebaiknya jangan mencoba membuat cluster besar dengan banyak node dalam satu operasi.
Membuat cluster hybrid atau mandiri tanpa worker node
Jika Anda membuat cluster hybrid atau mandiri yang besar dengan lebih dari 50 node pekerja, sebaiknya buat cluster ketersediaan tinggi (HA) dengan node bidang kontrol terlebih dahulu, lalu tingkatkan skalanya secara bertahap. Operasi pembuatan cluster menggunakan cluster bootstrap, yang bukan HA, sehingga kurang dapat diandalkan. Setelah cluster mandiri atau hybrid dengan ketersediaan tinggi (HA) dibuat, Anda dapat menggunakannya untuk meningkatkan skala ke lebih banyak node.
Meningkatkan jumlah worker node dalam batch
Jika Anda memperluas cluster ke lebih banyak worker node, sebaiknya perluas dalam beberapa tahap. Sebaiknya tambahkan maksimal 20 node sekaligus. Hal ini terutama berlaku untuk cluster yang menjalankan workload kritis.
Mengaktifkan pull gambar paralel
Secara default, kubelet mengambil gambar secara berurutan, satu per satu. Jika Anda memiliki koneksi upstream yang buruk ke server registry image, pull image yang buruk dapat menghalangi seluruh antrean untuk kumpulan node tertentu.
Untuk mengurangi hal ini, sebaiknya tetapkan serializeImagePulls ke false dalam konfigurasi kubelet kustom. Untuk mendapatkan petunjuk dan informasi selengkapnya, lihat
Mengonfigurasi setelan pull image kubelet.
Mengaktifkan pull gambar paralel dapat menyebabkan lonjakan pemakaian bandwidth
jaringan atau I/O disk.
Menyesuaikan permintaan dan batas resource aplikasi
Dalam lingkungan yang padat, beban kerja aplikasi mungkin akan hilang. Kubernetes menggunakan mekanisme yang direferensikan untuk menentukan peringkat pod jika terjadi eviction.
Praktik yang baik untuk menetapkan resource container Anda adalah menggunakan jumlah memori yang sama untuk permintaan dan batas, serta batas CPU yang lebih besar atau tidak terbatas. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan aplikasi Kubernetes berbasis cloud di Cloud Architecture Center.
Menggunakan partner penyimpanan
Sebaiknya gunakan salah satu partner penyimpanan GDCV Ready untuk deployment skala besar. Penting untuk mengonfirmasi informasi berikut dengan partner penyimpanan tertentu:
- Deployment penyimpanan mengikuti praktik terbaik untuk aspek penyimpanan, seperti ketersediaan tinggi, setelan prioritas, afinitas node, serta permintaan dan batas resource.
- Versi penyimpanan ini memenuhi syarat dengan GKE pada versi Bare Metal tertentu.
- Vendor penyimpanan dapat mendukung skala tinggi yang ingin Anda deploy.
Mengonfigurasi cluster untuk ketersediaan tinggi
Penting untuk mengaudit deployment berskala tinggi dan memastikan komponen penting telah dikonfigurasi untuk HA jika memungkinkan. GKE di Bare Metal mendukung opsi deployment HA untuk semua jenis cluster. Untuk informasi selengkapnya, lihat Memilih model deployment. Untuk mengetahui contoh file konfigurasi cluster deployment dengan ketersediaan tinggi (HA), lihat Contoh konfigurasi cluster.
Penting juga untuk mengaudit komponen lain, termasuk:
- Vendor penyimpanan
- Webhook cluster
Memantau penggunaan resource
Bagian ini memberikan beberapa rekomendasi pemantauan dasar untuk cluster berskala besar.
Memantau metrik pemanfaatan dengan cermat
Sangat penting untuk memantau penggunaan node dan masing-masing komponen sistem, serta memastikan semuanya memiliki margin yang aman dan nyaman. Untuk melihat kemampuan pemantauan standar yang tersedia secara default, lihat Menggunakan dasbor standar.
Memantau konsumsi bandwidth
Pantau konsumsi bandwidth dengan cermat untuk memastikan jaringan tidak jenuh, yang menyebabkan penurunan performa untuk cluster Anda.
Meningkatkan performa etcd
Kecepatan {i>disk<i} sangat penting untuk performa dan stabilitas etcd. Disk yang lambat meningkatkan
latensi permintaan dll., yang dapat menyebabkan masalah stabilitas cluster. Untuk meningkatkan performa cluster, GKE di Bare Metal menyimpan objek Event dalam instance etcd khusus yang terpisah. Instance etcd standar menggunakan /var/lib/etcd sebagai direktori datanya dan port 2379 untuk permintaan klien. Instance etcd-events menggunakan /var/lib/etcd-events sebagai direktori data dan port 2382 untuk permintaan klien.
Sebaiknya gunakan disk solid-state (SSD) untuk penyimpanan etcd Anda. Untuk
performa optimal, pasang disk terpisah ke /var/lib/etcd dan
/var/lib/etcd-events. Menggunakan {i>disk<i} khusus memastikan bahwa
dua instance {i>etcd<i} tidak berbagi I/O {i>disk<i}.
Dokumentasi etcd memberikan rekomendasi hardware tambahan untuk memastikan performa etcd terbaik saat menjalankan cluster Anda dalam produksi.
Untuk memeriksa performa etcd dan disk, gunakan metrik latensi I/O etcd berikut di Metrics Explorer:
etcd_disk_backend_commit_duration_seconds: durasinya harus kurang dari 25 milidetik untuk persentil ke-99 (p99).etcd_disk_wal_fsync_duration_seconds: durasi harus kurang dari 10 milidetik untuk persentil ke-99 (p99).
Untuk mengetahui informasi selengkapnya tentang performa etcd, lihat Apa maksud dari peringatan etcd "apply karya berdurasi terlalu lama" ? dan Apa arti peringatan etcd "failed to send out heartbeat on time"?.
Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.