Meningkatkan skala 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 batasan

Google Distributed Cloud adalah sistem kompleks dengan platform integrasi yang besar. Ada memiliki banyak dimensi yang memengaruhi skalabilitas cluster. Misalnya, jumlah node hanya merupakan 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 Grup Minat Khusus (SIG) Skalabilitas di repositori Komunitas Kubernetes di GitHub.

Batas skalabilitas juga sensitif terhadap konfigurasi hardware dan node tempat cluster Anda berjalan. Batasan yang dijelaskan dalam dokumen ini diverifikasi di lingkungan yang mungkin berbeda dengan lingkungan Anda. Oleh karena itu, Anda mungkin tidak mereproduksi angka yang sama ketika lingkungan yang mendasarinya adalah faktor pembatas.

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

Mempersiapkan 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 untuk 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 Service

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

CIDR Pod dan jumlah node maksimum

Jumlah total alamat IP yang dicadangkan untuk Pod di cluster Anda adalah salah satu yang membatasi faktor-faktor untuk meningkatkan skala 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 adalah ditentukan dengan clusterNetwork.pods.cidrBlocks, yang mengambil rentang alamat IP yang ditentukan dalam CIDR notasi. Misalnya, nilai yang telah diisi sebelumnya 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 pada satu node ditentukan dengan nodeConfig.podDensity.maxPodsPerNode

  • Berdasarkan setelan pod maksimum per node, penyediaan Google Distributed Cloud kira-kira dua kali lebih banyak alamat IP ke {i>node<i}. Alamat IP tambahan membantu mencegah penggunaan kembali IP Pod secara tidak sengaja dalam jangka waktu singkat.

  • Membagi jumlah total alamat IP Pod dengan jumlah IP Pod yang disediakan pada setiap {i>node<i} memberi Anda jumlah total {i>node<i} yang Anda miliki di cluster Anda.

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, 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 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 cermat pertumbuhan cluster Anda di masa mendatang untuk menghindari kehabisan kapasitas node. Untuk batas 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 sumber daya pada {i>node<i}, sehingga {i>daemon<i} sistem tidak dapat menyelesaikan tugas tugas klasifikasi.

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

Berjejaring dengan MetalLB

Anda mungkin ingin menambah jumlah speaker MetalLB untuk mengatasi masalah berikut aspek:

  • Bandwidth: seluruh bandwidth cluster untuk layanan load balancing bergantung pada jumlah speaker dan bandwidth setiap node speaker. Meningkat lalu lintas jaringan akan membutuhkan lebih banyak {i>speaker<i}.

  • Fault tolerance: lebih banyak pembicara mengurangi dampak keseluruhan speaker gagal.

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

Rencanakan dengan cermat jumlah speaker MetalLB yang ingin Anda miliki di cluster dan tentukan berapa banyak {i>node<i} Lapisan 2 yang Anda butuhkan. Untuk informasi selengkapnya, lihat Masalah skalabilitas MetalLB.

Secara terpisah, saat menggunakan mode load balancing yang dipaketkan, bidang kontrol node juga harus berada di bawah 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 Layanan adalah cara untuk menskalakan cluster Anda. Bagian berikut membahas beberapa setelan dan konfigurasi tambahan yang harus Anda pertimbangkan saat meningkatkan jumlah node, Pod, dan Layanan di cluster. Untuk mendapatkan informasi tentang batas dimensi ini dan caranya saling terkait, lihat Batas.

Membuat cluster tanpa kube-proxy

Untuk membuat cluster berperforma tinggi yang dapat diskalakan untuk menggunakan Layanan dan endpoint dalam jumlah besar, 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 iptable.

Anda tidak dapat menonaktifkan penggunaan kube-proxy untuk cluster yang ada. Ini konfigurasi harus disiapkan saat cluster dibuat. Untuk 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 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 tertentu sebelum mencari nama {i>host<i} yang pertama kali diminta, 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), menghasilkan 12 permintaan DNS untuk setiap kueri non-FQDN, yang secara signifikan akan memperkuat traffic DNS. Untuk mengurangi masalah ini, sebaiknya deklarasikan nama host untuk dicari sebagai FQDN dengan menambahkan titik di akhir (google.com.). Deklarasi ini harus dilakukan di tingkat beban kerja aplikasi. Untuk informasi selengkapnya, lihat halaman manual resolv.conf.

