☸️ Первое знакомство с Kubernetes: публикация приложения в интернет

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).