У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и nodeSelector'ов, чтобы постепенно перекатить DS flannel в пользу DS cilium.
Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.
У коллег спросил советов, на поверхность самый лучший вариант всплыл. Хранить в S3 или другом object storage, который у вашего хостера имеется! Сразу ото всех проблем избавитесь.
Облачный провайдер, у клиента непредсказуемая нагрузка в течение дня. Распродажа или livestream. Просто подключаем HPA и смотрим, как вся нагрузка аккуратно съедается.
В реальной жизни она везде не помешает. Вопрос лишь в том, как сделать системы автомасштабирования удобнее, более интегрированными в нашу работу.
Начнём с начала.
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.
Здесь нет ничего странного. В requests мы резервируем больше места для пода. А значит, он имеет большую приоритет на жизнь, чем остальные контейнеры/процессы на хосте.
На большинстве способов установки он уже был «внутри» кластера. Используя static manifests в kubelet'е master ноды. Это следующий логический шаг, чтобы отвязаться от необходимости трогать файловую систему.
А, я понял. Но в вашей ссылке патч, который ускоряет уменьшение slab'ов, а не решает вопрос подсчёта используемой памяти. В 4.16 подсчёт уже быстрее должен быть.
Благодарю.
Ситуация была с native routing'ом. Хотел бы дать больше информации, но, к сожалению, не углублялись ещё в это.
Рассказывай о своём опыте с Pulumi.
У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и nodeSelector'ов, чтобы постепенно перекатить DS flannel в пользу DS cilium.
В корень зришь.
Функция dig в sprig есть для этого. Если в качестве дефолта поставить пустое значение, то можно в if использовать.
http://masterminds.github.io/sprig/dicts.html
git cloneПоправил, спасибо.
github.com/flant/k8s-image-availability-exporter/issues/6
Сейчас поправлю, спасибо!
Minio!
В реальной жизни она везде не помешает. Вопрос лишь в том, как сделать системы автомасштабирования удобнее, более интегрированными в нашу работу.
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.
en.wiktionary.org/wiki/werf#Dutch