Как в Kubernetes масштабировать развертывание до нуля в режиме ожидания
Я запускаю довольно ресурсоемкую службу в кластере Kubernetes для поддержки операций CI. Требуется только одна реплика, но она использует много ресурсов (16 ЦП) и обычно требуется только в рабочее время (в будние дни, примерно с 8 до 18 часов). Мой кластер работает в облаке и настроен с автоматическим масштабированием экземпляра, поэтому, если эта служба масштабируется до нуля, этот экземпляр может быть остановлен.
Сервис - это сторонний код, который нельзя изменить (ну, непросто). Это довольно типичная HTTP-служба, за исключением того, что ее работа довольно интенсивна.
Какие существуют варианты автоматического масштабирования этого развертывания до нуля в режиме ожидания?
Я бы предпочел не настраивать график для увеличения / уменьшения в рабочее время, потому что иногда действия CI выполняются в нерабочее время. Я бы хотел, чтобы масштабирование было динамическим (например, масштабирование до нуля при бездействии более 30 минут или масштабирование до одного при поступлении входящего соединения).
5 ответов
В итоге я реализовал собственное решение: https://github.com/greenkeytech/zero-pod-autoscaler
По сравнению с Knative, это скорее "игрушечный" проект, довольно небольшой и не зависит от istio. Он хорошо работает для моего варианта использования, хотя я не рекомендую другим использовать его, не желая принять код как свой собственный.
На самом деле Kubernetes поддерживает масштабирование до нуля только с помощью вызова API, поскольку Horizontal Pod Autoscaler поддерживает масштабирование только до 1 реплики.
В любом случае есть несколько операторов, которые позволяют вам преодолеть это ограничение, перехватывая запросы, поступающие к вашим модулям, или проверяя некоторые показатели.
Вы можете взглянуть на Knative или Keda. Они позволяют вашему приложению быть бессерверным, и делают это по-разному.
Knative посредством Istio перехватывает запросы и, если есть активный модуль, обслуживающий их, перенаправляет входящий запрос на этот, в противном случае запускает масштабирование.
Напротив, Keda лучше всего подходит для архитектуры, управляемой событиями, поскольку она может проверять предопределенные метрики, такие как задержка, длина очереди или пользовательские метрики (например, полученные из Prometheus), и запускать масштабирование.
Обе опоры масштабируются до нуля в случае, если предопределенные условия выполняются в одинаково предопределенном окне.
Надеюсь, это помогло.
Этого можно добиться несколькими способами, возможно, наиболее "родным" способом является использование Knative с Istio. Kubernetes по умолчанию позволяет выполнять масштабирование до нуля, однако вам нужно что-то, что могло бы служить посредником для событий масштабирования на основе "входного события", что, по сути, поддерживает архитектуру, управляемую событиями.
Вы можете ознакомиться с официальными документами здесь: https://knative.dev/docs/serving/configuring-autoscaling/
Горизонтальный автомасштабирование модулей в настоящее время не позволяет устанавливать для поля minReplicas значение 0, поэтому автомасштабирование никогда не будет уменьшаться до нуля, даже если модули ничего не делают. Уменьшение количества модулей до нуля может значительно повысить эффективность использования вашего оборудования.
Когда вы запускаете службы, которые получают запросы только раз в несколько часов или даже дней, нет смысла запускать их постоянно, поглощая ресурсы, которые могут использоваться другими модулями.
Но вы по-прежнему хотите, чтобы эти службы были доступны сразу после поступления запроса от клиента.
Это известно как холостой ход и холостой ход. Это позволяет уменьшить до нуля модули, предоставляющие определенную услугу. Когда поступает новый запрос, он блокируется до тех пор, пока модуль не будет запущен, а затем запрос, наконец, переадресуется модулю.
Kubernetes в настоящее время еще не предоставляет эту функцию, но со временем она появится.
Согласно документации, он пока не поддерживает minReplicas=0. прочтите эту ветку: - https://github.com/kubernetes/kubernetes/issues/69687. и для правильной настройки HPA вы можете использовать эту формулу для настройки необходимого модуля: -
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
вы также можете настроить HPA на основе показателей Prometheus, перейдя по этой ссылке: -
https://itnext.io/horizontal-pod-autoscale-with-custom-metrics-8cb13e9d475