Menskalakan cluster Google Distributed Cloud

Seperti cluster Kubernetes lainnya, skalabilitas cluster Google Distributed Cloud memiliki banyak dimensi yang saling terkait. Dokumen ini dimaksudkan untuk membantu Anda memahami dimensi utama yang dapat disesuaikan untuk menskalakan cluster tanpa mengganggu beban kerja.

Memahami batas

Google Distributed Cloud adalah sistem yang kompleks dengan area integrasi yang luas. Ada banyak dimensi yang memengaruhi skalabilitas cluster. Misalnya, jumlah node hanyalah salah satu dari banyak dimensi yang dapat diskalakan oleh Google Distributed Cloud. Dimensi lainnya mencakup jumlah total Pod dan Layanan. Banyak dimensi ini, seperti jumlah pod per node dan jumlah node per cluster, saling terkait. Untuk mengetahui informasi selengkapnya tentang dimensi yang memengaruhi 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 kemungkinan berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak dapat mereproduksi angka yang sama jika lingkungan yang mendasarinya adalah faktor pembatas.

Untuk mengetahui informasi selengkapnya tentang batas yang berlaku untuk cluster Google Distributed Cloud Anda, lihat Kuota dan batas.

Bersiap untuk melakukan penskalaan

Saat Anda bersiap untuk menskalakan cluster Google Distributed Cloud, 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 untuk node bidang kontrol bagi cluster yang menjalankan workload 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 Layanan

Jumlah Pod dan Layanan yang dapat Anda miliki di cluster Anda dikontrol oleh setelan berikut:

CIDR Pod dan jumlah node maksimum

Jumlah total alamat IP yang dicadangkan untuk Pod di cluster Anda adalah salah satu faktor pembatas untuk menskalakan cluster Anda. Setelan ini, bersama dengan setelan untuk pod maksimum per node, menentukan jumlah maksimum node yang dapat Anda miliki di cluster sebelum Anda 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 telah diisi otomatis 192.168.0.0/16 menentukan rentang 65.536 alamat IP dari 192.168.0.0 hingga 192.168.255.255.

  • Jumlah maksimum Pod yang dapat berjalan di satu node ditentukan dengan nodeConfig.podDensity.maxPodsPerNode.

  • Berdasarkan setelan pod maksimum per node, Google Distributed Cloud menyediakan sekitar dua kali lipat jumlah alamat IP ke node. Alamat IP tambahan ini membantu mencegah penggunaan kembali IP Pod yang tidak disengaja dalam rentang waktu yang singkat.

  • Membagi jumlah total alamat IP Pod dengan jumlah alamat IP Pod yang disediakan di setiap node akan memberi Anda jumlah total node yang dapat Anda miliki di 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 menjadi 250, Google Distributed Cloud akan menyediakan rentang sekitar 500 alamat IP, yang kira-kira setara dengan blok CIDR /23 (2(32-23) = 29 = 512). Jadi, jumlah node maksimum 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 bersifat tetap sehingga rencanakan dengan cermat 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 Anda dapat diperbarui untuk menambahkan lebih banyak Layanan saat Anda menskalakan cluster. Namun, Anda tidak dapat mengurangi rentang CIDR Layanan. Untuk mengetahui informasi selengkapnya, lihat Meningkatkan rentang jaringan Layanan.

Resource yang dicadangkan untuk daemon sistem

Secara default, Google Distributed Cloud otomatis mencadangkan resource di node untuk daemon sistem, seperti sshd atau udev. Resource CPU dan memori dicadangkan di node untuk daemon sistem sehingga daemon ini memiliki resource yang diperlukan. Tanpa fitur ini, Pod berpotensi menggunakan sebagian besar resource pada node, sehingga daemon sistem tidak dapat menyelesaikan tugasnya.

Secara khusus, Google Distributed Cloud mencadangkan 80 milicore CPU (80 mCPU) dan 280 Mebibyte (280 MiB) memori di setiap node untuk daemon sistem. Perhatikan bahwa unit CPU mCPU adalah seperseribu inti, sehingga 80/1000 atau 8% dari inti pada setiap node dicadangkan untuk daemon sistem. Jumlah resource yang dicadangkan kecil dan tidak berdampak signifikan pada performa Pod. Namun, kubelet pada node dapat mengeluarkan Pod jika penggunaan CPU atau memorinya melebihi jumlah yang telah dialokasikan untuknya.

Jaringan dengan MetalLB

Anda mungkin ingin menambah jumlah speaker MetalLB untuk mengatasi 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 mengurangi dampak keseluruhan dari kegagalan speaker tunggal.

MetalLB memerlukan konektivitas Lapisan 2 antara node load balancing. Dalam kasus ini, Anda mungkin dibatasi oleh jumlah node dengan konektivitas Layer 2 tempat Anda dapat menempatkan speaker MetalLB.

Rencanakan dengan cermat jumlah speaker MetalLB yang ingin Anda miliki di cluster dan tentukan jumlah node Layer 2 yang Anda butuhkan. Untuk mengetahui informasi selengkapnya, lihat Masalah skalabilitas MetalLB.

