Может ли осушение узла временно увеличить масштаб развертывания в Kubernetes? - PullRequest
3 голосов
/ 03 августа 2020

Кубернеты когда-либо создают подов в результате осушения узла? Я не уверен, что мне не хватает этой функции, или я просто не нашел для нее подходящей документации.

Итак, вот проблема: у меня есть службы, которые хотят быть всегда -on, но обычно они хотят быть одним контейнером (по разным глупым причинам, связанным с тем, что они имеют большее состояние, чем должны быть). Однако можно временно запустить два контейнера во время развертывания или обслуживания. Таким образом, в ECS я бы сказал «желаемая емкость 1, максимальный процент 200%, минимальный процент здоровья 100%». Затем, если мне нужно заменить узел кластера, ECS автоматически масштабирует службу до , и, как только новая задача будет проходить проверки работоспособности, она остановит старую задачу, а затем узел сможет продолжить слив *. 1007 *

В кубернетах примитивы кажутся менее гибкими: я могу установить бюджет нарушения работы модуля, чтобы предотвратить выселение модуля. Но я не вижу способа временно масштабировать развертывание в результате истощения узла. Объект бюджета разрушения пода в кубернетах, будучи в основном независимым от развертывания или набора реплик, по-видимому, в основном действует как блокировщик опустошения узла, но не как способ быстро запустить масштабирование.

1 Ответ

3 голосов
/ 04 августа 2020

В Kubernetes при развертывании будут создаваться новые поды, только если current replicas меньше desired replicas. Другими словами, создание нового модуля запускается после нарушения работы.

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

Вероятно, вы ищете что-то вроде `горизонтального автомасштабирования подов. Однако это масштабируется только в зависимости от потребления ресурсов.

Я бы развернул по крайней мере 2 реплики и использовал pod disruption budget, поскольку ваша служба (приложение) является критически важным и должно работать круглосуточно 7 дней в неделю. 365. Это не только для обслуживания узлов, но и по многим другим причинам (добровольным и непроизвольным), модуль может выйти из строя / перенести.

...