Најдобри практики за контејнерите на Kubernetes: здравствени проверки

TL; ДР

• За да се постигне висока забележливост на контејнерите и микросервисите, трупците и примарните метрики не се доволни.
• За побрзо закрепнување и зголемена еластичност, апликациите треба да го применуваат Принципот за висока набљудуваност (HOP).
• На ниво на апликација, NOP бара: правилно евидентирање, внимателно следење, проверки на разумност и следење на перформанси/транзиција.
• Користете чекови како елемент на НИТИ подготвеностСонда и livenessProbe Кубернетис.

Што е шаблон за здравствена проверка?

Кога дизајнирате апликација која е критична за мисијата и многу достапна, многу е важно да се размислува за таков аспект како толеранција на грешки. Апликацијата се смета за толерантна за грешки ако брзо се опорави од дефект. Типична облак апликација користи микросервис архитектура - каде што секоја компонента се става во посебен контејнер. И за да бидете сигурни дека апликацијата на k8s е многу достапна кога дизајнирате кластер, треба да следите одредени шеми. Меѓу нив е и Шаблонот за здравствена проверка. Таа дефинира како апликацијата комуницира со k8s дека е здрава. Ова не е само информација за тоа дали подлогата работи, туку и за тоа како прима и одговара на барањата. Колку повеќе Kubernetes знае за здравјето на подлогата, толку попаметни одлуки носи за насочување на сообраќајот и балансирање на товарот. Така, Принципот за висока набљудуваност овозможува апликацијата да одговори на барањата навремено.

Принцип на висока набљудуваност (HOP)

Принципот на висока забележливост е еден од принципи за дизајнирање контејнеризирани апликации. Во архитектурата на микроуслугите, услугите не се грижат како се обработуваат нивните барања (и со право), туку важно е како добиваат одговори од услугите што примаат. На пример, за автентикација на корисник, еден контејнер испраќа барање за HTTP на друг, очекувајќи одговор во одреден формат - тоа е сè. PythonJS исто така може да го обработи барањето, а Python Flask може да одговори. Контејнерите се како црни кутии со скриени содржини едни на други. Сепак, принципот NOP бара секоја услуга да изложи повеќе крајни точки на API кои покажуваат колку е здрава, како и нејзината подготвеност и статусот на толеранција на грешки. Kubernetes ги бара овие индикатори за да размисли за следните чекори за рутирање и балансирање на оптоварување.

Добро дизајнираната облак апликација ги евидентира своите главни настани користејќи ги стандардните I/O преноси STDERR и STDOUT. Следува дополнителна услуга, на пример filebeat, logstash или fluentd, доставувајќи логови до централизиран систем за следење (на пример Prometheus) и систем за собирање дневници (софтверски пакет ELK). Дијаграмот подолу покажува како една апликација во облак функционира според Шемата за тестирање на здравјето и Принципот за висока набљудуваност.

Како да се примени моделот за проверка на здравјето во Кубернетес?

Надвор од кутијата, k8s го следи статусот на мешунките користејќи еден од контролорите (Распоредувања, ReplicaSets, DaemonSets, StatefulSets итн., итн.). Откако откри дека подлогата паднала поради некоја причина, контролорот се обидува да го рестартира или да го премести во друг јазол. Сепак, подлогата може да пријави дека е отворена и работи, но самиот тој не функционира. Да дадеме пример: вашата апликација користи Apache како веб-сервер, ја инсталиравте компонентата на неколку подлоги од кластерот. Бидејќи библиотеката е погрешно конфигурирана, сите барања до апликацијата одговараат со код 500 (грешка на внатрешен сервер). При проверка на испораката, проверката на статусот на мешунките дава успешен резултат, но клиентите размислуваат поинаку. Оваа несакана ситуација ќе ја опишеме на следниов начин:

Во нашиот пример, k8s го прави тоа проверка на функционалноста. Во овој тип на верификација, кубелетот континуирано ја проверува состојбата на процесот во контејнерот. Откако ќе разбере дека процесот е запрен, ќе го рестартира. Ако грешката може да се реши со едноставно рестартирање на апликацијата, а програмата е дизајнирана да се исклучува при секоја грешка, тогаш здравствената проверка на процесот е се што ви треба за да го следите NOP и моделот за здравствен тест. Единствената штета е што не се елиминираат сите грешки со рестартирање. Во овој случај, k8s нуди 2 подлабоки начини за идентификување на проблемите со подлогата: livenessProbe и подготвеностСонда.

LivenessProbe

За време на livenessProbe kubelet врши 3 типа на проверки: не само што одредува дали подлогата работи, туку и дали е подготвен да прима и соодветно да одговори на барањата:

• Поставете барање за HTTP на подлогата. Одговорот мора да содржи код за одговор HTTP во опсег од 200 до 399. Така, шифрите 5xx и 4xx сигнализираат дека подлогата има проблеми, иако процесот работи.
• За да ги тестирате подовите со услуги кои не се HTTP (на пример, серверот за пошта Postfix), треба да воспоставите TCP врска.
• Извршете произволна команда за pod (внатрешно). Проверката се смета за успешна ако кодот за комплетирање на командата е 0.

