Kubernetes позволяет автоматически масштабировать приложения (то есть Pod в развертывании или ReplicaSet) декларативным образом с использованием спецификации Horizontal Pod Autoscaler.

По умолчанию критерий для автоматического масштабирования — метрики использования CPU (метрики ресурсов), но можно интегрировать пользовательские метрики и метрики, предоставляемые извне.

Вместо горизонтального автомасштабирования подов, применяется Kubernetes Event Driven Autoscaling (KEDA) — оператор Kubernetes с открытым исходным кодом. Он изначально интегрируется с Horizontal Pod Autoscaler, чтобы обеспечить плавное автомасштабирование (в том числе до/от нуля) для управляемых событиями рабочих нагрузок. Код доступен на GitHub.

Краткий обзор работы системы

На схеме — краткое описание того, как все работает:

1. Приложение предоставляет метрики количества обращений к HTTP в формате Prometheus.






2. Prometheus настроен на сбор этих показателей.






3. Скейлер Prometheus в KEDA настроен на автоматическое масштабирование приложения на основе количества обращений к HTTP.

Теперь подробно расскажу о каждом элементе.

KEDA и Prometheus

Prometheus — набор инструментов для мониторинга и оповещения систем с открытым исходным кодом, часть Cloud Native Computing Foundation. Собирает метрики из разных источников и сохраняет в виде данных временных рядов. Для визуализации данных можно использовать Grafana или другие инструменты визуализации, работающие с API Kubernetes.

KEDA поддерживает концепцию скейлера — он действует как мост между KEDA и внешней системой. Реализация скейлера специфична для каждой целевой системы и извлекает из нее данные. Затем KEDA использует их для управления автоматическим масштабированием.

Скейлеры поддерживают нескольких источников данных, например, Kafka, Redis, Prometheus. То есть KEDA можно применять для автоматического масштабирования развертываний Kubernetes, используя в качестве критериев метрики Prometheus.

KEDA Prometheus ScaledObject

Скейлер действует как мост между KEDA и внешней системой, из которой нужно получать метрики. ScaledObject — настраиваемый ресурс, его необходимо развернуть для синхронизации развертывания с источником событий, в данном случае с Prometheus.

ScaledObject содержит информацию о масштабировании развертывания, метаданные об источнике события (например, секреты для подключения, имя очереди), интервал опроса, период восстановления и другие данные. Он приводит к соответствующему ресурсу автомасштабирования (определение HPA) для масштабирования развертывания.

Когда объект ScaledObject удаляется, соответствующее ему определение HPA очищается.

Вот определение ScaledObject для нашего примера, в нем используется скейлер Prometheus:

apiVersion: keda.k8s.io/v1alpha1

kind: ScaledObject

metadata:

 name: prometheus-scaledobject

 namespace: default

 labels:

  deploymentName: go-prom-app

spec:

 scaleTargetRef:

   deploymentName: go-prom-app

 pollingInterval: 15

 cooldownPeriod:  30

 minReplicaCount: 1

 maxReplicaCount: 10

 triggers:

 - type: prometheus

  metadata:

    serverAddress:

http://prometheus-service.default.svc.cluster.local:9090

    metricName: access_frequency

    threshold: '3'

    query: sum(rate(http_requests[2m]))

Учтите следующие моменты:

1. Он указывает на Deployment с именем go-prom-app.






2. Тип триггера — Prometheus. Адрес сервера Prometheus упоминается вместе с именем метрики, пороговым значением и запросом PromQL, который будет использоваться. Запрос PromQL — sum(rate(http_requests[2m])).






3. Согласно pollingInterval, KEDA запрашивает цель у Prometheus каждые пятнадцать секунд. Поддерживается минимум один под (minReplicaCount), а максимальное количество подов не превышает maxReplicaCount (в данном примере — десять).

Можно установить minReplicaCount равным нулю. В этом случае KEDA активирует развертывание с нуля до единицы, а затем предоставляет HPA для дальнейшего автоматического масштабирования. Возможен и обратный порядок, то есть масштабирование от единицы до нуля. В примере мы не выбрали ноль, поскольку это HTTP-сервис, а не система по запросу.

Магия внутри автомасштабирования

Пороговое значение используют в качестве триггера для масштабирования развертывания. В нашем примере запрос PromQL sum(rate (http_requests [2m])) возвращает агрегированное значение скорости HTTP-запросов (количество запросов в секунду), ее измеряют за последние две минуты.

Поскольку пороговое значение равно трем, значит, будет один под, пока значение sum(rate (http_requests [2m])) меньше трех. Если же значение возрастает, добавляется дополнительный под каждый раз, когда sum(rate (http_requests [2m])) увеличивается на три. Например, если значение от 12 до 14, то количество подов — четыре.

Теперь давайте попробуем настроить!

Установка KEDA

Вы можете развернуть KEDA несколькими способами, они перечислены в документации. Я использую монолитный YAML:

[root@kub-master-1 ~]# wget https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml
[root@kub-master-1 ~]# kubectl apply -f keda-2.1.0.yaml

ну или можно установить через helm

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda —namespace keda

