Јас го создадов Kube Eagle - извозник на Прометеј. Се покажа дека е кул работа што помага подобро да се разберат ресурсите на малите и средни кластери. На крајот, заштедив стотици долари бидејќи ги избрав вистинските типови на машини и ги конфигурирав ограничувањата на ресурсите на апликациите за оптоварување.
Ќе ви кажам за придобивките , но прво ќе објаснам што ја предизвика вревата и зошто беше потребно висококвалитетно следење.
Управував со неколку кластери од 4-50 јазли. Секој кластер содржи до 200 микросервиси и апликации. За подобра употреба на постоечкиот хардвер, повеќето распоредувања беа конфигурирани со распрсливи ресурси на RAM и процесорот. На овој начин, pods може да ги преземат достапните ресурси доколку е потребно, а во исто време да не се мешаат со другите апликации на овој јазол. Па, нели е супер?
И иако кластерот трошеше релативно малку процесор (8%) и RAM меморија (40%), постојано имавме проблеми со подигнувањето на подовите кога тие се обидоа да доделат повеќе меморија отколку што беше достапна на јазолот. Тогаш имавме само една контролна табла за следење на ресурсите на Кубернетес. Како ова:
Графана контролна табла само со метрика на cAdvisor
Со таков панел, не е проблем да се видат јазли кои јадат многу меморија и процесор. Проблемот е да се открие која е причината. За да се задржат мешунките на место, се разбира, може да се постават гарантирани ресурси на сите подлоги (бараните ресурси еднакви на лимитот). Но, ова не е најпаметната употреба на хардверот. Кластерот имаше неколку стотици гигабајти меморија, додека некои јазли гладуваа, додека на други им останаа 4-10 GB во резерва.
Излегува дека распоредувачот на Kubernetes нерамномерно ги распределувал оптоварувањата низ достапните ресурси. Распоредувачот на Kubernetes ги зема предвид различните конфигурации: правила за афинитет, дамки и толеранции, избирачи на јазли кои можат да ги ограничат достапните јазли. Но, во мојот случај немаше ништо такво, а подовите беа планирани во зависност од бараните ресурси на секој јазол.
Јазолот што има најмногу бесплатни ресурси и кој ги задоволува условите за барање е избран за подлогата. Откривме дека бараните ресурси на јазлите не се совпаѓаат со вистинското користење, и токму тука дојде до помош Kube Eagle и неговите способности за следење ресурси.
Имам речиси сите Kubernetes кластери следени само со и . Извозникот на јазли обезбедува статистика за користењето на влез/излез и диск, процесор и RAM меморија, додека Метриката на состојбата на Кубе покажува метрика на објекти на Кубернетес, како што се барањата и ограничувањата на ресурсите на процесорот и меморијата.
Треба да ја комбинираме метриката на користење со метриката за барања и ограничувања во Графана, а потоа ќе ги добиеме сите информации за проблемот. Ова звучи едноставно, но двете алатки всушност ги именуваат етикетите поинаку, а некои метрики воопшто немаат никакви етикети за метаподатоци. Kube Eagle прави се сам и панелот изгледа вака:
Успеавме да решиме многу проблеми со ресурси и да заштедиме опрема:
- Некои програмери не знаеја колку ресурси им се потребни на микросервисите (или едноставно не се мачеа). Немаше начин да најдеме неточни барања за ресурси - за ова треба да ја знаеме потрошувачката плус барањата и ограничувањата. Сега тие ја гледаат метриката на Прометеј, ја следат вистинската употреба и ги прилагодуваат барањата и ограничувањата.
- Апликациите на JVM земаат онолку RAM меморија колку што можат да поднесат. Собирачот на ѓубре ослободува меморија само кога се користи повеќе од 75%. И бидејќи повеќето услуги имаат рафална меморија, таа секогаш била окупирана од JVM. Затоа, сите овие Java услуги јадеа многу повеќе RAM од очекуваното.
- Некои апликации бараа премногу меморија, а распоредувачот на Kubernetes не ги даде овие јазли на други апликации, иако всушност тие беа послободни од другите јазли. Еден развивач случајно додаде дополнителна цифра во барањето и зграпчи големо парче RAM: 20 GB наместо 2. Никој не забележа. Апликацијата имаше 3 реплики, така што беа погодени дури 3 јазли.
- Воведовме ограничувања на ресурси, презакажавме подлоги со точни барања и добивме идеална рамнотежа на користење на хардверот низ сите јазли. Неколку јазли можеа да бидат целосно затворени. И тогаш видовме дека имаме погрешни машини (ориентирани кон процесорот, а не ориентирани кон меморијата). Го сменивме типот и избришавме уште неколку јазли.
Резултатите од
Со распрснети ресурси во кластерот, поефикасно го користите достапниот хардвер, но распоредувачот на Kubernetes закажува подлоги врз основа на барања за ресурси, и тоа е преполно. За да убиете две птици со еден камен: за да избегнете проблеми и максимално да ги искористите ресурсите, потребен ви е добар надзор. Ова е причината зошто тоа ќе биде корисно (Извозник на Прометеј и контролна табла на Графана).
Извор: www.habr.com