Дистрибуираните системи може да биде тешко да се управуваат бидејќи имаат многу подвижни, променливи елементи кои сите треба да работат правилно за системот да функционира. Ако некој од елементите не успее, системот мора да го открие, да го заобиколи и да го поправи, а сето тоа мора да се направи автоматски. Во оваа серија Кубернетес најдобри практики, ќе научиме како да поставиме тестови за подготвеност и живост за да го тестираме здравјето на кластерот на Кубернетес.
Health Check е едноставен начин да му дадете на системот да знае дали вашата апликација работи или не. Ако вашиот примерок на апликација е неактивен, тогаш другите услуги не треба да пристапуваат до него или да испраќаат барања до него. Наместо тоа, барањето мора да се испрати до друг примерок од апликацијата што веќе работи или ќе биде стартувана подоцна. Покрај тоа, системот треба да ја врати изгубената функционалност на вашата апликација.
Стандардно, Kubernetes ќе започне да испраќа сообраќај до подлогата кога ќе работат сите контејнери во подлогата и ќе ги рестартира контејнерите кога ќе паднат. Ова стандардно однесување на системот може да биде доволно добро за почеток, но можете да ја подобрите доверливоста на распоредувањето на вашиот производ со користење на прилагодени проверки на разумност.
За среќа, Kubernetes го прави ова прилично лесно, така што нема оправдување за игнорирање на овие проверки. Kubernetes обезбедува два вида здравствени проверки и важно е да се разберат разликите во начинот на кој се користи секој од нив.
Тестот за подготвеност е дизајниран да му каже на Kubernetes дека вашата апликација е подготвена да се справи со сообраќајот. Пред да дозволи услугата да испраќа сообраќај до подлога, Kubernetes мора да потврди дали проверката на подготвеноста е успешна. Ако тестот за подготвеност не успее, Kubernetes ќе престане да испраќа сообраќај до подлогата додека тестот не помине.
Тестот Liveness му кажува на Kubernetes дали вашата апликација е жива или мртва. Во првиот случај, Kubernetes ќе го остави на мира, во вториот ќе ја избрише мртвата подлога и ќе ја замени со нова.
Ајде да замислиме сценарио каде на вашата апликација и треба 1 минута за да се загрее и стартува. Вашата услуга нема да почне да работи додека апликацијата не се вчита целосно и не работи, иако работниот тек е веќе започнат. Исто така, ќе имате проблеми ако сакате да го зголемите ова распоредување на повеќе копии, бидејќи тие копии не треба да добиваат сообраќај додека не бидат целосно подготвени. Сепак, стандардно, Kubernetes ќе започне да испраќа сообраќај штом ќе започнат процесите во контејнерот.
Кога го користите тестот за подготвеност, Kubernetes ќе почека додека апликацијата целосно не се активира пред да дозволи услугата да испраќа сообраќај до новата копија.
Ајде да замислиме друго сценарио во кое апликацијата виси долго време, запирајќи ги барањата за сервисирање. Како што процесот продолжува да работи, стандардно Kubernetes ќе претпостави дека сè е во ред и ќе продолжи да испраќа барања до неработен подлога. Но, кога користи Liveness, Kubernetes ќе открие дека апликацијата повеќе не опслужува барања и стандардно ќе го рестартира мртвиот подлог.
Ајде да погледнеме како се тестираат подготвеноста и одржливоста. Постојат три методи за тестирање - HTTP, Command и TCP. Можете да користите било кој од нив за да проверите. Најчестиот начин за тестирање на корисникот е HTTP сонда.
Дури и ако вашата апликација не е HTTP сервер, сепак можете да креирате лесен HTTP сервер во вашата апликација за да комуницирате со тестот Liveness. После ова, Kubernetes ќе почне да го пингува подлогот и ако одговорот на HTTP е во опсег од 200 или 300 ms, тоа ќе укаже дека подлогата е здрава. Во спротивно, модулот ќе биде означен како „нездрав“.
За командни тестови, Kubernetes ја извршува командата во вашиот контејнер. Ако командата се врати со нулта излезна шифра, тогаш контејнерот ќе биде означен како здрав, во спротивно, по добивањето на излезниот статусен број од 1 до 255, контејнерот ќе биде означен како „болен“. Овој метод на тестирање е корисен ако не можете или не сакате да извршите HTTP сервер, но можете да извршите команда што ќе го провери здравјето на вашата апликација.
Конечниот механизам за верификација е TCP тестот. Kubernetes ќе се обиде да воспостави TCP врска на наведената порта. Ако ова може да се направи, садот се смета за здрав, а ако не, се смета за неостварлив. Овој метод може да биде корисен ако користите сценарио каде што тестирањето со барање HTTP или извршување на командата не функционира многу добро. На пример, главните услуги за верификација со користење на TCP би биле gRPC или FTP.
Тестовите може да се конфигурираат на неколку начини со различни параметри. Можете да одредите колку често тие треба да се извршуваат, кои се праговите за успех и неуспех и колку долго да чекате за одговори. За повеќе информации, видете ја документацијата за тестовите за подготвеност и живост. Сепак, постои една многу важна точка во поставувањето на тестот Liveness - почетната поставка на доцнењето на тестирањето initialDelaySeconds. Како што споменав, неуспехот на овој тест ќе резултира со рестартирање на модулот. Затоа, треба да бидете сигурни дека тестирањето нема да започне додека апликацијата не е подготвена за работа, инаку ќе почне да се движи со велосипед до рестартирање. Препорачувам да го користите времето за стартување P99 или просечното време за стартување на апликацијата од баферот. Не заборавајте да ја прилагодите оваа вредност бидејќи времето за стартување на вашата апликација станува побрзо или побавно.
Повеќето експерти ќе потврдат дека здравствените проверки се задолжителна проверка за кој било дистрибуиран систем, а Kubernetes не е исклучок. Користењето здравствени проверки на услугата обезбедува сигурна, непроблематична работа на Kubernetes и е без напор за корисниците.
Продолжува наскоро...
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB DDR4).
Dell R730xd 2 пати поевтин во центарот за податоци Equinix Tier IV во Амстердам? Само овде во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за
Извор: www.habr.com