Дистрибуираним системима може бити тешко управљати јер имају много покретних, променљивих елемената који су сви потребни да би исправно функционисали да би систем функционисао. Ако један од елемената поквари, систем мора да га открије, заобиђе и поправи, а све то мора да се уради аутоматски. У овој серији Кубернетес најбољих пракси, научићемо како да подесимо тестове спремности и живахности да бисмо тестирали здравље Кубернетес кластера.
Провера здравља је једноставан начин да обавестите систем да ли је инстанца ваше апликације покренута или не. Ако ваша инстанца апликације није у функцији, друге услуге не би требало да јој приступају нити да јој шаљу захтеве. Уместо тога, захтев се мора послати другој инстанци апликације која је већ покренута или ће бити покренута касније. Поред тога, систем би требало да врати изгубљену функционалност ваше апликације.
Подразумевано, Кубернетес ће почети да шаље саобраћај у под када су сви контејнери унутар модула покренути и поново покреће контејнере када се сруше. Ово подразумевано понашање система може бити довољно добро за почетак, али можете побољшати поузданост примене производа коришћењем прилагођених провера исправности.
На срећу, Кубернетес ово чини прилично лаким за извођење, тако да нема изговора за игнорисање ових провера. Кубернетес пружа две врсте провера здравља и важно је разумети разлике у начину на који се сваки користи.
Тест спремности је дизајниран да каже Кубернетесу да је ваша апликација спремна за руковање саобраћајем. Пре него што дозволи услузи да шаље саобраћај у под, Кубернетес мора да провери да ли је провера спремности успешна. Ако тест спремности не успе, Кубернетес ће престати да шаље саобраћај у под док тест не прође.
Тест Ливенесс говори Кубернетесу да ли је ваша апликација жива или мртва. У првом случају, Кубернетес ће га оставити на миру, у другом ће избрисати мртви под и заменити га новим.
Хајде да замислимо сценарио где је вашој апликацији потребно 1 минут да се загреје и покрене. Ваша услуга неће почети да ради док се апликација потпуно не учита и не покрене, иако је ток посла већ започео. Такође ћете имати проблема ако желите да проширите ову примену на више копија, јер те копије не би требало да примају саобраћај док не буду потпуно спремне. Међутим, по подразумеваној вредности, Кубернетес ће почети да шаље саобраћај чим почну процеси унутар контејнера.
Када користите тест спремности, Кубернетес ће сачекати док се апликација потпуно не покрене пре него што дозволи услузи да пошаље саобраћај на нову копију.
Замислимо још један сценарио у којем апликација дуго виси, заустављајући сервисирање захтева. Како процес наставља да се покреће, Кубернетес ће подразумевано претпоставити да је све у реду и наставити да шаље захтеве нефункционалном модулу. Али када се користи Ливенесс, Кубернетес ће открити да апликација више не испоручује захтеве и подразумевано ће поново покренути мртви под.
Погледајмо како се тестирају спремност и одрживост. Постоје три методе тестирања - ХТТП, Цомманд и ТЦП. Можете користити било који од њих за проверу. Најчешћи начин тестирања корисника је ХТТП сонда.
Чак и ако ваша апликација није ХТТП сервер, и даље можете да креирате лагани ХТТП сервер унутар апликације да бисте остварили интеракцију са Ливенесс тестом. Након овога, Кубернетес ће почети да пингује под, а ако је ХТТП одговор у опсегу од 200 или 300 мс, то ће указати да је под здрав. У супротном, модул ће бити означен као „нездрав“.
За командне тестове, Кубернетес покреће команду унутар вашег контејнера. Ако се команда врати са нултим излазним кодом, контејнер ће бити означен као здрав, у супротном, по пријему излазног статусног броја од 1 до 255, контејнер ће бити означен као „болестан“. Овај метод тестирања је користан ако не можете или не желите да покренете ХТТП сервер, али сте у могућности да покренете команду која ће проверити здравље ваше апликације.
Коначни механизам верификације је ТЦП тест. Кубернетес ће покушати да успостави ТЦП везу на наведеном порту. Ако је то могуће, контејнер се сматра здравим; ако није, сматра се неодрживим. Овај метод може бити користан ако користите сценарио у којем тестирање са ХТТП захтевом или извршавањем команде не функционише баш добро. На пример, главни сервиси за верификацију користећи ТЦП би били гРПЦ или ФТП.
Тестови се могу конфигурисати на неколико начина са различитим параметрима. Можете одредити колико често треба да се извршавају, који су прагови успеха и неуспеха и колико дуго треба чекати на одговоре. За више информација погледајте документацију за тестове спремности и издржљивости. Међутим, постоји једна веома важна тачка у подешавању теста Ливенесс - почетно подешавање кашњења тестирања инитиалДелаиСецондс. Као што сам поменуо, неуспех овог теста ће довести до поновног покретања модула. Зато морате да се уверите да тестирање не почне док апликација не буде спремна за рад, иначе ће почети да се креће кроз поновна покретања. Препоручујем да користите П99 време покретања или просечно време покретања апликације из бафера. Не заборавите да подесите ову вредност како време покретања ваше апликације буде брже или спорије.
Већина стручњака ће потврдити да су здравствене провере обавезна провера за сваки дистрибуирани систем, а Кубернетес није изузетак. Коришћење провера исправности услуге обезбеђује поуздан рад Кубернетес-а без проблема и корисницима је једноставан.
Ускоро ће се наставити...
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом