Prometey ixracatçısı olan Kube Eagle yaratdım. Kiçik və orta ölçülü klasterlərin resurslarını daha yaxşı başa düşməyə kömək edən gözəl bir şey olduğu ortaya çıxdı. Sonda yüzlərlə dollar qənaət etdim, çünki düzgün maşın növlərini seçdim və iş yükləri üçün tətbiq resurs məhdudiyyətlərini konfiqurasiya etdim.
Faydaları haqqında sizə məlumat verəcəyəm , amma əvvəlcə təlaşa səbəb olanı və yüksək keyfiyyətli monitorinqin nə üçün lazım olduğunu izah edəcəyəm.
4-50 qovşaqdan ibarət bir neçə klasteri idarə etdim. Hər klasterdə 200-ə qədər mikroservis və proqram var. Mövcud aparatdan daha yaxşı istifadə etmək üçün əksər yerləşdirmələr partlaya bilən RAM və CPU resursları ilə konfiqurasiya edilmişdir. Beləliklə, podlar lazım olduqda mövcud resursları götürə bilər və eyni zamanda bu qovşaqdakı digər proqramlara müdaxilə etmir. Yaxşı, əla deyilmi?
Klaster nisbətən az CPU (8%) və RAM (40%) istehlak etsə də, qovşaqda mövcud olandan daha çox yaddaş ayırmağa çalışdıqda, biz daim podların qarşısının alınması ilə bağlı problemlərlə üzləşdik. O vaxt Kubernetes resurslarını izləmək üçün yalnız bir tablomuz var idi. Bunun kimi:
Yalnız cAdvisor göstəriciləri ilə Grafana idarə paneli
Belə bir panellə çox yaddaş və CPU yeyən qovşaqları görmək problem deyil. Problem səbəbin nə olduğunu anlamaqdır. Podları yerində saxlamaq üçün, əlbəttə ki, bütün podlarda zəmanətli resurslar qurmaq olar (tələb olunan resurslar limitə bərabərdir). Lakin bu, aparatın ən ağıllı istifadəsi deyil. Çoxluqda bir neçə yüz giqabayt yaddaş var idi, bəzi qovşaqlar ac idi, digərlərində isə ehtiyatda 4-10 GB qaldı.
Məlum olub ki, Kubernetes planlaşdırıcısı iş yüklərini mövcud resurslar arasında qeyri-bərabər paylayıb. Kubernetes planlaşdırıcısı müxtəlif konfiqurasiyaları nəzərə alır: yaxınlıq, ləkələr və dözüm qaydaları, mövcud qovşaqları məhdudlaşdıra bilən qovşaq seçiciləri. Ancaq mənim vəziyyətimdə belə bir şey yox idi və podlar hər node üçün tələb olunan resurslardan asılı olaraq planlaşdırıldı.
Ən çox pulsuz resurslara malik olan və sorğu şərtlərinə cavab verən qovşaq pod üçün seçildi. Biz qovşaqlarda tələb olunan resursların faktiki istifadəyə uyğun gəlmədiyini aşkar etdik və Kube Eagle və onun resurs monitorinqi imkanlarının köməyinə buradan gəldik.
Demək olar ki, bütün Kubernetes klasterlərini yalnız onunla izləmişəm и . Node Exporter I/O və disk, CPU və RAM istifadəsi ilə bağlı statistika təqdim edir, Kube State Metrics isə sorğular, CPU və yaddaş resurs məhdudiyyətləri kimi Kubernetes obyekt ölçülərini göstərir.
İstifadə ölçülərini Grafana-da sorğular və məhdudiyyətlər ölçüləri ilə birləşdirməliyik və sonra problem haqqında bütün məlumatları əldə edəcəyik. Bu sadə səslənir, lakin iki alət əslində etiketləri fərqli adlandırır və bəzi ölçülərdə metadata etiketləri ümumiyyətlə yoxdur. Kube Eagle hər şeyi özü edir və panel belə görünür:
Resurslarla bir çox problemləri həll edə bildik və avadanlıqlara qənaət etdik:
- Bəzi tərtibatçılar mikroservislərə nə qədər resurs lazım olduğunu bilmirdilər (və ya sadəcə narahat etmirdilər). Resurslar üçün yanlış sorğular tapmaq üçün heç bir yol yox idi - bunun üçün istehlak, üstəgəl sorğu və limitləri bilməliyik. İndi onlar Prometheus göstəricilərini görür, faktiki istifadəni izləyir və sorğu və limitləri tənzimləyir.
- JVM proqramları idarə edə bildikləri qədər RAM alır. Zibil toplayıcı yalnız 75%-dən çox istifadə edildikdə yaddaşı buraxır. Əksər xidmətlərin partlaya bilən yaddaşı olduğundan, onu həmişə JVM tuturdu. Buna görə də, bütün bu Java xidmətləri gözləniləndən daha çox RAM yeyirdi.
- Bəzi proqramlar həddən artıq yaddaş tələb edirdi və Kubernetes planlayıcısı bu qovşaqları digər qovşaqlardan daha sərbəst olsa da, digər proqramlara vermədi. Bir tərtibatçı təsadüfən sorğuya əlavə rəqəm əlavə etdi və böyük bir RAM parçasını tutdu: 20 əvəzinə 2 GB. Heç kim fərq etmədi. Tətbiqin 3 replikası var idi, buna görə də 3 qovşaq təsirləndi.
- Biz resurs limitlərini təqdim etdik, düzgün sorğularla podları yenidən planlaşdırdıq və bütün qovşaqlarda aparat istifadəsi üçün ideal balans əldə etdik. Bir neçə qovşaq tamamilə bağlana bilərdi. Və sonra gördük ki, səhv maşınlarımız var (yaddaş yönümlü deyil, CPU yönümlü). Biz növü dəyişdirdik və daha bir neçə qovşağı sildik.
Nəticələri
Klasterdəki partlaya bilən resurslarla siz mövcud avadanlıqdan daha səmərəli istifadə edirsiniz, lakin Kubernetes planlaşdırıcısı resurs sorğularına əsaslanaraq podları planlaşdırır və bu, təhlükəlidir. İki quşu bir daşla öldürmək üçün: problemlərin qarşısını almaq və resurslardan tam istifadə etmək üçün yaxşı monitorinq lazımdır. Bu səbəbdən faydalı olacaq (Prometheus ixracatçısı və Grafana idarə paneli).
Mənbə: www.habr.com