Хочешь уверенно проходить IT-интервью?
Мы понимаем, как сложно подготовиться: стресс, алгоритмы, вопросы, от которых голова идёт кругом. Но с AI тренажёром всё гораздо проще.
💡 Почему Т1 тренажёр — это мастхэв?
- Получишь настоящую обратную связь: где затык, что подтянуть и как стать лучше
- Научишься не только решать задачи, но и объяснять своё решение так, чтобы интервьюер сказал: "Вау!".
- Освоишь все этапы собеседования, от вопросов по алгоритмам до диалога о твоих целях.
Зачем листать миллион туториалов? Просто зайди в Т1 тренажёр, потренируйся и уверенно удиви интервьюеров. Мы не обещаем лёгкой прогулки, но обещаем, что будешь готов!
Реклама. ООО «Смарт Гико», ИНН 7743264341. Erid 2VtzqwP8vqy
Health check probe
Проверки работоспособности дают кластеру k8s понять, когда с нашим приложением что-то не так и нам нужно зафиксировать это в логах или перезапустить под. Есть два типа проверок: Liveness и Readiness.
Liveness
В этом случае мы определяем работоспособность контейнера. Узнать его состояние можно несколькими способами – это httpGet (запрос HTTP к приложению), tcpSocket (k8s попробует создать соединение на указанный порт вашего приложения) и gRPC (grpc-health-probe). Рассмотрим первые два варианта.
Для приложения с HTTP-сервером определение работоспособности через httpGet выглядит примерно так:
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
Делается HTTP-запрос к указанным URI и порту (в нашем случае это / на порте 8080). В случае успешного ответа вида 2xx, k8s считает приложение работоспособным. Другой ответ или отсутствие такового говорит о том, что контейнер отключен и его нужно перезапустить.
Разберем параметры:
- initialDelaySeconds отвечает за задержку в секундах перед началом проверки. Нет такого приложения, которое стартует мгновенно.
- periodSeconds отвечает за периодичность запуска проверки для защиты от перегрузки. В нашем случае проверка проводится каждые 3 секунды.
Если приложение не умеет обрабатывать HTTP-запросы, можно использовать проверку через tcpSoket:
livenessProbe:
tcpSocket:
port: 8080
Если TCP-соединение будет успешным, k8s считает приложение работоспособным.
Readiness
С технической точки зрения эта проверка похожа на предыдущую. Разница в том, что если мы не проходим Liveness, то под с нашим приложением уходит в перезагрузку, а в случае с провалом Readiness он блокируется на Service. На приложение в этом случае не будет направляться трафик.
Описать проверку Readiness можно так:
readinessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
Внимательный читатель увидит, что разница только в одной строчке.
Ingress
От проверок переходим к объекту Ingress, который организует сетевое взаимодействие с подами (как Service), но прокидывает трафик на доменное имя и позволяет добраться до приложения из Internet. Еще одна его функция – балансировка трафика, при этом в настройках можно указать правила маршрутизации на определенные Service.
Ingress сверху мапится с доменным именем, а снизу – с Service, который обслуживает трафик для подов нашего приложения.
Описать YAML можно так:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress-nginx
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: test.com
http:
paths:
- backend:
serviceName: app
servicePort: 8080
Основные моменты:
- host – ваше доменное имя.
- serviceName – Name Service, который обслуживает приложение.
- servicePort – порт для сетевого взаимодействия.
В статьях цикла мы сделали следующее:
- Развернули учебный кластер k8s на VPS
- Разобрались с основными особенностями системы оркестрации Kubernetes
- Изучили основные объекты Kubernetes (Pod, Deployment, Service, Ingress)
- Разработали приложение на Python и развернули его в кластере
После публикации приложение в Internet с помощью Ingress архитектурная схема нашего кластера выглядит так:
Забрать файлы YAML можно по ссылке. В следующей статье мы разберемся с Helm (package manager for Kubernetes).
Комментарии