я ставил через монолитный файл.
проверим что всё поднялось:

[root@kub-master-1 ~]# kubectl get all -n keda

NAME                                          READY   STATUS    RESTARTS   AGE

pod/keda-metrics-apiserver-57cbdb849f-w7rfg   1/1     Running   0          70m

pod/keda-operator-58cb545446-5rblj            1/1     Running   0          70m



NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE

service/keda-metrics-apiserver   ClusterIP   10.100.134.31   <none>        443/TCP,80/TCP   70m



NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/keda-metrics-apiserver   1/1     1            1           70m

deployment.apps/keda-operator            1/1     1            1           70m



NAME                                                DESIRED   CURRENT   READY   AGE

replicaset.apps/keda-metrics-apiserver-57cbdb849f   1         1         1       70m

replicaset.apps/keda-operator-58cb545446            1         1         1       70m

3. Пример работы

создаём namespace

kubectl create ns my-site

запускаем обычное приложение например apache:

[root@kub-master-1 ~]# cat my-site.yaml

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment-apache

  namespace: my-site

spec:

  replicas: 1

  selector:

    matchLabels:

      app: apache # по вот этому лейблу репликасет цепляет под

# тут описывается каким мокаром следует обновлять поды

  strategy:

    rollingUpdate:

      maxSurge: 1  # указывает на какое количество реплик можно увеличить

      maxUnavailable: 1 # указывает на какое количество реплик можно уменьшить

#т.е. в одно время при обновлении, будет увеличено на один (новый под) и уменьшено на один (старый под)

    type: RollingUpdate

## тут начинается описание контейнера

  template:

    metadata:

      labels:

        app: apache  # по вот этому лейблу репликасет цепляет под

    spec:

      containers:

        - image: httpd:2.4.43

          name: apache

          ports:

            - containerPort: 80

# тут начинаются проверки по доступности

          readinessProbe: # проверка готово ли приложение

            failureThreshold: 3 #указывает количество провалов при проверке

            httpGet:  # по сути дёргает курлом на 80 порт

              path: /

              port: 80

            periodSeconds: 10 #как часто должна проходить проверка (в секундах)

            successThreshold: 1 #сбрасывает счётчик неудач, т.е. при 3х проверках если 1 раз успешно прошло, то счётчик сбрасывается и всё ок

            timeoutSeconds: 1 #таймаут на выполнение пробы 1 секунда

          livenessProbe: #проверка на жизнь приложения, живо ли оно

            failureThreshold: 3

            httpGet:

              path: /

              port: 80

            periodSeconds: 10

            successThreshold: 1

            timeoutSeconds: 1

            initialDelaySeconds: 10 #означает что первую проверку надо сделать только после 10 секунд



# тут начинается описание лимитов для пода

          resources:

            requests: #количество ресурсов которые резервируются для pod на ноде

              cpu: 60m

              memory: 200Mi

            limits: #количество ресурсов которые pod может использовать(верхняя граница)

              cpu: 120m

              memory: 300Mi

[root@kub-master-1 ~]# cat my-site-service.yaml

---

apiVersion: v1

kind: Service

metadata:

  name: my-service-apache # имя сервиса

  namespace: my-site

spec:

  ports:

  - port: 80  # принимать на 80

    targetPort: 80 # отправлять на 80

  selector:

    app: apache  #отправлять на все поды с данным лейблом

  type: ClusterIP

[root@kub-master-1 ~]# cat my-site-ingress.yaml

---

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: my-ingress

  namespace: my-site

spec:

  rules:

  - host: test.ru  #тут указывается наш домен

    http:

      paths:  #список путей которые хотим обслуживать(он дефолтный и все запросы будут отпаврляться на бэкенд, т.е. на сервис my-service-apache)

      - backend:

          serviceName: my-service-apache  #тут указывается наш сервис 

          servicePort: 80 #порт на котором сервис слушает

#        path: /  все запросы на корень '/' будут уходить на наш сервис

применяем:

[root@kub-master-1 ~]# kubectl apply -f my-site.yaml -f my-site-service.yaml -f my-site-ingress.yaml

проверяем:

[root@kub-worker-1 ~]# curl test.ru
<html><body><h1>It works!</h1></body></html>

[root@kub-master-1 ~]# kubectl get all -n my-site

NAME                                        READY   STATUS    RESTARTS   AGE

pod/my-deployment-apache-859486bd8c-k6bql   1/1     Running   0          20m



NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE

service/my-service-apache   ClusterIP   10.100.255.190   <none>        80/TCP    20m



NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/my-deployment-apache   1/1     1            1           20m



NAME                                              DESIRED   CURRENT   READY   AGE

replicaset.apps/my-deployment-apache-859486bd8c   1         1         1       20m

будем автоскейлить — для примера по метрике nginx nginx_ingress_controller_requests

запрос в prometheus будет следующий:

sum(irate( nginx_ingress_controller_requests{namespace=»my-site»}[3m] )) by (ingress)*10

т.е. считаем общее количество запросов в неймспейс my-site за 3 минуты

создаём keda сущность:

