k8s = loop(ansible)

Тейк: система оркестрации (условный кубернетес) это ансибл, запускающийся в цикле (условно по крону). Уточню, что такое ансибл, для дальнейшего повествования это некая программа, которая берет некие (yaml) манифесты и идемпотентными действиями делает их более реальными.

Рассмотрим по компонентам, что должно и не должно быть в оркестраторе.

  • Secret management, Configuration management

Секреты могут быть внешней по отношению к оркестратору вещью, если для нагрузки нужно брать секреты, пусть она их берет откуда нужно как нужно, нам(оркестратору) за этим следить не нужно. Конфигурация так же может быть как внешней, так и храниться прямо в манифестах, в зависимости от того, хотим ли мы менять ее на лету или только при обновлениях инфры, например деплое новой версии.

Examples: Vault, Consul, любое другое key-value хранилище вплоть до Redis.

  • Automated scheduling

То есть выяснять, на какую ноду закинуть новый под. Кажется, что состояния кластера достаточно, чтобы это посчитать, поэтому так же может быть внешней системой. Тогда оркестратор будет работать так: - взять манифест - если нужно, обратиться к шедулеру, или просто захардкоженому шедулингу(ансибл инвентори) - использовать полученый шедулинг при выполнении плейбука

При походе в шедулер достаточно передать ему состояние кластера, плюс шедулер сам может хранить или запрашивать из апи оркестратора дополнительные данные.

  • Service discovery, Load balancing

Выглядит тоже, как внешняя вещь. Сервис дискавери через сервис меш работал и работает через запросы у оркестратора где находятся ворклоады, ничего не мешает им работать так же и дальше. Лоад балансер это тот же самый ворклоад, который еще и затребовал внешние порты.

Examples: Consul, Nginx, Caddy, wireguard vpn, etc.

  • Self-healing applications

Состояние сервиса можно проверять во время выполнения плейбука, чтобы понять, нужно ли сервис перезапускать. Является частным случаем части плейбука.

  • Auto scaling, Rollout, Rollback

Оркестратор нам в итоге должен предоставлять как минимум две вещи: - запустить ворклоад - удалить ворклоад

Что такое автоскейлер: посмотреть на метрики или что-то другое и запустить еще ворклоадов, либо убрать лишние. Это вполне может делать внешняя программа, оркестратору этим можно не заниматься.

Rollout: выкатить новый деплой, ну это базовая возможность оркестратора.

Rollback: удалить новый деплой и выкатить старый. Комбинация базовых возможностей оркестратора с разными параметрами.

  • Storage orchestration

Тут не уверен, звучит как ресурсы, привязанные к нодам, которые влияют только на шедулинг. На самом деле я не девопс и не знаю даже как StatefulSet работает в кубере. В воображении картинка такая: у ноды указываются волюмы с размером и положением на диске, которые с ноды можно брать. И ворклоады, пользующиеся этими волюмами, шедулятся на эти ноды. Тогда это решается лейблами в шедулере, а не в оркестраторе.

  • Custom controller

Если хотим контролировать не деплои, а что то еще. Например джобы (одноразовые таски) или кронджобы (периодически повторяющиеся джобы) или что-то другое. Звучит как еще один плейбук для ансибла, который это все и запускает/настраивает. По своей природе, плейбуки в ансибле это идемпотентные операции над некоторыми сущностями, будь то выкатывания деплоев или запуски джоб.