У меня довольно дорогая рабочая нагрузка, которую иногда приходится выполнять некоторым коллегам в будний день (не по какому-либо установленному графику). Я использую Google Cloud Kubernetes.
Он состоит из трех наборов состояний, каждый с одной репликой.
Я проинструктировал их, как «включить» и «выключить». Чтобы включить его, они масштабируют каждый набор состояний до 1 реплики. Чтобы отключить его, они масштабируют каждый набор состояний до 0 реплик.
Первоначально у меня был один пул узлов автомасштабирования с размером по умолчанию в три узла (каждый набор состояний потребляет почти весь объем ЦП и ОЗУ). Я заметил, что даже после масштабирования до 0 по крайней мере один (а иногда и два) узла останется через час или два. Я ожидал, что в конце концов все узлы умрут, но этого не произошло.
Я заметил, что у запущенных узлов все еще есть несколько модулей, только в другом пространстве имен. Остальные капсулы находятся в kube-system пространство имен, за исключением одного в custom-metrics пространство имен.
Тогда я подумал, хорошо - может быть, Kubernetes хочет запустить другие сервисы, даже если нет пользовательских рабочих нагрузок / модулей. Итак, я создал еще один пул узлов с одним очень маленьким, но адекватным узлом. Этот узел достаточно велик, чтобы запускать все, что сообщает Kubernetes, в этих не-default пространства имен.
После того, как новый пул узлов работал с одним узлом, я приступил к ручному изменению размера исходного пула узлов до 0. Это было нормально. Я надеялся на этом этапе, что у меня есть "системный" пул узлов для запуска kube-system и прочее, а также пул «пользовательских» узлов для запуска моих собственных вещей.
Поэтому для следующего теста я увеличил масштаб только одной реплики с набором состояний. В конце концов, узел подключился, и модуль с набором состояний был запущен / готов. Затем я снова уменьшил его до 0 и ждал ... и ждал ... и узел не исчезал.
Что нужно для того, чтобы пул узлов автомасштабирования фактически достиг 0 узлов? Ясно, что мне чего-то не хватает (или чего-то большего), но мне было трудно найти информацию о том, что необходимо, чтобы средство масштабирования узлов уменьшило размер пула узлов до 0.
Любой совет приветствуется.
Дополнительная информация
Когда я смотрю, что работает на узле в пуле узлов, я хочу перейти на 0, вот что я вижу
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
kube-system fluentd-gcp-v3.1.1-mfkxf 100m (0%) 1 (3%) 200Mi (0%) 500Mi (0%) 28m
kube-system kube-proxy-gke-tileperformance-pool-1-14d3671d-jl76 100m (0%) 0 (0%) 0 (0%) 0 (0%) 28m
kube-system prometheus-to-sd-htvnw 1m (0%) 3m (0%) 20Mi (0%) 20Mi (0%) 28m
Если я попытаюсь drain узел жалуется, что они управляются через DaemonSet, поэтому я мог бы заставить его, но, очевидно, я пытаюсь никоим образом не вмешиваться вручную.
Взломать
Чтобы автомасштабирование "работало" и уменьшилось до 0, я временно добавил nodeSelector ко всем kube-system развертывания, поэтому они назначаются в отдельный пул для kube-system прочее. Но ведь должен быть способ получше?
Автомасштабирование не уменьшит ваш пул узлов до 0.
Примечание: Если вы укажете минимум ноль узлов, пул простаивающих узлов можно полностью уменьшить. Однако для запуска системных модулей в кластере всегда должен быть доступен хотя бы один узел.
- Google Cloud: автоматическое масштабирование кластера движка Kubernetes
Однако автомасштабирование кластера не может полностью уменьшить до нуля весь кластер. Для запуска системных модулей в кластере всегда должен быть доступен хотя бы один узел. Итак, вам нужно сохранить хотя бы один узел. Но это не значит, что вам нужно оставить его дорого узел работает в режиме ожидания.
- Medium.com: масштабируйте кластер kubernetes почти до нуля с помощью gke autoscaler
Вы можете явно уменьшить свой пул узлов до ноль (0) с командой:
$ gcloud container clusters resize CLUSTER_NAME --node-pool NAME_OF_THE_POOL --num-nodes 0
Но знайте, что у такого подхода будет недостаток.
Представьте себе ситуацию, когда:
Autoscaler не сможет увеличить количество узлов из нуль. У него не будет возможности определить, требуются ли дополнительные ресурсы. Поды, которые работали в kube-system на этих узлах было важно определить, требуется ли еще один узел.
Есть статья с вариантом использования, похожим на ваш. Взгляни, пожалуйста: Medium.com: масштабируйте кластер kubernetes почти до нуля с помощью gke autoscaler
Другой способ сделать это - сметить расходы на отключение контейнеров. Ознакомьтесь с ресурсами ниже:
Возможные причины, которые могут помешать автоматическому масштабированию кластера удалить узел:
- Пакеты с ограниченным бюджетом PodDisruptionBudget.
- Модули Kube-system, которые:
- не запускаются на узле по умолчанию,
- нет бюджет на нарушение целостности капсулы set или их PDB слишком ограничены (начиная с CA 0.6).
- Модули, которые не поддерживаются объектом контроллера (поэтому они не создаются путем развертывания, набора реплик, задания, набора с отслеживанием состояния и т. Д.).
- Поды с локальным хранилищем.
- Поды, которые нельзя переместить в другое место из-за различных ограничений (нехватка ресурсов, несовпадающие селекторы узлов или сродство, соответствие анти-сродства и т. Д.)
- Поды, для которых заданы следующие аннотации:
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"Если модуль не имеет следующей аннотации (поддерживается в CA 1.0.3 или новее):
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
CA не удаляет недостаточно используемые узлы, если на них работают поды, которые не следует выселять
Другие возможные причины отказа от уменьшения:
- группа узлов уже имеет минимальный размер,
- произошла неудачная попытка удалить этот конкретный узел, и в этом случае Cluster Autoscaler будет ждать дополнительных 5 минут, прежде чем снова рассматривать его для удаления,
- Github.com: у меня есть пара узлов с низким коэффициентом использования, но они не уменьшены, почему