- У нас мультизональный кластер (три зоны), в котором пять нод
Мультизональный кластер - это кластер который размещен в облаке и разных геогр.зонах. Это сделано для того чтобы допустим при поломке EU кластера, люди всё равно получали доступ к приложению, но уже к Asia. Или чтобы люди подкючались к ближайшему кластеру(увелич.скорость) Для этого мы размещаем наше веб приложение в 3ех зонах. Для этого юзаем affinity. Как я понял эта штука пришла на смену nodeSelector и в данном случаем мы устанавливаем anti afinity чтобы разнести поды по зонам доступности, указанным в метках узлов
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: webapp
operator: In
values:
- nginx
topologyKey: failure-domain.beta.kubernetes.io/zone
- Приложение требует около 5-10 секунд для инициализации
Для реализации этого условия нам помогут пробы,им нужно установить 5 сек initialDelaySeconds. readinessProbe - проверяет готов ли контейнер принимать запросы, трафик и т.д. livenessProbe - живой ли контейнер, если умер - делаем рестарт. Примерный код:
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 10 # инициализация 10 сек или можно задать 5
periodSeconds: 20 # каждые 20 сек
livenessProbe:
httpGet:
path: /healthz #отправляем сюда запрос, чекаем живой ли он
port: 8080
initialDelaySeconds: 10 # ждем 10 сек после старта
periodSeconds: 20 # каждые 20 сек
- По результатам нагрузочного теста известно, что 4 пода справляются с пиковой нагрузкой
Укажим при создании Deployment'a (В HPA) что хотим видеть max 4 реплики днем и 1 ночью.
spec:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 4
- На первые запросы приложению требуется значительно больше ресурсов CPU, в дальнейшем потребление ровное в районе 0.1 CPU. По памяти всегда “ровно” в районе 128M memory
0.1CPU это 100m (миликоры), куб умный он сам посчитает, мы лишь укажем желаемое число, request - это минимальные мощности которые мы выделяем, а limits - это сколько мы максимум можем дать этому приложению(Ставим 128Mi т.к. это константа, 200 миликоров нуу пусть будет в два раза больше на всякий случай ¯_(ツ)_/¯ )
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 128Mi
- Приложение имеет дневной цикл по нагрузке – ночью запросов на порядки меньше, пик – днём
Используем горизонтальное автоматическое масштабирование (HPA). Он будет днем давать 4 реплики, а ночью 1. Для определения времени суток будем юзать CronJob. Настроим CronJob, чтобы запускать задачу каждый день с 8 утра до 22 вечера. В задаче мы запускаем контейнер с нашим приложением, указываем ресурсы CPU и задаем политику перезапуска на случай ошибок. Далее настраиваем HPA. Мы указываем, что масштабирование будет происходить при использовании CPU более, чем на 50%. Минимальное количество реплик установлено на 1, а максимальное - на 4. Таким образом, в период пиковых нагрузок, HPA автоматически увеличит количество реплик подов до 4, чтобы обеспечить достаточную производительность приложения. В ночное время, когда нагрузка на приложение снижается, количество реплик будет автоматически уменьшено до 1.
- Хотим максимально отказоустойчивый deployment
Для этого мы делали разделение на зоны (availability zones)
- Хотим минимального потребления ресурсов от этого deployment’а
Для этого использовали горизонтальное автоматическое масштабирование (HPA)