Действительно, для большинства стандартных задач дефолтных решений Kubernetes хватает, и нет необходимости строить звездолеты. Но в нашем случае важно понимать, что мы решаем специфические инфраструктурные задачи на больших масштабах.
Вот почему стандартный Kubelet GC и стратегии пиннинга нам не подходят:
Гарантия сохранности: Мы обеспечиваем гарантированное хранение предыдущих релизов. Нам нужна уверенность, что никакой встроенный GC на ноде не удалит нужный образ в самый неподходящий момент при скачке утилизации диска.
Эффективность и дефрагментация: Мы сфокусированы на максимальной утилизации железа. В нашем внутреннем облаке жесткий «пиннинг» (привязка) подов к нодам крайне не приветствуется. Наоборот, облако постоянно дефрагментируется: поды проактивно и реактивно перемещаются между хостами, а планировщик оптимизирует ресурсы в режиме реального времени. При таком подходе полагаться на локальный кэш конкретной ноды просто бессмысленно.
Если интересно погрузиться в детали того, как это устроено на уровне архитектуры больших систем, очень рекомендую почитать статьи ребят на Хабре:
jingvar
Стратеги роллинга и пин на нолы в кубере не вывозят? Старые образа кубер сразу не удаляет.
amich Автор
Действительно, для большинства стандартных задач дефолтных решений Kubernetes хватает, и нет необходимости строить звездолеты. Но в нашем случае важно понимать, что мы решаем специфические инфраструктурные задачи на больших масштабах.
Вот почему стандартный Kubelet GC и стратегии пиннинга нам не подходят:
Гарантия сохранности: Мы обеспечиваем гарантированное хранение предыдущих релизов. Нам нужна уверенность, что никакой встроенный GC на ноде не удалит нужный образ в самый неподходящий момент при скачке утилизации диска.
Эффективность и дефрагментация: Мы сфокусированы на максимальной утилизации железа. В нашем внутреннем облаке жесткий «пиннинг» (привязка) подов к нодам крайне не приветствуется. Наоборот, облако постоянно дефрагментируется: поды проактивно и реактивно перемещаются между хостами, а планировщик оптимизирует ресурсы в режиме реального времени. При таком подходе полагаться на локальный кэш конкретной ноды просто бессмысленно.
Если интересно погрузиться в детали того, как это устроено на уровне архитектуры больших систем, очень рекомендую почитать статьи ребят на Хабре:
https://habr.com/ru/companies/yandex/articles/564510/ Yandex Planner. Как планировать вычислительные мощности
https://habr.com/ru/companies/yandex/articles/761946/ Почему инфраструктура big tech обычно состоит из самописных решений
https://habr.com/ru/companies/yandex/articles/854506/ Как мы нарушили все гайдлайны Kubernetes, чтобы описывать инфраструктуру в разы быстрее