Най-добри практики за контейнери на Kubernetes: Проверка на състоянието

TL; DR

• За да се постигне висока видимост на контейнерите и микроуслугите, регистрационните файлове и първичните показатели не са достатъчни.
• За по-бързо възстановяване и повишена устойчивост приложенията трябва да прилагат принципа на висока видимост (HOP).
• На ниво приложение, NOP изисква: правилно регистриране, внимателно наблюдение, проверки за разумност и проследяване на производителност/преход.
• Използвайте проверки като елемент на NOR готовностПроба и livenessProbe Kubernetes.

Какво е шаблон за проверка на състоянието?

Когато проектирате критично за мисията и високо достъпно приложение, е много важно да помислите за такъв аспект като толерантност към грешки. Едно приложение се счита за устойчиво на грешки, ако се възстановява бързо след повреда. Типично облачно приложение използва архитектура на микроуслуги - където всеки компонент се поставя в отделен контейнер. И за да сте сигурни, че приложението на k8s е много достъпно, когато проектирате клъстер, трябва да следвате определени модели. Сред тях е шаблонът за проверка на състоянието. Той определя как приложението съобщава на k8s, че е здраво. Това не е само информация за това дали подът работи, но и за това как получава и отговаря на заявки. Колкото повече Kubernetes знае за здравето на групата, толкова по-интелигентни решения взема относно маршрутизирането на трафика и балансирането на натоварването. По този начин принципът на висока наблюдаемост позволява на приложението да отговаря на заявки своевременно.

Принцип на висока наблюдаемост (HOP)

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

Едно добре проектирано облачно приложение регистрира основните си събития, използвайки стандартните I/O потоци STDERR и STDOUT. Следва спомагателна услуга, например filebeat, logstash или fluentd, доставяща регистрационни файлове до централизирана система за наблюдение (например Prometheus) и система за събиране на регистрационни файлове (софтуерен пакет ELK). Диаграмата по-долу показва как работи едно облачно приложение според шаблона за тестване на здравето и принципа на висока видимост.

Как да приложите шаблона за проверка на здравето в Kubernetes?

Извън кутията, k8s следи състоянието на модулите с помощта на един от контролерите (Разгръщането, ReplicaSets, DaemonSets, StatefulSets и т.н. и т.н.). След като установи, че модулът е паднал по някаква причина, контролерът се опитва да го рестартира или да го премести на друг възел. Въпреки това, група може да съобщи, че е готова и работи, но самата тя не функционира. Нека дадем пример: вашето приложение използва Apache като уеб сървър, инсталирали сте компонента на няколко подове на клъстера. Тъй като библиотеката е конфигурирана неправилно, всички заявки към приложението отговарят с код 500 (вътрешна сървърна грешка). При проверка на доставката проверката на състоянието на шушулките дава успешен резултат, но клиентите мислят различно. Ще опишем тази нежелана ситуация, както следва:

В нашия пример k8s го прави проверка на функционалността. При този тип проверка kubelet непрекъснато проверява състоянието на процеса в контейнера. След като разбере, че процесът е спрял, той ще го рестартира. Ако грешката може да бъде разрешена чрез просто рестартиране на приложението и програмата е проектирана да се изключва при всяка грешка, тогава проверката на изправността на процеса е всичко, от което се нуждаете, за да следвате NOP и шаблона за тестване на здравето. Единственото жалко е, че не всички грешки се елиминират чрез рестартиране. В този случай k8s предлага 2 по-задълбочени начина за идентифициране на проблеми с капсулата: livenessProbe и готовностПроба.

LivenessProbe

По време на livenessProbe kubelet извършва 3 вида проверки: не само определя дали pod работи, но и дали е готов да получава и да отговаря адекватно на заявки:

• Настройте HTTP заявка към групата. Отговорът трябва да съдържа HTTP код за отговор в диапазона от 200 до 399. Така кодовете 5xx и 4xx сигнализират, че подът има проблеми, въпреки че процесът работи.
• За да тествате pods с не-HTTP услуги (например пощенския сървър Postfix), трябва да установите TCP връзка.
• Изпълнение на произволна команда за под (вътрешно). Проверката се счита за успешна, ако кодът за завършване на командата е 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:

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

Докер файл

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

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

готовностПроба

readinessProbe работи подобно на livenessProbes (GET заявки, TCP комуникации и изпълнение на команди), с изключение на действията за отстраняване на неизправности. Контейнерът, в който е открита грешката, не се рестартира, но се изолира от входящия трафик. Представете си, че един от контейнерите извършва много изчисления или е под голямо натоварване, което води до увеличаване на времето за реакция. В случай на livenessProbe, проверката за наличност на отговора се задейства (чрез параметъра за проверка timeoutSeconds), след което kubelet рестартира контейнера. Когато се стартира, контейнерът започва да изпълнява задачи, изискващи ресурси, и се рестартира отново. Това може да бъде критично за приложения, които се нуждаят от скорост на реакция. Например, кола, докато е на пътя, чака отговор от сървъра, отговорът се забавя - и колата попада в катастрофа.

Нека напишем дефиниция на 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

Нека разположим под с 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; DR
Преди появата на облачните приложения, регистрационните файлове бяха основното средство за наблюдение и проверка на изправността на приложенията. Нямаше обаче средства да се предприемат каквито и да било коригиращи действия. Регистрационните файлове са все още полезни днес; те трябва да бъдат събрани и изпратени до система за събиране на регистрационни файлове за анализиране на извънредни ситуации и вземане на решения. [Всичко това може да се направи без облачни приложения, използващи monit, например, но с k8s стана много по-лесно :) – бележка на редактора. ]

Днес корекциите трябва да се правят почти в реално време, така че приложенията вече не трябва да бъдат черни кутии. Не, те трябва да показват крайни точки, които позволяват на системите за мониторинг да правят заявки и да събират ценни данни за състоянието на процесите, така че да могат да реагират незабавно, ако е необходимо. Това се нарича модел на дизайн на теста за производителност, който следва принципа на висока видимост (HOP).

Kubernetes предлага 2 вида проверки на здравето по подразбиране: readinessProbe и livenessProbe. И двете използват едни и същи видове проверки (HTTP GET заявки, TCP комуникации и изпълнение на команди). Те се различават по това какви решения вземат в отговор на проблеми в подс. livenessProbe рестартира контейнера с надеждата, че грешката няма да се повтори, а readinessProbe изолира групата от входящ трафик, докато причината за проблема не бъде разрешена.

Правилният дизайн на приложението трябва да включва и двата типа проверки и да гарантира, че те събират достатъчно данни, особено когато е хвърлено изключение. Той също така трябва да показва необходимите крайни точки на API, които предоставят на системата за мониторинг (Prometheus) важни показатели за здравето.

Източник: www.habr.com