Saya mencipta Kube Eagle - pengeksport Prometheus. Ia ternyata menjadi perkara yang menarik yang membantu untuk lebih memahami sumber kluster kecil dan sederhana. Akhirnya, saya menjimatkan beratus-ratus dolar kerana saya memilih jenis mesin yang betul dan mengkonfigurasikan had sumber aplikasi untuk beban kerja.
Saya akan memberitahu anda tentang faedah , tetapi pertama-tama saya akan menerangkan apa yang menyebabkan kekecohan dan mengapa pemantauan berkualiti tinggi diperlukan.
Saya menguruskan beberapa kluster 4β50 nod. Setiap kluster mengandungi sehingga 200 perkhidmatan mikro dan aplikasi. Untuk menggunakan perkakasan sedia ada dengan lebih baik, kebanyakan penggunaan telah dikonfigurasikan dengan sumber RAM dan CPU yang boleh pecah. Dengan cara ini, pod boleh mengambil sumber yang tersedia jika perlu, dan pada masa yang sama tidak mengganggu aplikasi lain pada nod ini. Nah, bukankah ia hebat?
Dan walaupun kluster menggunakan CPU yang agak sedikit (8%) dan RAM (40%), kami sentiasa menghadapi masalah dengan pod yang didahulukan apabila mereka cuba memperuntukkan lebih banyak memori daripada yang tersedia pada nod. Pada masa itu kami hanya mempunyai satu papan pemuka untuk memantau sumber Kubernetes. seperti ini:
Papan pemuka Grafana dengan metrik cAdvisor sahaja
Dengan panel sedemikian, tidak menjadi masalah untuk melihat nod yang memakan banyak memori dan CPU. Masalahnya ialah untuk mengetahui apa sebabnya. Untuk mengekalkan pod di tempatnya, seseorang sudah tentu boleh menyediakan sumber terjamin pada semua pod (sumber yang diminta sama dengan had). Tetapi ini bukan penggunaan perkakasan yang paling bijak. Kelompok itu mempunyai beberapa ratus gigabait memori, manakala beberapa nod sedang kelaparan, manakala yang lain mempunyai 4β10 GB yang tinggal dalam simpanan.
Ternyata penjadual Kubernetes mengagihkan beban kerja secara tidak sekata merentas sumber yang tersedia. Penjadual Kubernetes mengambil kira konfigurasi yang berbeza: peraturan pertalian, kotoran dan toleransi, pemilih nod yang boleh mengehadkan nod yang tersedia. Tetapi dalam kes saya tiada apa-apa seperti itu, dan pod telah dirancang bergantung pada sumber yang diminta pada setiap nod.
Nod yang mempunyai sumber paling banyak percuma dan yang memenuhi syarat permintaan telah dipilih untuk pod. Kami mendapati bahawa sumber yang diminta pada nod tidak sepadan dengan penggunaan sebenar, dan di sinilah Kube Eagle dan keupayaan pemantauan sumbernya datang untuk menyelamatkan.
Saya mempunyai hampir semua kluster Kubernetes yang dipantau hanya dengan ΠΈ . Pengeksport Node menyediakan statistik tentang penggunaan I/O dan cakera, CPU dan RAM, manakala Kube State Metrics menunjukkan metrik objek Kubernetes seperti permintaan dan had CPU dan sumber memori.
Kami perlu menggabungkan metrik penggunaan dengan permintaan dan metrik had dalam Grafana, dan kemudian kami akan mendapat semua maklumat tentang masalah tersebut. Ini kedengaran mudah, tetapi kedua-dua alat itu sebenarnya menamakan label secara berbeza dan sesetengah metrik tidak mempunyai sebarang label metadata sama sekali. Kube Eagle melakukan segala-galanya sendiri dan panel kelihatan seperti ini:
Kami berjaya menyelesaikan banyak masalah dengan sumber dan menjimatkan peralatan:
- Sesetengah pembangun tidak tahu berapa banyak sumber perkhidmatan mikro yang diperlukan (atau hanya tidak mengganggu). Tidak ada cara untuk kami mencari permintaan sumber yang salah - untuk ini kami perlu mengetahui penggunaan serta permintaan dan had. Kini mereka melihat metrik Prometheus, memantau penggunaan sebenar dan melaraskan permintaan dan had.
- Aplikasi JVM mengambil seberapa banyak RAM yang mereka boleh kendalikan. Pengumpul sampah hanya mengeluarkan ingatan apabila lebih daripada 75% digunakan. Dan kerana kebanyakan perkhidmatan mempunyai memori yang boleh pecah, ia sentiasa diduduki oleh JVM. Oleh itu, semua perkhidmatan Java ini memakan lebih banyak RAM daripada yang dijangkakan.
- Sesetengah aplikasi meminta terlalu banyak memori, dan penjadual Kubernetes tidak memberikan nod ini kepada aplikasi lain, walaupun sebenarnya ia lebih bebas daripada nod lain. Seorang pembangun secara tidak sengaja menambahkan digit tambahan dalam permintaan dan meraih sekeping RAM yang besar: 20 GB dan bukannya 2. Tiada siapa yang perasan. Aplikasi ini mempunyai 3 replika, jadi sebanyak 3 nod telah terjejas.
- Kami memperkenalkan had sumber, menjadualkan semula pod dengan permintaan yang betul dan mendapat keseimbangan ideal penggunaan perkakasan merentas semua nod. Beberapa nod mungkin telah ditutup sama sekali. Dan kemudian kami melihat bahawa kami mempunyai mesin yang salah (berorientasikan CPU, bukan berorientasikan memori). Kami menukar jenis dan memadam beberapa lagi nod.
Keputusan
Dengan sumber yang boleh pecah dalam kelompok, anda menggunakan perkakasan yang tersedia dengan lebih cekap, tetapi penjadual Kubernetes menjadualkan pod berdasarkan permintaan untuk sumber, dan ini adalah penuh. Untuk membunuh dua burung dengan satu batu: untuk mengelakkan masalah dan menggunakan sumber sepenuhnya, anda memerlukan pemantauan yang baik. Inilah sebabnya ia akan berguna (Pengeksport Prometheus dan papan pemuka Grafana).
Sumber: www.habr.com