ТЛ; ДР
- Да би се постигла висока видљивост контејнера и микросервиса, евиденције и примарне метрике нису довољни.
- За бржи опоравак и повећану отпорност, апликације треба да примењују принцип високе уочљивости (ХОП).
- На нивоу апликације, НОП захтева: правилно евидентирање, пажљиво праћење, проверу исправности и праћење перформанси/транзиције.
- Користите чекове као елемент НОР-а спремностПробе и ливенессПробе Кубернетес.
Шта је шаблон здравственог прегледа?
Приликом дизајнирања критичне и веома доступне апликације, веома је важно размишљати о таквом аспекту као што је толеранција грешака. Апликација се сматра толерантном на грешке ако се брзо опоравља од квара. Типична апликација у облаку користи архитектуру микросервиса – где је свака компонента смештена у посебан контејнер. А да бисте били сигурни да је апликација на к8с веома доступна када дизајнирате кластер, морате да пратите одређене обрасце. Међу њима је и шаблон здравствене провере. Дефинише како апликација саопштава к8с-у да је здрава. Ово није само информација о томе да ли под ради, већ и о томе како прима и одговара на захтеве. Што више Кубернетес зна о здрављу модула, доноси паметније одлуке о рутирању саобраћаја и балансирању оптерећења. Дакле, принцип високе уочљивости омогућава апликацији да благовремено одговори на захтеве.
Принцип високе уочљивости (ХОП)
Принцип високе уочљивости је један од . У архитектури микросервиса, услуге није брига како се њихов захтев обрађује (и то с правом), већ је важно како добијају одговоре од услуга које примају. На пример, за аутентификацију корисника, један контејнер шаље ХТТП захтев другом, очекујући одговор у одређеном формату - то је све. ПитхонЈС такође може да обради захтев, а Питхон Фласк може да одговори. Контејнери су као црне кутије са скривеним садржајем једни другима. Међутим, принцип НОП захтева да свака услуга изложи више крајњих тачака АПИ-ја које показују колико је здрава, као и њену спремност и статус толеранције грешака. Кубернетес захтева ове индикаторе да би размислио о следећим корацима за рутирање и балансирање оптерећења.
Добро дизајнирана апликација у облаку бележи своје главне догађаје користећи стандардне И/О токове СТДЕРР и СТДОУТ. Следеће долази помоћна услуга, на пример филебеат, логстасх или флуентд, која испоручује дневнике централизованом систему за праћење (на пример Прометхеус) и систему за прикупљање дневника (ЕЛК софтверски пакет). Дијаграм испод показује како апликација у облаку функционише у складу са обрасцем тестирања здравља и принципом високе уочљивости.
Како да примените образац здравствене провере у Кубернетесу?
Изван кутије, к8с прати статус подова помоћу једног од контролера (, , , итд, итд.). Откривши да је под из неког разлога пао, контролер покушава да га поново покрене или премести на други чвор. Међутим, модул може пријавити да је покренут и да ради, али сам не функционише. Дајемо пример: ваша апликација користи Апацхе као веб сервер, инсталирали сте компоненту на неколико подова кластера. Пошто је библиотека погрешно конфигурисана, сви захтеви апликацији одговарају кодом 500 (интерна грешка сервера). Приликом провере испоруке, провера статуса махуна даје успешан резултат, али купци мисле другачије. Ову непожељну ситуацију ћемо описати на следећи начин:
У нашем примеру, к8с ради провера функционалности. У овој врсти верификације, кубелет континуирано проверава стање процеса у контејнеру. Када схвати да је процес заустављен, поново ће га покренути. Ако се грешка може решити једноставним поновним покретањем апликације, а програм је дизајниран да се искључи у случају било какве грешке, онда је провера здравља процеса све што вам је потребно да бисте пратили НОП и образац за тестирање здравља. Једина штета је што се не отклањају све грешке поновним покретањем. У овом случају, к8с нуди 2 дубља начина за идентификацију проблема са подом: и .
ЛивенессПробе
Током ливенессПробе кубелет врши 3 врсте провера: не само да утврђује да ли је под покренут, већ и да ли је спреман да прими и адекватно одговори на захтеве:
- Подесите ХТТП захтев за под. Одговор мора да садржи ХТТП код одговора у опсегу од 200 до 399. Дакле, кодови 5кк и 4кк сигнализирају да под има проблема, иако је процес покренут.
- Да бисте тестирали подове са не-ХТТП услугама (на пример, Постфик сервер поште), потребно је да успоставите ТЦП везу.
- Изврши произвољну команду за под (интерно). Провера се сматра успешном ако је код за завршетак команде 0.
Пример како ово функционише. Следећа дефиниција под садржи НодеЈС апликацију која баца грешку 500 на ХТТП захтеве. Да бисмо били сигурни да се контејнер поново покреће када добије такву грешку, користимо параметар ливенессПробе:
apiVersion: v1
kind: Pod
metadata:
name: node500
spec:
containers:
- image: magalix/node500
name: node500
ports:
- containerPort: 3000
protocol: TCP
livenessProbe:
httpGet:
path: /
port: 3000
initialDelaySeconds: 5Ово се не разликује од било које друге дефиниције под, али ми додајемо објекат .spec.containers.livenessProbe. Параметар httpGet прихвата путању на коју се шаље ХТТП ГЕТ захтев (у нашем примеру ово је /, али у борбеним сценаријима може постојати нешто слично /api/v1/status). Друга ливенессПробе прихвата параметар initialDelaySeconds, који налаже операцији верификације да чека одређени број секунди. Одлагање је потребно јер је контејнеру потребно време да се покрене, а када се поново покрене биће недоступан неко време.
Да бисте применили ово подешавање на кластер, користите:
kubectl apply -f pod.yamlНакон неколико секунди, можете да проверите садржај модула помоћу следеће команде:
kubectl describe pods node500На крају излаза пронађите .
Као што видите, ливенессПробе је покренуо ХТТП ГЕТ захтев, контејнер је генерисао грешку 500 (за шта је и програмиран), а кубелет га је поново покренуо.
Ако се питате како је програмирана НидеЈС апликација, ево апп.јс и Доцкерфиле који су коришћени:
апп.јс
var http = require('http');
var server = http.createServer(function(req, res) {
res.writeHead(500, { "Content-type": "text/plain" });
res.end("We have run into an errorn");
});
server.listen(3000, function() {
console.log('Server is running at 3000')
})Доцкерфиле
FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]Важно је напоменути ово: ливенессПробе ће поново покренути контејнер само ако не успе. Ако поновно покретање не исправи грешку која спречава покретање контејнера, кубелет неће моћи да предузме мере да исправи проблем.
спремностПробе
реадинессПробе ради слично као и ливенессПробес (ГЕТ захтеви, ТЦП комуникација и извршавање команди), осим за акције за решавање проблема. Контејнер у коме је квар откривен се не покреће поново, већ је изолован од долазног саобраћаја. Замислите да један од контејнера обавља много прорачуна или је под великим оптерећењем, што доводи до повећања времена одговора. У случају ливенессПробе, покреће се провера доступности одговора (преко параметра провере тимеоутСецондс), након чега кубелет поново покреће контејнер. Када се покрене, контејнер почиње да извршава задатке који захтевају велике ресурсе и поново се покреће. Ово може бити критично за апликације којима је потребна брзина одговора. На пример, аутомобил док је на путу чека одговор од сервера, одговор је одложен - и аутомобил долази у несрећу.
Хајде да напишемо дефиницију рединессПробе која ће поставити време одговора ГЕТ захтева на не више од две секунде, а апликација ће одговорити на ГЕТ захтев након 5 секунди. Под.иамл датотека би требало да изгледа овако:
apiVersion: v1
kind: Pod
metadata:
name: nodedelayed
spec:
containers:
- image: afakharany/node_delayed
name: nodedelayed
ports:
- containerPort: 3000
protocol: TCP
readinessProbe:
httpGet:
path: /
port: 3000
timeoutSeconds: 2Хајде да поставимо под са кубецтл:
kubectl apply -f pod.yamlСачекајмо неколико секунди, а затим видимо како је радила РеадинессПробе:
kubectl describe pods nodedelayedНа крају излаза можете видети да су неки од догађаја слични .
Као што видите, кубецтл није поново покренуо под када је време провере премашило 2 секунде. Уместо тога, он је отказао захтев. Долазне комуникације се преусмеравају на друге, радне подове.
Имајте на уму да сада када је под истоварен, кубецтл поново усмерава захтеве ка њему: одговори на ГЕТ захтеве више не одлажу.
За поређење, испод је модификована датотека апп.јс:
var http = require('http');
var server = http.createServer(function(req, res) {
const sleep = (milliseconds) => {
return new Promise(resolve => setTimeout(resolve, milliseconds))
}
sleep(5000).then(() => {
res.writeHead(200, { "Content-type": "text/plain" });
res.end("Hellon");
})
});
server.listen(3000, function() {
console.log('Server is running at 3000')
})ТЛ; ДР
Пре појаве апликација у облаку, евиденције су биле примарно средство за праћење и проверу здравља апликација. Међутим, није било средстава да се предузму корективне мере. Дневници су и данас корисни; потребно их је прикупити и послати у систем прикупљања дневника за анализу ванредних ситуација и доношење одлука. [Све ово је могло да се уради без апликација у облаку користећи монит, на пример, али са к8с је постало много лакше :) – напомена уредника. ]
Данас се корекције морају вршити скоро у реалном времену, тако да апликације више не морају бити црне кутије. Не, требало би да приказују крајње тачке које омогућавају системима за праћење да постављају упите и прикупљају вредне податке о стању процеса како би могли одмах да одговоре ако је потребно. Ово се зове образац дизајна теста перформанси, који прати принцип високе уочљивости (ХОП).
Кубернетес подразумевано нуди 2 врсте провера здравља: реадинессПробе и ливенессПробе. Оба користе исте врсте провера (ХТТП ГЕТ захтеви, ТЦП комуникације и извршавање команди). Разликују се по томе које одлуке доносе као одговор на проблеме у махунама. ливенессПробе поново покреће контејнер у нади да се грешка неће поновити, а реадинессПробе изолује под од долазног саобраћаја док се не реши узрок проблема.
Одговарајући дизајн апликације треба да укључи оба типа провере и да обезбеди да прикупљају довољно података, посебно када се појави изузетак. Такође би требало да прикаже неопходне АПИ крајње тачке које обезбеђују систему за праћење (Прометхеус) важне здравствене метрике.
Извор: ввв.хабр.цом