У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и 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 подсчёт уже быстрее должен быть.
Тернистый путь к eBPF, или Как мы Cilium в Deckhouse внедряли
Благодарю.
Ситуация была с native routing'ом. Хотел бы дать больше информации, но, к сожалению, не углублялись ещё в это.
Обзор фреймворка cdk8s для «программирования» Kubernetes-манифестов
Рассказывай о своём опыте с Pulumi.
Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием
У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и nodeSelector'ов, чтобы постепенно перекатить DS flannel в пользу DS cilium.
Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием
В корень зришь.
Продвинутая Helm-шаблонизация: выжимаем максимум
Функция dig в sprig есть для этого. Если в качестве дефолта поставить пустое значение, то можно в if использовать.
http://masterminds.github.io/sprig/dicts.html
Представляем k8s-image-availability-exporter для обнаружения пропавших образов в Kubernetes
git clone
Поправил, спасибо.
Представляем k8s-image-availability-exporter для обнаружения пропавших образов в Kubernetes
github.com/flant/k8s-image-availability-exporter/issues/6
Представляем k8s-image-availability-exporter для обнаружения пропавших образов в Kubernetes
Представляем k8s-image-availability-exporter для обнаружения пропавших образов в Kubernetes
Сейчас поправлю, спасибо!
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
Minio!
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
В реальной жизни она везде не помешает. Вопрос лишь в том, как сделать системы автомасштабирования удобнее, более интегрированными в нашу работу.
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
Kubernetes 1.14: обзор основных новшеств
6 занимательных системных багов при эксплуатации Kubernetes [и их решение]
6 занимательных системных багов при эксплуатации Kubernetes [и их решение]
Perf и flamegraphs
Как победить дракона: переписываем вашу программу на Golang
en.wiktionary.org/wiki/werf#Dutch