Привет!

По возможности продолжаю обзор статьи - https://www.gitpod.io/blog/we-are-leaving-kubernetes

Итак, мы узнали про разные подходы к управлением CPU, памятью и дисковым пространством.

Следующая часть статьи - про оптимизацию старта и автоскейл.

Быстрый старт окружений критично важен для такого сервиса как Gitpod, но это требование конфликтует с желанием максимально утилизировать ресурсы.

Первое что не сработало - это попытка запускать множество воркспейсов на одной ноде, рассчитывали что общие кэши (возможно это про опцию host IPC - https://www.fairwinds.com/blog/kubernetes-basics-tutorial-host-ipc-should-not-be-configured) ускорят старт. Но оказалось что в k8s все равно есть накладные расходы на перемещение контента в нужное место.

Далее провели ряд экспериментов:

Ghost workspaces - с помощью кастомного планировщика задач создавали поды - пустышки, которые занимали место для возможного автоскейла и замены на настоящие поды. Оказалось медленно и ненадежно.

Ballast pods - эволюция предыдущего подхода, поды - призраки заполняли ноду целиком, что ускорило и удешевило замену.

Затем в k8s появился плагин автоскейлер который позволил убрать костыли и отлично решает проблему - https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/

Для автоскейла при пиковых нагрузках разработали свою систему, которая управляет масштабированием в зависимости от частоты развертывания development окружений. Работает эта система с помощью старта так называемых pause images, что позволяет быстро по требованию подстроиться под нагрузки.

Pause image - это контейнер который хранит (занимает?) network namespace для пода, все прочие контейнеры созданные в поде будут использовать именно его, ссылки по теме:
- https://www.ianlewis.org/en/almighty-pause-container
- https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/