Размеркаванымі сістэмамі бывае цяжка кіраваць па чынніку таго, што ў іх маецца мноства рухомых змяняных элементаў, і ўсе яны павінны звычайна працаваць для забеспячэння функцыянальнасці сістэмы. Калі адзін з элементаў выйдзе са строю, то сістэма павінна яго выявіць, абыйсці і выправіць, прычым усё гэта трэба рабіць аўтаматычна. У гэтай серыі "Kubernetes Best Practices" мы даведаемся, як наладжваць тэсты Readiness і Liveness для праверкі жыццяздольнасці кластара Kubernetes.
Праверка здароўя Health Check - гэта просты спосаб дазволіць сістэме ведаць, ці працуе асобнік вашага прыкладання ці не. Калі асобнік вашага прыкладання не працуе, то іншыя службы не павінны звяртацца да яго ці адпраўляць яму запыты. Замест гэтага запыт павінен быць адпраўлены іншаму асобніку прыкладання, які ўжо запушчаны або запусціцца пазней. Акрамя таго, сістэма павінна вярнуць вашаму з дадаткам згубленую працаздольнасць.
Па змаўчанні Kubernetes пачне адпраўляць трафік у pod, калі ўсе кантэйнеры ўсярэдзіне подаў будуць запушчаныя, і перазагружаць кантэйнеры, калі яны аварыйна завершаць працу. Для пачатку такія паводзіны сістэмы па змаўчанні можа быць досыць добрым, аднак вы можаце падвысіць надзейнасць разгортвання свайго прадукта, выкарыстоўваючы карыстацкія праверкі працаздольнасці.
На шчасце, Kubernetes дазваляе зрабіць гэта даволі проста, так што ігнараванню падобных праверак няма ніякіх апраўданняў. Kubernetes дае два тыпу тэстаў Health Check, прычым важна разумець адрозненні ва ўжыванні кожнага з іх.
Тэст гатоўнасці Readiness прызначаны для таго, каб паведамляць Kubernetes аб гатоўнасці вашага прыкладання абслугоўваць трафік. Перш чым дазволіць сэрвісу адправіць трафік у pod, Kubernetes павінен пераканацца ў паспяховасці праверкі гатоўнасці. Калі тэст Readiness дасць збой, Kubernetes спыніць адпраўляць трафік у pod, пакуль тэсціраванне не пройдзе паспяхова.
Тэст жыццяздольнасці Liveness паведамляе Kubernetes аб тым, жыва ці мёртва ваша прыкладанне. У першым выпадку Kubernetes пакіне яго ў спакоі, у другім выдаліць мёртвы pod і заменіць яго новым.
Давайце ўявім сабе сцэнар, у якім вашаму з дадаткам на «разаграванне» і запуск патрабуецца 1 хвіліна. Ваш сэрвіс не пачне працаваць, пакуль праграма цалкам не загрузіцца і не запусціцца, хоць працоўны працэс ужо пачаўся. Прычым у вас таксама ўзнікнуць праблемы, калі вы захочаце павялічыць маштаб гэтага разгортвання да некалькіх дзід, бо гэтыя копіі не павінны атрымліваць трафік, пакуль яны не будуць цалкам гатовыя. Аднак па змаўчанні Kubernetes запусціць адпраўку трафіку адразу ж пасля пачатку працэсаў усярэдзіне кантэйнера.
Пры выкарыстанні тэсту гатоўнасці Readiness, Kubernetes будзе чакаць, пакуль прыкладанне не будзе поўнасцю запушчана і толькі пасля гэтага дазволіць сэрвісу адпраўляць трафік на новую копію.
Давайце ўявім сабе іншы сцэнар, пры якім прыкладанне завісае на працяглы час, перастаючы абслугоўваць запыты. Паколькі працэс працягвае выконвацца, па змаўчанні Kubernetes палічыць, што ўсё ў парадку, і працягне адпраўляць запыты на непрацоўны pod. Але пры выкарыстанні Liveness, Kubernetes выявіць, што прыкладанне больш не абслугоўвае запыты, і па змаўчанні перазапусціць непрацоўны pod.
Разгледзім, з дапамогай чаго тэстуецца гатоўнасць і жыццяздольнасць. Існуе тры спосабу тэсціравання – HTTP, Сommand і TCP. Для праверкі вы можаце выкарыстоўваць любы з іх. Найбольш распаўсюджаны спосаб карыстацкага цеста - гэта HTTP probe.
Нават калі ваша прыкладанне не з'яўляецца HTTP-серверам, вы ўсё роўна можаце стварыць легкаважны HTTP-сервер усярэдзіне вашага прыкладання для ўзаемадзеяння з тэстам Liveness. Пасля гэтага Kubernetes пачне пінгаваць pod, і калі адказ HTTP будзе знаходзіцца ў дыяпазоне 200 ці 300 мс, гэта будзе азначаць, што pod "здаровы". У адваротным выпадку модуль будзе пазначаны як "нездаровы".
Для тэстаў з дапамогай Command Kubernetes выконвае каманду ўнутры вашага кантэйнера. Калі каманда вяртаецца з нулявым exit code, то кантэйнер будзе пазначаны як здаровы, у адваротным выпадку, пры атрыманні ліку exit status ад 1 да 255, кантэйнер будзе адзначаны як "хворы". Гэты спосаб тэставання карысны, калі вы не можаце ці не жадаеце запускаць HTTP-сервер, але здольныя запусціць каманду, якая праверыць "здароўе" вашага прыкладання.
Апошні механізм праверкі - гэта тэст TCP. Kubernetes паспрабуе ўсталяваць TCP злучэнне на паказаным порце. Калі гэта атрымоўваецца зрабіць, кантэйнер лічыцца здаровым, калі не - нежыццяздольным. Гэты спосаб можа спатрэбіцца, калі вы выкарыстоўваеце сцэнар, пры якім тэсціраванне з дапамогай HTTP-запыту або выканання каманды працуе не вельмі добра. Напрыклад, асноўнымі сэрвісамі для праверкі з дапамогай TCP будуць gRPC ці FTP.
Тэсты можна наладзіць некалькімі спосабамі з рознымі параметрамі. Вы можаце пазначыць, як часта яны павінны выконвацца, якія парогавыя значэння поспеху і няўдачы, як доўга чакаць адказаў. Больш падрабязная інфармацыю выкладзена ў дакументацыі да тэстаў Readiness і Liveness. Аднак ёсць адзін вельмі важны момант у наладзе тэсту Liveness - пачатковая ўстаноўка затрымкі тэсціравання initialDelaySeconds. Як я згадваў, няўдалае выкананне гэтага цеста прывядзе да перазапуску модуля. Таму вам трэба пераканацца, што тэсціраванне не пачнецца да таго часу, пакуль прыкладанне не будзе гатова да працы, інакш яно пачне цыклічна перазапускацца. Я рэкамендую выкарыстоўваць час стартапа P99 ці сярэдні час запуску прыкладання з буфера. Не забывайце карэктаваць гэтае значэнне па меры таго, як час запуску вашага прыкладання становіцца ўсё хутчэй ці запавольваецца.
Большасць адмыслоўцаў пацвердзіць, што Health Check з'яўляюцца абавязковай праверкай для любой размеркаванай сістэмы, і Kubernetes не з'яўляецца выключэннем. Выкарыстанне праверкі "здароўя" сэрвісаў забяспечвае надзейную і безадмоўную працу Kubernetes і не складае для карыстальнікаў ніякай працы.
Працяг будзе зусім хутка…
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com