IPv6

Jika cluster tidak menggunakan IPv6, ada kemungkinan untuk mengurangi permintaan DNS dengan dengan menghapus pencarian kumpulan data AAAA ke server DNS upstream. Jika Anda memerlukan bantuan untuk menonaktifkan pencarian AAAA, hubungi Cloud Customer Care.

Node pool khusus

Karena sifat kritis dari kueri DNS dalam siklus hidup aplikasi, kami sebaiknya gunakan node khusus untuk Deployment coredns. Ini Deployment berada dalam domain kegagalan yang berbeda dari aplikasi normal. Jika Anda memerlukan bantuan untuk menyiapkan node khusus untuk Deployment coredns, hubungi kami ke Cloud Customer Care.

Masalah skalabilitas MetalLB

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

Failover

Sebelum Google Distributed Cloud merilis 1.28.0, dalam skala besar, failover MetalLB memerlukan waktu yang lama dan dapat menimbulkan risiko keandalan .

Batas koneksi

Jika ada VIP LoadBalancer tertentu, seperti Layanan Ingress, mengharapkan hampir atau lebih dari 30 ribu koneksi serentak, maka ada kemungkinan node speaker yang menangani VIP mungkin habis tersedia port. Karena batasan 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 traffic masuk.

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 kumpulan node load balancer (loadBalancer.nodePoolSpec), kumpulan node bidang kontrol (controlPlane.nodePoolSpec) akan digunakan.

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

Konfigurasi ingress

Jika Anda mengharapkan 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, bergantung pada profil aplikasi dan pola traffic, konfigurasi resource default untuk komponen Cloud Logging dan Cloud Monitoring mungkin tidak memadai. Untuk petunjuk cara menyesuaikan permintaan dan batas resource untuk komponen visibilitas, lihat Mengonfigurasi resource komponen Stackdriver.

Secara khusus, kube-state-metrics di cluster dengan sejumlah besar layanan dan endpoint dapat menyebabkan penggunaan memori yang berlebihan pada kube-state-metrics itu sendiri dan gke-metrics-agent di node yang sama. Penggunaan resource server metrik juga dapat diskalakan 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 sesuaikan konfigurasi sistem operasi untuk node Anda agar sesuai dengan kasus penggunaan workload Anda. fs.inotify.max_user_watches dan Parameter fs.inotify.max_user_instances yang mengontrol jumlah inotify resource sering kali memerlukan tuning. Misalnya, jika Anda melihat pesan error seperti berikut, sebaiknya coba lihat 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 konsultasikan tentang praktik terbaik OS khusus dengan vendor OS Anda.

Praktik terbaik

Bagian ini menjelaskan praktik terbaik untuk meningkatkan skala cluster Anda.

Menskalakan satu dimensi dalam satu waktu

Untuk meminimalkan masalah dan mempermudah untuk melakukan roll back perubahan, jangan menyesuaikan lebih dari satu dimensi pada 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 di cluster ke 250 kemungkinan tidak akan berhasil karena jumlah Pod, jumlah untuk tiap node, dan jumlah node yang terlalu banyak.

Menskalakan cluster secara bertahap

Peningkatan skala cluster dapat memerlukan banyak resource. Untuk mengurangi risiko cluster jika operasi gagal atau beban kerja cluster terganggu, sebaiknya jangan mencoba membuat cluster besar dengan banyak {i>node<i} dalam satu operasi.

Membuat cluster hybrid atau mandiri tanpa worker node