Пример за тоа како функционира ова. Следната дефиниција на pod содржи апликација NodeJS која исфрла грешка 500 на барањата HTTP. За да се увериме дека контејнерот е рестартиран кога добивате таква грешка, го користиме параметарот livenessProbe:

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

Ова не се разликува од која било друга дефиниција на pod, но додаваме објект .spec.containers.livenessProbe. Параметар httpGet ја прифаќа патеката до која се испраќа барањето HTTP GET (во нашиот пример ова е /, но во борбени сценарија може да има нешто слично /api/v1/status). Друга livenessProbe прифаќа параметар initialDelaySeconds, што и наложува на операцијата за верификација да чека одреден број секунди. Доцнењето е потребно затоа што на контејнерот му треба време да започне, а кога ќе се рестартира ќе биде недостапен некое време.

За да ја примените оваа поставка на кластер, користете:

kubectl apply -f pod.yaml

По неколку секунди, можете да ја проверите содржината на подлогата користејќи ја следнава команда:

kubectl describe pods node500

На крајот од излезот, пронајдете тоа е што.

Како што можете да видите, livenessProbe иницираше барање за HTTP GET, контејнерот генерира грешка 500 (што е она што беше програмирано да го прави), а kubelet го рестартираше.

Ако се прашувате како е програмирана апликацијата NideJS, еве ги app.js и Dockerfile кои беа користени:

апликација.js

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')
})

dockerfile

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

Важно е да се забележи ова: livenessProbe ќе го рестартира контејнерот само ако не успее. Ако рестартирањето не ја исправи грешката што го спречува контејнерот да работи, kubelet нема да може да преземе акција за да го поправи проблемот.

подготвеностСонда

ReadinessProbe работи слично како livenessProbes (GET барања, TCP комуникации и извршување на команди), освен за дејства за отстранување проблеми. Контејнерот во кој е откриен дефектот не се рестартира, туку е изолиран од дојдовниот сообраќај. Замислете дека еден од контејнерите врши многу пресметки или е под големо оптоварување, што предизвикува зголемување на времето на одговор. Во случај на livenessProbe, се активира проверката на достапноста на одговорот (преку параметарот за проверка timeoutSeconds), по што кубелетот го рестартира контејнерот. Кога ќе се стартува, контејнерот почнува да извршува задачи со интензивни ресурси и повторно се рестартира. Ова може да биде критично за апликациите на кои им е потребна брзина на одговор. На пример, автомобил додека е на пат чека одговор од серверот, одговорот е одложен - и автомобилот влегува во несреќа.

Ајде да напишеме дефиниција за redinessProbe која ќе го постави времето за одговор на барањето GET на не повеќе од две секунди, а апликацијата ќе одговори на барањето GET по 5 секунди. Датотеката pod.yaml треба да изгледа вака:

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

Ајде да распоредиме pod со kubectl:

kubectl apply -f pod.yaml

Ајде да почекаме неколку секунди и потоа да видиме како функционирала ReadinessProbe:

kubectl describe pods nodedelayed

На крајот од излезот можете да видите дека некои од настаните се слични оваа.

Како што можете да видите, kubectl не го рестартираше подот кога времето за проверка надмина 2 секунди. Наместо тоа, тој го откажа барањето. Дојдовните комуникации се пренасочуваат кон други, работни места.

Забележете дека сега кога подлогата е истоварена, kubectl повторно ги насочува барањата до него: одговорите на барањата GET веќе не се одложуваат.

За споредба, подолу е изменетата датотека app.js:

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')
})

TL; ДР
Пред појавата на облак апликациите, логовите беа примарно средство за следење и проверка на здравјето на апликациите. Сепак, немаше средства да се преземат какви било корективни мерки. Дневниците се сè уште корисни и денес; тие треба да се соберат и да се испратат до систем за собирање дневници за анализа на итни ситуации и донесување одлуки. [Сето ова можеше да се направи без облак апликации користејќи монит, на пример, но со k8 стана многу полесно :) – забелешка на уредникот. ]

Денес, корекции треба да се прават речиси во реално време, така што апликациите повеќе не мора да бидат црни кутии. Не, тие треба да прикажуваат крајни точки што им овозможуваат на системите за следење да бараат и собираат вредни податоци за состојбата на процесите за да можат веднаш да одговорат доколку е потребно. Ова се нарекува модел за дизајн на тест за изведба, кој го следи принципот на висока набљудуваност (HOP).

Kubernetes стандардно нуди 2 типа здравствени проверки: ReadinessProbe и livenessProbe. И двете користат исти типови на проверки (барања HTTP GET, TCP комуникации и извршување на команди). Тие се разликуваат во одлуките што ги носат како одговор на проблемите во мешунките. livenessProbe го рестартира контејнерот со надеж дека грешката нема да се повтори, а readinessProbe го изолира подлогата од дојдовниот сообраќај додека не се реши причината за проблемот.

Правилниот дизајн на апликацијата треба да ги вклучува двата вида на проверка и да се осигура дека тие собираат доволно податоци, особено кога е исклучок. Исто така, треба да ги прикаже потребните крајни точки на API кои му обезбедуваат на системот за следење (Прометеус) важни здравствени метрики.

Извор: www.habr.com