[root@kub-master-1 ~]# cat hpa-keda.yaml

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

  name: prometheus-scaledobject

  namespace: my-site

spec:

  scaleTargetRef:

    name: my-deployment-apache

  minReplicaCount: 1   # Optional. Default: 0

  maxReplicaCount: 8 # Optional. Default: 100

  triggers:

  - type: prometheus

    metadata:

      serverAddress: http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090

      metricName: nginx_ingress_controller_requests

      threshold: '100'

      query: sum(irate(nginx_ingress_controller_requests{namespace="my-site"}[3m])) by (ingress)*10

тут мы указываем в каком namespace нам запускаться:
namespace: my-site

указываем цель, т.е. наш deployment:
name: my-deployment-apache

задаём минимальное и максимальное количество реплик
minReplicaCount: 1 # значение по умолчанию: 0
maxReplicaCount: 8 # значение по умолчанию: 100

есть ещё 2 стандартные переменные отвечающие за то когда поды будут подыматься и убиваться:
pollingInterval: 30 # Optional. Default: 30 seconds
cooldownPeriod: 300 # Optional. Default: 300 seconds

указываем адрес нашего prometheus

serverAddress: http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090
адрес идёт в виде сервис.неймспейс.svc.имя_кластера

указываем нашу метрику:
metricName: nginx_ingress_controller_requests

указываем пороговое значение при котором начнётся автоскейлинг:
threshold: ‘100’

и соответственно наш запрос в prometheus:
query:

всё можно применять:

[root@kub-master-1 ~]# kubectl apply -f hpa-keda.yaml

проверяем:

[root@kub-master-1 ~]# kubectl get horizontalpodautoscalers.autoscaling -n my-site

NAME                               REFERENCE                         TARGETS       MINPODS   MAXPODS   REPLICAS   AGE

keda-hpa-prometheus-scaledobject   Deployment/my-deployment-apache   0/100 (avg)   1         8         1          68m