Jika Anda membuat cluster hybrid atau mandiri besar dengan lebih dari 50 node pekerja, sebaiknya buat cluster ketersediaan tinggi (HA) dengan node control plane terlebih dahulu, lalu tingkatkan skalanya secara bertahap. Pembuatan cluster operasi menggunakan cluster bootstrap, yang bukan ketersediaan tinggi (HA), sehingga kurang dapat diandalkan. Setelah cluster hibrida atau mandiri HA dibuat, Anda dapat menggunakan untuk meningkatkan skalanya ke lebih banyak node.

Meningkatkan jumlah node pekerja dalam batch

Jika Anda memperluas cluster ke lebih banyak worker node, sebaiknya perluas online. Sebaiknya tambahkan tidak lebih dari 20 node sekaligus. Hal ini terutama berlaku untuk cluster yang menjalankan workload penting.

Mengaktifkan pengambilan gambar paralel

Secara {i>default<i}, kubelet menarik gambar secara berurutan, satu per satu. Jika Anda memiliki koneksi upstream yang buruk ke server registry image, pull image yang buruk dapat menghambat seluruh antrean untuk node pool 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 pengambilan gambar paralel dapat menyebabkan lonjakan dalam konsumsi bandwidth jaringan atau I/O disk.

Menyesuaikan permintaan dan batas resource aplikasi

Dalam lingkungan yang padat, beban kerja aplikasi mungkin dihapus. Kubernetes menggunakan mekanisme yang direferensikan untuk menentukan peringkat pod jika terjadi penghapusan.

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 selengkapnya informasi selengkapnya, lihat Menyiapkan Kubernetes berbasis cloud profesional di Cloud Architecture Center.

Menggunakan partner penyimpanan

Sebaiknya gunakan salah satu penyimpanan Siap GDC GDC partner 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 layanan khusus Cloud .
  • Vendor penyimpanan dapat mendukung skala tinggi yang ingin Anda deploy.

Mengonfigurasi cluster untuk ketersediaan tinggi

Penting untuk mengaudit deployment berskala tinggi dan memastikan komponen kritis dikonfigurasi untuk HA jika memungkinkan. Dukungan Google Distributed Cloud Opsi deployment HA untuk semua jenis cluster. Untuk informasi selengkapnya, lihat Memilih model deployment. Misalnya cluster deployment HA, lihat file konfigurasi 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 penggunaan dengan cermat

Sangatlah penting untuk memantau penggunaan node dan setiap sistem komponennya dan memastikannya memiliki margin yang aman. Untuk melihat apa kemampuan pemantauan standar tersedia secara default, lihat Menggunakan dasbor.

Memantau penggunaan bandwidth

Pantau pemakaian bandwidth dengan cermat untuk memastikan jaringan tidak tersaturasi, yang menyebabkan penurunan performa cluster Anda.

Meningkatkan performa dll.

Kecepatan disk sangat penting untuk performa dan stabilitas etcd. {i>Disk<i} yang lambat meningkat latensi permintaan etcd, yang dapat menyebabkan masalah stabilitas cluster. Untuk meningkatkan performa cluster, Google Distributed Cloud menyimpan objek Peristiwa di instance etcd khusus yang terpisah. Instance etcd standar menggunakan /var/lib/etcd sebagai direktori data dan port 2379 untuk permintaan klien. Tujuan Instance etcd-events menggunakan /var/lib/etcd-events sebagai direktori dan port data 2382 untuk permintaan klien.

Sebaiknya gunakan solid-state disk (SSD) untuk penyimpanan etcd Anda. Sebagai performa optimal, pasang disk terpisah ke /var/lib/etcd dan /var/lib/etcd-events. Menggunakan {i>disk<i} khusus memastikan bahwa kedua disk tidak berbagi I/O disk.

Dokumentasi etcd memberikan rekomendasi hardware tambahan untuk memastikan performa etcd terbaik saat menjalankan cluster dalam produksi.

Untuk memeriksa performa disk dan etcd Anda, gunakan latensi I/O etcd berikut di Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: durasi 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 informasi selengkapnya tentang performa etcd, lihat Apa yang dimaksud dengan peringatan etcd "apply entries took too long" ? dan Apa yang dimaksud dengan peringatan etcd "failed to send out heartbeat on time" ?.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Apa langkah selanjutnya?