Pull to refresh
109
0
Андрей Климентьев @zuzzas

Solutions Engineer

Send message

Благодарю.

Ситуация была с native routing'ом. Хотел бы дать больше информации, но, к сожалению, не углублялись ещё в это.

Рассказывай о своём опыте с Pulumi.

У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и nodeSelector'ов, чтобы постепенно перекатить DS flannel в пользу DS cilium.

Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.

В корень зришь.

Функция dig в sprig есть для этого. Если в качестве дефолта поставить пустое значение, то можно в if использовать.


http://masterminds.github.io/sprig/dicts.html

Я issue создал в GitHub, сделаю. Там чуть подумать нужно будет, что в стандартной поставке будет.
github.com/flant/k8s-image-availability-exporter/issues/6
gecube не у нас работает, но мы его знаем и уважаем, потому что он всегда читает и критикует наши статьи.
Возможно, стоит перефразировать. Самый старый timestamp последней проверки.
Сейчас поправлю, спасибо!
Настройки CPU shares и oom_score_adj проставляет kubelet, если конкретно. Я попытался (как смог) более общую картину нарисовать.
У коллег спросил советов, на поверхность самый лучший вариант всплыл. Хранить в S3 или другом object storage, который у вашего хостера имеется! Сразу ото всех проблем избавитесь.
Облачный провайдер, у клиента непредсказуемая нагрузка в течение дня. Распродажа или livestream. Просто подключаем HPA и смотрим, как вся нагрузка аккуратно съедается.

В реальной жизни она везде не помешает. Вопрос лишь в том, как сделать системы автомасштабирования удобнее, более интегрированными в нашу работу.
Начнём с начала.
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.
Здесь нет ничего странного. В requests мы резервируем больше места для пода. А значит, он имеет большую приоритет на жизнь, чем остальные контейнеры/процессы на хосте.
На большинстве способов установки он уже был «внутри» кластера. Используя static manifests в kubelet'е master ноды. Это следующий логический шаг, чтобы отвязаться от необходимости трогать файловую систему.
А, я понял. Но в вашей ссылке патч, который ускоряет уменьшение slab'ов, а не решает вопрос подсчёта используемой памяти. В 4.16 подсчёт уже быстрее должен быть.
В следующий раз упомяните DWARF и LBR, пожалуйста. Далеко не каждый софт можно пересобрать в production.
1

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Date of birth
Registered
Activity