Seperti cluster Kubernetes lainnya, skalabilitas cluster Google Distributed Cloud memiliki banyak dan dimensi yang saling terkait. Dokumen ini dimaksudkan untuk membantu Anda memahami dimensi utama yang dapat Anda sesuaikan untuk meningkatkan skala cluster tanpa mengganggu workload Anda.
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 Service. Banyak di antaranya dimensi, seperti jumlah pod per node dan jumlah node per , saling terkait. Untuk informasi selengkapnya tentang dimensi yang memiliki dampak pada skalabilitas, lihat Skalabilitas Kubernetes minimum di bagian Scalability Special Resources Group (SIG) pada Kubernetes Repositori komunitas di GitHub.
Batas skalabilitas juga sensitif pada konfigurasi hardware dan node pada yang digunakan untuk menjalankan cluster Anda. Batas yang dijelaskan dalam dokumen ini adalah diverifikasi di lingkungan yang mungkin berbeda dari 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 memori dan CPU 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 Service yang dapat Anda miliki di cluster dikontrol oleh setelan berikut:
clusterNetwork.pods.cidrBlocks
menentukan jumlah Pod yang diizinkan di cluster Anda.nodeConfig.podDensity.maxPodsPerNode
menentukan jumlah maksimum Pod yang dapat dijalankan pada satu node.clusterNetwork.services.cidrBlocks
menentukan 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 yang membatasi faktor-faktor untuk meningkatkan skala cluster Anda. Setelan ini, ditambah dengan untuk pod maksimum per node, menentukan jumlah maksimum node yang dapat sendiri di cluster Anda sebelum Anda berisiko kehabisan alamat IP untuk pod Anda.
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, nilai192.168.0.0/16
yang terisi otomatis menentukan rentang 65.536 IP alamat dari192.168.0.0
hingga192.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 ulang IP Pod secara tidak sengaja dalam 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
, berarti Anda memiliki total 32.768
Alamat IP (2(32-17) = 215 = 32.768). Jika Anda menyetel
jumlah maksimum Pod per node menjadi 250, Google Distributed Cloud
menyediakan kisaran 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 maksimum yang direkomendasikan untuk Pod per
cluster, Pod per node, dan node per cluster berdasarkan pengujian. Lihat
Batas.
CIDR Layanan
CIDR Layanan Anda dapat diupdate untuk menambahkan Layanan lainnya saat Anda meningkatkan . Namun, Anda tidak dapat mengurangi rentang CIDR Layanan. Untuk selengkapnya informasi tambahan, lihat Meningkatkan Jaringan layanan rentang.
Resource yang dicadangkan untuk daemon sistem
Secara default, Google Distributed Cloud otomatis mencadangkan resource pada node untuk
daemon sistem, seperti sshd
atau udev
. Resource CPU dan memori dicadangkan
pada {i>node<i} untuk {i>daemon<i} sistem agar {i>
daemon<i} ini memiliki sumber daya yang
butuhkan. 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 cadangan resource kecil dan tidak memiliki dampak signifikan terhadap performa Pod. Namun, kubelet pada node dapat mengeluarkan Pod jika penggunaan CPU atau memori 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 jumlah {i>speaker<i} dan {i>bandwidth<i} dari setiap {i>node<i} 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. Di beberapa dalam kasus ini, Anda mungkin dibatasi oleh jumlah {i>node<i} dengan konektivitas Lapisan 2 di mana Anda dapat memasang 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 Service adalah salah satu cara untuk meningkatkan skala cluster Anda. Tujuan bagian berikut ini membahas beberapa setelan dan konfigurasi tambahan yang harus pertimbangkan saat Anda meningkatkan jumlah node, Pod, dan Service . 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 ditingkatkan skalanya untuk menggunakan
Layanan dan endpoint, sebaiknya Anda membuat cluster tanpa
kube-proxy
. Tanpa kube-proxy
, cluster menggunakan GKE Dataplane V2 di
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 klaster.
DNS Pod
Secara default, cluster Google Distributed Cloud menginjeksikan Pod dengan resolv.conf
yang
akan 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 bahwa 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
:
google.com.NAMESPACE.svc.cluster.local
google.com.svc.cluster.local
google.com.cluster.local
google.com.c.PROJECT_ID.internal
google.com.google.internal
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 Anda menyatakan
nama host yang akan dicari sebagai FQDN dengan menambahkan tanda titik (google.com.
). Ini
harus dilakukan pada level workload aplikasi. Untuk selengkapnya
informasi, lihat resolv.conf
halaman.
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.
Kumpulan node 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 pasif aktif,
yang berarti setiap saat ada
hanya satu speaker MetalLB yang menyajikan VIP LoadBalancer
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 keterbatasan arsitektur,
tidak ada mitigasi untuk masalah ini dari MetalLB. Pertimbangkan untuk beralih ke
load balancing paket dengan BGP sebelumnya
pembuatan cluster atau menggunakan class masuk 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 node load balancer
kolam renang
(loadBalancer.nodePoolSpec
),
kumpulan node bidang kontrol (controlPlane.nodePoolSpec
) 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 lebih dari tiga ke mengakomodasi pembicara tambahan mungkin bukan penggunaan sumber daya Anda dengan baik.
Konfigurasi traffic masuk
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 BGPnya. yang tidak memiliki keterbatasan praktik.
Menyesuaikan komponen Cloud Logging dan Cloud Monitoring
Dalam cluster besar, bergantung pada profil aplikasi dan pola traffic, konfigurasi resource default untuk Cloud Logging dan Komponen Cloud Monitoring mungkin tidak memadai. Untuk petunjuk tuning permintaan dan batas resource untuk komponen kemampuan observasi, Mengonfigurasi komponen Stackdriver resource.
Secara khusus, kube-state-metrics dalam cluster dengan sejumlah besar layanan
dan endpoint dapat menyebabkan penggunaan memori yang berlebihan
kube-state-metrics
itu sendiri dan gke-metrics-agent
pada node yang sama. Tujuan
penggunaan resource metrik-server juga
dapat diskalakan dalam hal node, Pod, dan
Layanan. Jika Anda mengalami masalah resource pada komponen ini, hubungi
Cloud Customer Care.
Gunakan sysctl untuk mengonfigurasi sistem operasi Anda
Sebaiknya sesuaikan konfigurasi sistem operasi untuk node Anda
agar cocok 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 ini, maka 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 workload 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 pada satu waktu
Untuk meminimalkan masalah dan mempermudah roll back perubahan, jangan menyesuaikan lebih banyak dari satu dimensi pada saat itu. Menskalakan beberapa dimensi secara bersamaan dapat menyebabkan masalah bahkan pada 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 Pod per node, dan jumlah node terlalu tinggi.
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 hibrida atau klaster mandiri besar dengan lebih dari 50 node pekerja, sebaiknya buat cluster ketersediaan tinggi (HA) dengan node bidang kontrol terlebih dahulu, lalu secara bertahap meningkatkan skalanya. Pembuatan cluster operasi menggunakan cluster bootstrap, yang bukan ketersediaan tinggi (HA), sehingga kurang dapat diandalkan. Setelah cluster hybrid atau mandiri dengan ketersediaan tinggi (HA) dibuat, Anda dapat menggunakan untuk meningkatkan skalanya ke lebih banyak node.
Meningkatkan jumlah worker node dalam batch
Jika Anda memperluas cluster ke lebih banyak worker node, sebaiknya perluas online. Sebaiknya tambahkan tidak lebih dari 20 node sekaligus. Ini adalah terutama untuk cluster yang menjalankan beban kerja kritis.
Aktifkan penarikan gambar paralel
Secara {i>default<i}, kubelet menarik gambar secara berurutan, satu per satu. Anda memiliki koneksi upstream yang buruk ke server {i> registry<i} {i>image<i} Anda, {i>image<i} yang buruk dapat menghentikan seluruh antrean untuk kumpulan node tertentu.
Untuk mengurangi hal ini, sebaiknya tetapkan serializeImagePulls
ke false
di
konfigurasi kubelet kustom. Untuk mendapatkan petunjuk dan informasi selengkapnya, lihat
Mengonfigurasi setelan pull image kubelet.
Mengaktifkan penarikan gambar paralel dapat menyebabkan lonjakan pemakaian jaringan
{i>bandwidth<i} atau I/O {i>disk<i}.
Menyesuaikan permintaan dan batas resource aplikasi
Dalam lingkungan padat, workload aplikasi mungkin akan 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.
Menggunakan partner penyimpanan
Sebaiknya gunakan salah satu penyimpanan Siap GDC GDC partner untuk deployment skala besar. Penting untuk mengonfirmasi informasi berikut dengan penyimpanan partner:
- Deployment penyimpanan mengikuti praktik terbaik untuk aspek penyimpanan, seperti ketersediaan tinggi, setelan prioritas, minat node, dan permintaan resource dan batasan.
- 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 skala tinggi Anda dan memastikan jika memungkinkan, konfigurasi komponennya untuk HA. 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 lainnya, termasuk:
- Vendor penyimpanan
- Webhook cluster
Memantau penggunaan resource
Bagian ini memberikan beberapa rekomendasi pemantauan dasar untuk skala besar klaster.
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 konsumsi 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 dll. {i>Disk<i} yang lambat meningkat
latensi permintaan etcd, yang dapat menyebabkan masalah stabilitas cluster. Kepada
meningkatkan performa cluster, Google Distributed Cloud menyimpan objek Event di
instance, dll. yang terpisah dan terdedikasi. {i>Instance <i}etcd standar menggunakan
/var/lib/etcd
sebagai direktori datanya 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 {i>etcd<i} memberikan informasi tambahan rekomendasi hardware untuk memastikan performa etcd terbaik saat menjalankan cluster Anda 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 dalam milidetik untuk persentil ke-99 (p99).
Untuk informasi selengkapnya tentang performa dst, lihat Apa fungsi peringatan etcd "penerapan entri memerlukan waktu terlalu lama" ? dan Apa arti peringatan dll. "gagal mengirimkan detak jantung tepat waktu" ?.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.