[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-v59b8   1/1     Running   0          37m

а теперь накрутим запросов:

[root@kub-worker-1 ~]# for i in {1..5000}; do curl test.ru; done

проверяем:

[root@kub-master-1 ~]# kubectl get horizontalpodautoscalers.autoscaling -n my-site

NAME                               REFERENCE                         TARGETS            MINPODS   MAXPODS   REPLICAS   AGE

keda-hpa-prometheus-scaledobject   Deployment/my-deployment-apache   34858m/100 (avg)   1         8         7          71m

как видим количество запросов превысило наш лимит и стали создаваться новые поды:

[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-6885f   1/1     Running   0          49s

my-deployment-apache-859486bd8c-6mcq4   1/1     Running   0          64s

my-deployment-apache-859486bd8c-cdb6z   1/1     Running   0          64s

my-deployment-apache-859486bd8c-kpwb8   1/1     Running   0          64s

my-deployment-apache-859486bd8c-rmw8d   1/1     Running   0          49s

my-deployment-apache-859486bd8c-v59b8   1/1     Running   0          39m

my-deployment-apache-859486bd8c-xmv28   1/1     Running   0          49s

прекращаем запросы и спустя 5 минут, указанное в переменной cooldownPeriod ненужные поды будут убиты:

[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS        RESTARTS   AGE

my-deployment-apache-859486bd8c-6885f   0/1     Terminating   0          6m35s

my-deployment-apache-859486bd8c-6mcq4   1/1     Running       0          6m50s

my-deployment-apache-859486bd8c-cdb6z   0/1     Terminating   0          6m50s

my-deployment-apache-859486bd8c-kpwb8   0/1     Terminating   0          6m50s

my-deployment-apache-859486bd8c-rmw8d   0/1     Terminating   0          6m35s

my-deployment-apache-859486bd8c-v59b8   0/1     Terminating   0          44m

my-deployment-apache-859486bd8c-xmv28   0/1     Terminating   0          6m35s



[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-6mcq4   1/1     Running   0          7m48s

Источник: https://sidmid.ru/kubernetes-автоскейлинг-приложений-при-помощ/

Имеется приложение на Go, API-бекенд.

Периодически начинает возвращать 502 ошибку, хотя сам под работает и в статусе Running.

Что бы рассмотреть, как и почему Ingress и Service могут возвращать 502, и как работают readinessProbe и livenessProbe в Kubernetes Deployment – напишем простой веб-сервер на Go, в котором опишем два ендпоинта – один будет возвращать нормальный ответ, а во втором – выполнение программы будет прерываться.

Затем задеплоим его в AWS Elastic Kubernetes, создадим Kubernetes Ingress, который создаст AWS Application Load balancer, и потрестируем работу приложения.

Golang HTTP server

Пишем приложение на Go, которое потом упакуем в Docker-контейнер, и запустим в Kubernetes:

package main



import (

    "fmt"

    "log"

    "net/http"

)

  

func main() {

    

    http.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request){

        fmt.Fprintf(w, "pong")

    })

      

    http.HandleFunc("/err", func(w http.ResponseWriter, r *http.Request){

        panic("Error")

    })

      

    fmt.Printf("Starting server at port 8080n")

    if err := http.ListenAndServe(":8080", nil); err != nil {

        log.Fatal(err)

    }   

}

Тут мы запускаем http.ListenAndServe() на порту 8080, и определяем два роута:

• /ping – при обращении сюда всегда возвращаем 200






• /err – при обращении сюда прерываем выполнение функции с panic, что сэмулировать некорретный ответ приложения

Проверяем локально.

Запускаем:

go run http.go

Starting server at port 8080

Проверяем роут /ping:

curl -I localhost:8080/ping

HTTP/1.1 200 OK

И URI /err, который вызовет panic:

curl -I localhost:8080/err

curl: (52) Empty reply from server

Лог приложения:

go run http.go

Starting server at port 8080

2020/11/11 14:34:53 http: panic serving [::1]:43008: Error

goroutine 6 [running]:

...

Docker образ

Пишем Dockefile:

FROM golang:latest

WORKDIR /app

COPY . .

RUN go build -o main .

EXPOSE 8080

CMD ["./main"]

Собираем образ и пушим в Docker Hub:

docker build -t setevoy/go-http .

docker push setevoy/go-http

Kubernetes

Deployment

Описываем запуск пода с этим образом – создаём 1 под, Service для него, и Ingress, который создаст AWS Application Load Balancer.

Начнём с Deployment:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: go-http

  labels:

    app: go-http

spec:

  replicas: 1

  strategy:

    type: Recreate

  selector: 

    matchLabels:

      app: go-http

  template:

    metadata:

      labels:

        app: go-http

    spec:

      containers:

      - name: go-http

        image: setevoy/go-http

        ports:

        - containerPort: 8080

        imagePullPolicy: Always

        livenessProbe:

          httpGet:

            path: /ping

            port: 8080

          initialDelaySeconds: 1

          periodSeconds: 1

        readinessProbe:

          httpGet:

            path: /ping

            port: 8080

          initialDelaySeconds: 1

          periodSeconds: 1

      restartPolicy: Always

Тут создаём один под, который слушает порт 8080.

В strategy деплоймента указываем Recreate, что бы при тестах не оставались старые поды.

Для него описываем проверки – livenessProbe и readinessProbe, обе проверки ходят на URI /ping, где получают ответ 200.

Позже мы поменяем путь в проверках, и посмотрим, к чему это приведёт.

Service

Создаём Kubernetes Service, который откроет на WorkerNode порт для ALB, и будет роутить трафик к нашему поду на порт 8080 (см. Kubernetes: Service, балансировка нагрузки, kube-proxy и iptables):

---

apiVersion: v1

kind: Service

metadata:

  name: go-http-svc

spec:

  type: NodePort

  ports:

  - port: 80

    targetPort: 8080

    protocol: TCP

  selector:

    app: go-http

Ingress

Добавляем Ingress, который создаст AWS Application Load Balancer, который будет направлять трафик к go-http-svc Service:

--- 

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: go-http-ingress

  annotations:    

    kubernetes.io/ingress.class: alb

    alb.ingress.kubernetes.io/scheme: internet-facing

    alb.ingress.kubernetes.io/healthcheck-path: /ping

    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'

  labels:   

    app: go-http

spec:         

  rules:

  - http: 

      paths:

      - path: /*

        backend: 

          serviceName: go-http-svc

          servicePort: 80

Создаём ресурсы:

kubectl apply -f go-http.yaml

deployment.apps/go-http created

service/go-http-svc created

ingress.extensions/go-http-ingress created

Проверяем под:

kubectl get pod -l app=go-http

NAME                      READY   STATUS    RESTARTS   AGE

go-http-8dc5b4779-7q4kw   1/1     Running   0          8s

И его Ingress:

kubectl get ingress -l app=go-http

NAME              HOSTS   ADDRESS                                                                 PORTS   AGE

go-http-ingress   *       e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com   80      31s

Ждём, пока наш DNS увидит новый URL e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com, и проверяем работу приложения – выполняем запрос к /ping:

curl -I e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/ping

HTTP/1.1 200 OK

Kubernetes Ingress 502

А теперь – обращаемся к ендпоинту /err, который в Go-приложении вызовет panic, и ловим 502 ошибку:

curl -vI e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/err

...

< HTTP/1.1 502 Bad Gateway

HTTP/1.1 502 Bad Gateway

< Server: awselb/2.0

Server: awselb/2.0

Логи пода:

kubectl logs go-http-8dc5b4779-7q4kw

Starting server at port 8080

2020/11/11 12:57:10 http: panic serving 10.3.39.145:8926: Error

goroutine 5169 [running]:

net/http.(*conn).serve.func1(0xc000260e60)

/usr/local/go/src/net/http/server.go:1801 +0x147

panic(0x654840, 0x6f0ba0)

/usr/local/go/src/runtime/panic.go:975 +0x47a

main.main.func2(0x6fa0a0, 0xc00012c540, 0xc000127700)

/app/http.go:16 +0x39

net/http.HandlerFunc.ServeHTTP(0x6bab98, 0x6fa0a0, 0xc00012c540, 0xc000127700)

/usr/local/go/src/net/http/server.go:2042 +0x44

net/http.(*ServeMux).ServeHTTP(0x8615e0, 0x6fa0a0, 0xc00012c540, 0xc000127700)

/usr/local/go/src/net/http/server.go:2417 +0x1ad

net/http.serverHandler.ServeHTTP(0xc0000ea000, 0x6fa0a0, 0xc00012c540, 0xc000127700)

/usr/local/go/src/net/http/server.go:2843 +0xa3

net/http.(*conn).serve(0xc000260e60, 0x6fa4e0, 0xc00011b8c0)

/usr/local/go/src/net/http/server.go:1925 +0x8ad

created by net/http.(*Server).Serve

/usr/local/go/src/net/http/server.go:2969 +0x36c

Тут всё логично – load-balancer отправил наш запрос к поду, под не ответил (вспомним curl: (52) Empty reply from server в наших первых тестах), и мы получили ответ 502 от балансировщика aka Ingress.

readinessProbe и livenessProbe

Теперь посмотрим, как изменение в readinessProbe и livenessProbe повлияют на ответы Ingress и работу самого пода.

readinessProbe

Документация – тут>>>.

readinessProbe используется для проверки того, готов ли под принимать трафик.

Сейчас наш под в статусе Ready:

kubectl get pod -l app=go-http

NAME                      READY   STATUS    RESTARTS   AGE

go-http-8dc5b4779-7q4kw   1/1     Running   0          28m

Или так:

kubectl get pod -l app=go-http -o json | jq '.items[].status.containerStatuses[].ready'

true

И запрос к /ping возвращает нам ответ 200:

curl -I e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/ping

HTTP/1.1 200 OK

Меняем readinessProbe – задаём path=/err, что бы проверка постоянно фейлилась:

...

        readinessProbe:

          httpGet:

            path: /err

...

Передеплоиваем:

kubectl apply -f go-http.yaml

deployment.apps/go-http configured

И проверяем:

kubectl get pod -l app=go-http

NAME                      READY   STATUS    RESTARTS   AGE

go-http-5bd557544-2djcw   0/1     Running   0          4s

Если мы теперь отправим запрос даже на ендпоинт /ping – всё-равно получим 502, т.к. бекенд Сервиса, т.е. под, не принимает трафик, потому что не прошёл readinessProbe:

kubectl get pod -l app=go-http -o json | jq '.items[].status.containerStatuses[].ready'

false

Пробуем:

curl -I e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/ping

HTTP/1.1 502 Bad Gateway

livenessProbe

Документация – тут>>>.

Вернём readinessProbe в /ping, что бы трафик на под пошёл, но изменим livenessProbe – зададим path в /err, а initialDelaySeconds и periodSeconds установим в 15 секунд, плюс добавим failureThreshold равным одной попытке:

...

        livenessProbe:

          httpGet:

            path: /err

            port: 8080

          initialDelaySeconds: 15

          periodSeconds: 15

          failureThreshold: 1

        readinessProbe:

          httpGet:

            path: /ping

...

Теперь после запуска пода Kubernetes выждет 15 секунд, затем выполнит livenessProbe и будет повторять её каждые следующие 15 секунд.

Передеплоиваем, и проверяем:

kubectl get pod -l app=go-http

NAME                       READY   STATUS    RESTARTS   AGE

go-http-78f6c66c8b-q6fkf   1/1     Running   0          6s

Проверяем запрос к ендпоинту /ping:

curl -I e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/ping

HTTP/1.1 200 OK

Всё хорошо.

И /err нам ожидаемо вернёт 502:

curl -I e172ad3e-default-gohttping-ec00-691779486.us-east-2.elb.amazonaws.com/err

HTTP/1.1 502 Bad Gateway

Через 15 секунд, после выполнения первой live проверки – под будет перезапущен:

kubectl get pod -l app=go-http

NAME                       READY   STATUS    RESTARTS   AGE

go-http-668c674dcb-4db9x   0/1     Running   1          19s

Events этого пода:

kubectl describe pod -l app=go-http

...

Normal   Created    6s (x4 over 81s)  kubelet, ip-10-3-55-229.us-east-2.compute.internal  Created container go-http                                                                                                                         

 Warning  Unhealthy  6s (x3 over 66s)  kubelet, ip-10-3-55-229.us-east-2.compute.internal  Liveness probe failed: Get http://10.3.53.103:8080/err: EOF                                                                                       

 Normal   Killing    6s (x3 over 66s)  kubelet, ip-10-3-55-229.us-east-2.compute.internal  Container go-http failed liveness probe, will be restarted                                                                                        

Normal   Started    5s (x4 over 81s)  kubelet, ip-10-3-55-229.us-east-2.compute.internal  Started container go-http

Контейнер в поде не прошёл проверку livenessProbe, и Kubernetes перезапускает под в попытке “починить” его.

Если получится попасть на сам момент перезапуска контейнера – увидим стаус CrashLoopBackOff, а запрос к /ping снова вернёт нам 502:

kubectl get pod -l app=go-http

NAME                       READY   STATUS             RESTARTS   AGE

go-http-668c674dcb-4db9x   0/1     CrashLoopBackOff   4          2m21s

Выводы

Используем readinessProbe для проверки того, что приложение запустилось, в данном случае – Go-бинарник начал прослушивать порт 8080, и на него можно направлять трафик, и используем livenessProbe во время работы пода для проверки того, что приложение в нём все ещё живо.

Если приложение начинает отдавать 502 на определённые запросы – то следует поискать проблему именно в запросах, т.к. если бы была проблема в настройках Ingress/Service – получали бы 502 постоянно.

Самое важное – понимать принципиальную разницу между readinessProbe и livenessProbe:

• если фейлится readinessProbe – процесс aka контейнер в поде останется в том же состоянии, в котором был на момент сфейленой ready-проверки, но под будет отключен от трафика к нему






• если фейлится livenessProbe – трафик на под продолжает идти, но контейнер будет перезапущен

Итак, имеем ввиду, что:

• Если readinessProbe не задана вообще – kubelet будет считать, что под готов к работе, и направит к нему трафик сразу после старта пода. При этом если на  запуск пода уходит минута – то клиенты, которые к нему были направлены после его запуска, будут ждать эту минуту, пока он ответит.






• Если приложение ловит ошибку, которую не может обработать – оно должно завершить свой процесс, и Kubernetes сам перезапустит контейнер.






• Используем livenessProbe для проверки состояний, которые нельзя обработать в самом приложении, например – deadlock или бесконечный цикл, при которых контейнер не может ответить на ready-проверку. В таком случае если нет livenessProbe, которая может перезапустить процесс, то под будет отключен от Service – но останется в статусе Running, продолжая потреблять реурсы WorkerNode.

Источник: https://rtfm.co.ua/ru/kubernetes-ingress-oshibka-502-readinessprobe-i-livenessprobe/

Имеется PHP-приложение, работает в Kubernetes в подах с двумя контейнерами – NGINX и PHP-FPM.

Проблема: во время скейлинга приложения начинают проскакивать 502 ошибки. Т.е. при остановке подов – некорректно отрабатывает завершение подключений.

Рассмотрим процесс остановки подов вообще, и особенности NGINX и PHP-FPM в частности.

Тестировать будем приложение в AWS Elastic Kubernetes Service с помощью Yandex.Tank.

Ingress создаёт AWS Application Load Balancer с помощью AWS ALB Ingress Controller.

Для управления контейнерами на Kubernetes WorkerNodes испольузется Docker.

Pod Lifecycle – Termination of Pods

Посмотрим, как вообще происходит процесс остановки и удаления подов.

Итак, под – это процесс(ы), запущенные на WorkerNode, для остановки которых используются стандартные сигналы IPC (Inter Process Communication).

Что бы дать возможность поду (процессу/ам) закончить все его текущие операции – система управления контейнерами (container runtime) пытается мягко завершить его работу (graceful shutdown), отправляя сигнал SIGTERM процессу с PID 1 в каждом контейнере этого пода (см. docker stop). При этом, кластер запускает отсчёт grace period перед тем, как жёстко убить под отправкой сигнала SIGKILL.

При этом, можно переопределить сигнал для мягкой остановки используя STOPSIGNAL в образе, из которого запускался контейнер.

Итак, процесс удаления пода выглядит следующим образом:

1. мы выполняем kubectl delete pod или kubectl scale deployment – запускается процесс удаления подов и стартует таймер отсчёта grace period с дефолтным значением в 30 секунд






2. API-сервер обновляет статус пода – из Running он становится Terminating (см. Container states). На WorkerNode, на которой этот под запущен, kubelet получает обновление статус этого пода и начинает процесс его остановки:

   1. если для контейнера(ов) в поде есть preStop hook – kubelet  его выполняет. Если хук продолжает выполнение после истечения grace period – добавляется ещё 2 секунды на его завершение. При необходимости можно изменить дефолтные 30 секунд используя terminationGracePeriodSeconds

   
   
   
   

   2. после завершения preStop хука – kubelet отправляет указание Docker на остановку контейнеров, и Docker отправляет сигнал SIGTERM процессу с PID 1 в каждом контейнере. При этом контейнеры в поде получают сигнал в случайном порядке.






3. одновременно с началом процесса graceful shutdown – Kubernetes Control Plane (его kube-controller-manager) удаляет останавливаемый под из списка ендпоинтов (см. Kubernetes – Endpoints), и соответствующий Service перестаёт отправлять новые подключения на останавливаемый под






4. по завершению grace period, kubelet триггерит force shutdown – Docker отправляет сигнал SIGKILL всем оставшимся процесам во всех контейнерах пода, который они проигнорировать не могут, и мгновенно умирают, аварийно завершая все свои операции






5. kubelet триггерит удаление объекта пода из API-сервера






6. API-сервер удаляет запись о поде из базы, и под становится недоступен

Наглядная табличка:

Собственно, тут возникает две проблемы:

1. сам NGINX и PHP-FPM воспринимают SIGTERM как “жестокое убийство”, и завершают работу немедленно, не заботясь о корректном завершении текущих подключений (см. Controlling nginx и php-fpm(8) – Linux man page)






2. шаги 2 и 3 – отправка SIGTERM и удаление ендпоинта – выполняются одновременно. Однако, обновление данных в Ingress Service происходит не моментально, и под может начать умирать раньше, чем Ingress перестанет на него слать трафик, соотвественно – получим 502, т.к. процесс в поде уже не может принимать подключения

Т.е. в первом случае, если у нас есть подключение к NGINX с keep-alive – то NGINX при выполнении fast shutdown просто обрубит его, а клиент получит 502 ошибку, см. Avoiding dropped connections in nginx containers with “STOPSIGNAL SIGQUIT”.

NGINX STOPSIGNAL и 502

Попробуем воспроизвести проблему с NGINX.

Возмём пример из поста по ссылке выше, и задеплоим его в Кубер.

Пишем Dockerfile:

FROM nginx

RUN echo 'server {n

    listen 80 default_server;n

    location / {n

      proxy_pass      http://httpbin.org/delay/10;n

    }n

}' > /etc/nginx/conf.d/default.conf

CMD ["nginx", "-g", "daemon off;"]

Тут NGINX выполняет proxy_pass на http://httpbin.org, который отвечает с задержкой в 10 секунд – эмулируем работу PHP-бекенда.

Собираем, пушим в репозиторий:

docker build -t setevoy/nginx-sigterm .

docker push setevoy/nginx-sigterm

• Re-play






• Copy to Clipboard






• Pause






• Full View

Пишем Deployment с 10 подами из собранного образа.

Тут приведу полный файл, с Namespace, Service и Ingress, далее только те части, которые будут меняться:

---

apiVersion: v1

kind: Namespace

metadata:

  name: test-namespace

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: test-deployment

  namespace: test-namespace

  labels:

    app: test

spec:

  replicas: 10

  selector:

    matchLabels:

      app: test

  template:

    metadata:

      labels:

        app: test

    spec:

      containers:

      - name: web

        image: setevoy/nginx-sigterm

        ports:

        - containerPort: 80

        resources:

          requests:

            cpu: 100m

            memory: 100Mi

        readinessProbe:

          tcpSocket:

            port: 80

---

apiVersion: v1

kind: Service

metadata:

  name: test-svc

  namespace: test-namespace

spec:

  type: NodePort

  selector:

    app: test

  ports:

    - protocol: TCP

      port: 80

      targetPort: 80

---

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: test-ingress

  namespace: test-namespace

  annotations:

    kubernetes.io/ingress.class: alb

    alb.ingress.kubernetes.io/scheme: internet-facing

    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'

spec:

  rules:

  - http:

      paths:

      - backend:

          serviceName: test-svc

          servicePort: 80

Деплоим:

kubectl apply -f test-deployment.yaml

namespace/test-namespace created

deployment.apps/test-deployment created

service/test-svc created

ingress.extensions/test-ingress created

Проверяем Ingress:

curl -I aadca942-testnamespace-tes-5874-698012771.us-east-2.elb.amazonaws.com

HTTP/1.1 200 OK

Запущено 10 подов:

kubectl -n test-namespace get pod

NAME                              READY   STATUS    RESTARTS   AGE

test-deployment-ccb7ff8b6-2d6gn   1/1     Running   0          26s

test-deployment-ccb7ff8b6-4scxc   1/1     Running   0          35s

test-deployment-ccb7ff8b6-8b2cj   1/1     Running   0          35s

test-deployment-ccb7ff8b6-bvzgz   1/1     Running   0          35s

test-deployment-ccb7ff8b6-db6jj   1/1     Running   0          35s

test-deployment-ccb7ff8b6-h9zsm   1/1     Running   0          20s

test-deployment-ccb7ff8b6-n5rhz   1/1     Running   0          23s

test-deployment-ccb7ff8b6-smpjd   1/1     Running   0          23s

test-deployment-ccb7ff8b6-x5dc2   1/1     Running   0          35s

test-deployment-ccb7ff8b6-zlqxs   1/1     Running   0          25s

Готовим load.yaml для Yandex.Tank:

phantom:

  address: aadca942-testnamespace-tes-5874-698012771.us-east-2.elb.amazonaws.com

  header_http: "1.1"

  headers:

     - "[Host: aadca942-testnamespace-tes-5874-698012771.us-east-2.elb.amazonaws.com]"

  uris:

    - /    

  load_profile:

    load_type: rps

    schedule: const(100,30m)

  ssl: false

console:

  enabled: true

telegraf:

  enabled: false

  package: yandextank.plugins.Telegraf

  config: monitoring.xml

Тут выполняем 1 запрос в секунду к подам за нашим Ingress (и NGINX в каждом будет ждать 10 секунд ответа от своего “бекенда” перед тем, как ответить 200 нашему Танку).

Запускаем тесты:

Пока всё хорошо.

Теперь скейлим поды с 10 до 1:

kubectl -n test-namespace scale deploy test-deployment --replicas=1

deployment.apps/test-deployment scaled

Поды перешли в Terminating:

kubectl -n test-namespace get pod

NAME                              READY   STATUS        RESTARTS   AGE

test-deployment-647ddf455-67gv8   1/1     Terminating   0          4m15s

test-deployment-647ddf455-6wmcq   1/1     Terminating   0          4m15s

test-deployment-647ddf455-cjvj6   1/1     Terminating   0          4m15s

test-deployment-647ddf455-dh7pc   1/1     Terminating   0          4m15s

test-deployment-647ddf455-dvh7g   1/1     Terminating   0          4m15s

test-deployment-647ddf455-gpwc6   1/1     Terminating   0          4m15s

test-deployment-647ddf455-nbgkn   1/1     Terminating   0          4m15s

test-deployment-647ddf455-tm27p   1/1     Running       0          26m

...

И ловим наши 502 ошибки:

Теперь в Dockerfile добавляем STOPSIGNAL SIGQUIT:

FROM nginx

RUN echo 'server {n

    listen 80 default_server;n

    location / {n

      proxy_pass      http://httpbin.org/delay/10;n

    }n

}' > /etc/nginx/conf.d/default.conf

STOPSIGNAL SIGQUIT

CMD ["nginx", "-g", "daemon off;"]

Билдим, пушим:

docker build -t setevoy/nginx-sigquit .

docker push setevoy/nginx-sigquit

Обновляем деплоймент:

...

    spec:

      containers:

      - name: web

        image: setevoy/nginx-sigquit

        ports:

        - containerPort: 80

...

Передеплоиваем, и проверяем ещё раз.

Запускаем тесты:

Скейлим деплоймент:

kubectl -n test-namespace scale deploy test-deployment --replicas=1

deployment.apps/test-deployment scaled

А ошибок по-прежнему нет:

Прекрасно.

Трафик, preStop и sleep

И всё-таки, если повторить тесты несколько раз, то иногда 502 ошибки всё-таки проскакивают:

Тут мы уже сталкиваемся со второй проблемой – обновление ендпоинтов выполняется параллельно с отправкой SIGTERM.

Добавим preStop хук со sleep, что бы дать время на обновление ендпоинтов – тогда после получения команды на удаление пода, kubelet выждет 5 секунд перед отправкой SIGTERM, за которые Ingress успеет обновить список ендпоинтов:

...

    spec:

      containers:

      - name: web

        image: setevoy/nginx-sigquit

        ports:

        - containerPort: 80

        lifecycle:

          preStop:

            exec:

              command: ["/bin/sleep","5"]

...

Повторяем тесты – всё хорошо.

Выкатили фикс в Production – всё работает замечательно, ошибки пропали, автотесты теперь работают без проблем.

С PHP-FPM проблемы, как оказалось, не было вообще,  т.к. исходный образ изначально был со STOPSIGNAL SIGQUIT.

Другие варианты решения

Конечно, по ходу поиска решения были переброваны самые разные варианты. См. ссылки на интересные материалы в конце, а тут опишу их кратко.

preStop и nginx -s quit

Одним из вариантов было добавить в preStop хук отправку сигнала QUIT в NGINX:

lifecycle:

  preStop:

    exec:

      command:

      - /usr/sbin/nginx

      - -s

      - quit

Но не помогло. Не очень понятно почему, потому как идея вроде бы правильная – вместо того, что бы ожидать TERM от Kubernetes/Docker – мы сами мягко стопаем NGINX, отправляя ему QUIT.

Но можно попробовать.

NGINX + PHP-FPM, supervisord и stopsignal

Наше приложение работает в двух отдельных контейнерах NGINX и PHP-FPM.

Но в процессе поиска решения пробовал использовать образ, в котором оба сервиса собраны в одном образе, например trafex/alpine-nginx-php7.

В нём пробовал добавлять параметр stopsignal и для NGINX, и для PHP-FPM со значением QUIT – но тоже не помогло, хотя идея тоже вроде правильная.

Тем не менее – как вариант на попытку.

PHP-FPM и process_control_timeout

В посте Graceful shutdown in Kubernetes is not always trivial и на Stackoveflow в вопросе Nginx / PHP FPM graceful stop (SIGQUIT): not so graceful есть упоминание о том, что мастер-процесс FPM убивается не дожидаясь своих дочерних процессов, что также может приводить к 502.

Не наш случай, но стоит обратить внимание на параметр process_control_timeout.

NGINX, HTTP и keep-alive session

В принципе, можно было бы указать приложению отправлять заголовок [Connection: close] – тогда клиент по завершении передачи данных закрывал бы соединение, и это уменьшило бы вероятность 502-х. Но они всё равно будут, если NGINX получит SIGTERM в процессе обработки запроса от клиента, а т.к. у нас “сзади” ещё PHP, который ходит в базу – то некоторые запросы могут обрабатываться по 5-10 и более секунд.

См. HTTP persistent connection.

Источник: https://rtfm.co.ua/ru/kubernetes-nginx-php-fpm-graceful-shutdown-izbavlyaemsya-ot-502-oshibok/