Share This
Связаться со мной
Крути в низ
Categories
//Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

prodolzhaja znakomitsja s kubernetes razberemsja s proverkoj rabotosposobnosti prilozhenij health check probe i rassmotrim obekt ingress kotoryj dc1b384 - Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

Мы уже знаем что оркестратор Kubernetes управляет подами. Кластеру нет разницы, доступно ли приложение внутри пода. Под запустился, и с точки зрения k8s все в порядке. Бывают ситуации, когда под запускается и со стороны k8s все работает, а со стороны пользователя приложение недоступно. Для решения таких проблем существуют проверки работоспособности (Health check probe).

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. На приложение в этом случае не будет направляться трафик.

Практический кейс Приложение нормально запустилось и прошло проверку Liveness, но затупило по соединению с БД. На фронтенде пользователи могут видеть устаревшую информацию.

Описать проверку Readiness можно так:

         readinessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 3 periodSeconds: 3       

Внимательный читатель увидит, что разница только в одной строчке.

Проверки необходимы для своевременной сигнализации о проблемах и оперативного устранения поломок. Они добавляют стабильности развернутым в кластере Kubernetes приложениям.

Ingress

От проверок переходим к объекту Ingress, который организует сетевое взаимодействие с подами (как Service), но прокидывает трафик на доменное имя и позволяет добраться до приложения из Internet. Еще одна его функция – балансировка трафика, при этом в настройках можно указать правила маршрутизации на определенные Service.

Возможности настройки правил огромные – это материал не на одну статью. Мы коснемся Ingress только для публикации приложения из кластера k8s в Internet.

prodolzhaja znakomitsja s kubernetes razberemsja s proverkoj rabotosposobnosti prilozhenij health check probe i rassmotrim obekt ingress kotoryj 517ca40 - Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

Схема работы Ingress.

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 – порт для сетевого взаимодействия.

Важный нюанс В настройке записей DNS своего домене указывайте IP-адрес ноды кластера, на которой установлен Ingress. Этот IP должен быть виден из Internet.

В статьях цикла мы сделали следующее:

  • Развернули учебный кластер k8s на VPS
  • Разобрались с основными особенностями системы оркестрации Kubernetes
  • Изучили основные объекты Kubernetes (Pod, Deployment, Service, Ingress)
  • Разработали приложение на Python и развернули его в кластере

После публикации приложение в Internet с помощью Ingress архитектурная схема нашего кластера выглядит так:

prodolzhaja znakomitsja s kubernetes razberemsja s proverkoj rabotosposobnosti prilozhenij health check probe i rassmotrim obekt ingress kotoryj 67334d8 - Продолжая знакомиться с Kubernetes, разберемся с проверкой работоспособности приложений (Health check probe) и рассмотрим объект Ingress, который позволит сделать приложения кластера доступными из интернета.

Забрать файлы YAML можно по ссылке. В следующей статье мы разберемся с Helm (package manager for Kubernetes).

  • 1 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Свежие комментарии

    Рубрики

    About Author 01.

    blank
    Roman Spiridonov

    Моя специальность - Back-end Developer, Software Engineer Python. Мне 39 лет, я работаю в области информационных технологий более 5 лет. Опыт программирования на Python более 3 лет. На Django более 2 лет.

    Categories 05.

    © Speccy 2022 / All rights reserved

    Связаться со мной
    Close