Selain itu, saat menggunakan mode load balancing gabungan, node panel kontrol juga harus berada di jaringan Layer 2 yang sama. Load balancing manual tidak memiliki batasan ini. Untuk mengetahui informasi selengkapnya, lihat Mode load balancer manual.

Menjalankan banyak node, Pod, dan Layanan

Menambahkan node, Pod, dan Layanan adalah cara untuk meningkatkan skala cluster Anda. Bagian berikut mencakup beberapa setelan dan konfigurasi tambahan yang harus Anda pertimbangkan saat meningkatkan jumlah node, Pod, dan Layanan di cluster Anda. Untuk mengetahui informasi tentang batas untuk dimensi ini dan hubungannya satu sama lain, lihat Batas.

Membuat cluster tanpa kube-proxy

Untuk membuat cluster berperforma tinggi yang dapat di-scale up untuk menggunakan sejumlah besar Layanan dan endpoint, sebaiknya buat cluster tanpa kube-proxy. Tanpa kube-proxy, cluster menggunakan GKE Dataplane V2 dalam mode kube-proxy-replacement. Mode ini menghindari konsumsi 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 selengkapnya, lihat Membuat cluster tanpa kube-proxy.

Konfigurasi CoreDNS

Bagian ini menjelaskan aspek CoreDNS yang memengaruhi skalabilitas untuk cluster Anda.

DNS Pod

Secara default, cluster Google Distributed Cloud menyuntikkan 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). Aplikasi Server DNS menambahkan semua domain penelusuran yang ditentukan sebelum mencari nama host yang diminta semula, yang mengurutkan pencarian seperti berikut saat me-resolve google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Setiap pencarian dilakukan untuk IPv4 (data A) dan IPv6 (data AAAA), sehingga 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 di akhir (google.com.). Deklarasi ini harus dilakukan di tingkat workload aplikasi. Untuk informasi selengkapnya, lihat halaman manual resolv.conf.

IPv6

Jika cluster tidak menggunakan IPv6, Anda dapat mengurangi permintaan DNS hingga setengahnya 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 kueri DNS yang penting dalam siklus proses aplikasi, sebaiknya gunakan node khusus untuk Deployment coredns. Deployment ini termasuk dalam domain kegagalan yang berbeda dengan aplikasi normal. Jika Anda memerlukan bantuan untuk menyiapkan node khusus untuk Deployment coredns, hubungi Cloud Customer Care.

Masalah skalabilitas MetalLB

MetalLB berjalan dalam mode aktif-pasif, yang berarti bahwa pada waktu tertentu, hanya ada satu speaker MetalLB yang melayani VIP LoadBalancer tertentu.

Failover

Sebelum Google Distributed Cloud rilis 1.28.0, dalam skala besar, failover MetalLB dapat memakan waktu lama dan dapat menimbulkan risiko keandalan pada cluster.

Batas koneksi

Jika ada VIP LoadBalancer tertentu, seperti Layanan Ingress, yang mengharapkan koneksi serentak mendekati atau lebih dari 30 ribu, kemungkinan node speaker yang menangani VIP akan kehabisan port yang tersedia. Karena batasan arsitektur, tidak ada mitigasi untuk masalah ini dari MetalLB. Pertimbangkan untuk beralih ke load balancing gabungan dengan BGP sebelum pembuatan cluster atau gunakan class ingress yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi Ingress.

Speaker load balancer

Secara default, Google Distributed Cloud menggunakan kumpulan node load balancer yang sama untuk bidang kontrol dan bidang data. Jika Anda tidak menentukan node pool load balancer (loadBalancer.nodePoolSpec), node pool bidang kontrol (controlPlane.nodePoolSpec) akan digunakan.

Untuk menambah jumlah speaker saat Anda menggunakan node pool bidang kontrol untuk load balancing, Anda harus menambah jumlah mesin bidang kontrol. Untuk deployment produksi, sebaiknya gunakan tiga node panel kontrol untuk ketersediaan tinggi. Meningkatkan jumlah node bidang kontrol di atas tiga untuk mengakomodasi speaker tambahan mungkin bukan penggunaan resource yang baik.

Konfigurasi ingress

Jika Anda mengharapkan hampir 30 ribu koneksi serentak 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 gabungan dengan BGP, yang tidak memiliki batasan yang sama.

Menyesuaikan komponen Cloud Logging dan Cloud Monitoring

Dalam cluster besar, bergantung 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 dan batas resource untuk komponen kemampuan pengamatan, 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 metrics-server juga dapat diskalakan dalam hal node, Pod, dan Service. Jika Anda mengalami masalah resource pada komponen ini, hubungi Cloud Customer Care.

Menggunakan sysctl untuk mengonfigurasi sistem operasi Anda

Sebaiknya sesuaikan konfigurasi sistem operasi untuk node agar paling sesuai dengan kasus penggunaan workload Anda. Parameter fs.inotify.max_user_watches dan fs.inotify.max_user_instances yang mengontrol jumlah resource inotify sering kali perlu disesuaikan. Misalnya, jika Anda melihat pesan error seperti berikut, Anda mungkin ingin mencoba melihat apakah parameter ini 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 menurut jenis beban kerja dan konfigurasi hardware. Anda dapat berkonsultasi tentang praktik terbaik OS tertentu dengan vendor OS Anda.

Praktik terbaik

Bagian ini menjelaskan praktik terbaik untuk menskalakan cluster Anda.

Menskalakan satu dimensi dalam satu waktu

Untuk meminimalkan masalah dan mempermudah melakukan roll back perubahan, jangan sesuaikan lebih dari satu dimensi dalam satu waktu. Menskalakan beberapa dimensi secara bersamaan dapat menyebabkan masalah bahkan di cluster yang lebih kecil. Misalnya, mencoba meningkatkan jumlah Pod yang dijadwalkan per node menjadi 110 sambil meningkatkan jumlah node dalam cluster menjadi 250 kemungkinan tidak akan berhasil karena jumlah Pod, jumlah Pod per node, dan jumlah node terlalu jauh.

Menskalakan cluster secara bertahap

Menskalakan cluster dapat memerlukan banyak resource. Untuk mengurangi risiko kegagalan operasi cluster atau terganggunya workload cluster, sebaiknya jangan mencoba membuat cluster besar dengan banyak node dalam satu operasi.

Membuat cluster hybrid atau mandiri tanpa node pekerja

Jika Anda membuat cluster hybrid atau mandiri besar dengan lebih dari 50 node pekerja, sebaiknya buat cluster ketersediaan tinggi (HA) dengan node bidang kontrol terlebih dahulu, lalu lakukan penskalaan secara bertahap. Operasi pembuatan cluster menggunakan cluster bootstrap, yang bukan HA dan oleh karena itu kurang andal. Setelah cluster hybrid atau mandiri HA dibuat, Anda dapat menggunakannya untuk menskalakan hingga lebih banyak node.

Menambah jumlah node pekerja dalam batch

Jika Anda memperluas cluster ke lebih banyak node pekerja, sebaiknya perluas secara bertahap. Sebaiknya tambahkan maksimal 20 node sekaligus. Hal ini terutama berlaku untuk cluster yang menjalankan workload penting.

Mengaktifkan penarikan gambar paralel

Secara default, kubelet menarik image secara berurutan, satu per satu. Jika Anda memiliki koneksi upstream yang buruk ke server image registry, penarikan image yang buruk dapat menghentikan seluruh antrean untuk node pool tertentu.

Untuk mengurangi risiko ini, sebaiknya tetapkan serializeImagePulls ke false dalam konfigurasi kubelet kustom. Untuk mengetahui petunjuk dan informasi selengkapnya, lihat Mengonfigurasi setelan penarikan image kubelet. Mengaktifkan penarikan image paralel dapat menyebabkan lonjakan dalam penggunaan bandwidth jaringan atau I/O disk.

Menyesuaikan permintaan dan batas resource aplikasi

Di lingkungan yang padat, beban kerja aplikasi dapat dikeluarkan. Kubernetes menggunakan mekanisme yang dirujuk untuk memberi peringkat pod jika terjadi pengusiran.

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 yang Siap GDC untuk deployment skala besar. Anda harus 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 memenuhi syarat dengan versi Google Distributed Cloud tertentu.
  • Vendor penyimpanan dapat mendukung skala tinggi yang ingin Anda deploy.

Mengonfigurasi cluster untuk ketersediaan tinggi

Penting untuk mengaudit deployment skala tinggi dan memastikan komponen penting dikonfigurasi untuk HA jika memungkinkan. Google Distributed Cloud mendukung opsi deployment HA untuk semua jenis cluster. Untuk mengetahui informasi selengkapnya, lihat Memilih model deployment. Untuk contoh file konfigurasi cluster deployment 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 skala besar.

Pantau metrik pemanfaatan dengan cermat

Anda harus memantau penggunaan kedua node dan komponen sistem individual serta memastikan keduanya memiliki margin aman yang memadai. Untuk melihat kemampuan pemantauan standar yang tersedia secara default, lihat Menggunakan dasbor bawaan.

Memantau konsumsi bandwidth

Pantau penggunaan bandwidth dengan cermat untuk memastikan jaringan tidak terlalu penuh, yang mengakibatkan penurunan performa untuk cluster Anda.

Meningkatkan performa etcd

Kecepatan disk sangat penting untuk performa dan stabilitas etcd. Disk yang lambat akan meningkatkan latensi permintaan etcd, yang dapat menyebabkan masalah stabilitas cluster. Untuk meningkatkan performa cluster, Google Distributed Cloud menyimpan objek Peristiwa 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 datanya 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 disk khusus memastikan bahwa dua instance etcd tidak berbagi I/O disk.

Dokumentasi etcd memberikan rekomendasi hardware tambahan untuk memastikan performa etcd terbaik saat menjalankan cluster 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 arti peringatan etcd "apply entries took too long"? dan Apa arti peringatan etcd "failed to send out heartbeat on time"?.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care. Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:

  • Persyaratan untuk membuka kasus dukungan.
  • Alat untuk membantu Anda memecahkan masalah, seperti konfigurasi lingkungan, log, dan metrik.
  • Komponen yang didukung.

Apa langkah selanjutnya?