Два трека в одном бинарнике

Инструменты инфраструктуры обычно выбирают одну из двух стратегий. Либо простота: одна виртуальная машина, контейнеры, никакого Kubernetes. Либо серьёзность: кластер, оператор, декларативная сверка. Первое не растёт, второе избыточно для половины задач.

Мы поддерживаем оба, одним бинарником, и трек определяется файлом описания, а не флагом при запуске.

Простой трек

Виртуальная машина, Ubuntu, контейнеры через Docker Compose. Формат описания — YAML. Стиль работы императивный: инструмент читает закоммиченное состояние и выполняет команды напрямую.

Здесь нет непрерывного цикла сверки. ArgoCD не участвует. Нет состояния кластера в etcd и нет жизненного цикла ресурсов Cluster API.

Это честный режим для стенда, лаборатории, небольшого сервиса и всего, что не требует высокой доступности. Он не «упрощённая версия для ознакомления» — он полноценный способ работы, у которого другой предмет.

Производственный трек

Talos Linux, Cluster API, Sidero Metal, Helm. Формат описания — HCL. Стиль декларативный: Cluster API управляет жизненным циклом кластера, ArgoCD владеет всеми нагрузками, а инструмент выступает дирижёром, а не исполнителем.

Разница в слове «владеет». В производственном треке инструмент не ставит приложения в кластер сам. Он записывает желаемое состояние в репозиторий, а применяет его ArgoCD. Это означает, что состояние кластера сходится к репозиторию непрерывно, а не в момент запуска команды.

Высокая доступность здесь настраивается в том же описании: количество управляющих узлов и рабочих узлов задаётся параметрами конфигурации.

Почему трек определяется файлом

Потому что трек — свойство проекта, а не свойство запуска. Если бы он задавался флагом, то один и тот же проект в разных руках применялся бы по-разному, и это обнаружилось бы не сразу.

Файл описания лежит в репозитории и коммитится. Значит, трек — часть согласованного состояния, а не решение того, кто первым набрал команду.

Дистрибутив Kubernetes отделён от облака

Отдельное свойство производственного трека: выбор дистрибутива Kubernetes не связан с выбором машины и облака.

По умолчанию Talos — неизменяемая система, управляемая по API. Можно поднять и обычный upstream Kubernetes из штатных компонентов — сервер API, контроллер-менеджер, планировщик, kubelet, kube-proxy, плюс etcd и containerd. Можно взять любой из распространённых облегчённых дистрибутивов.

Локально или в любом облаке, одинаково. Это не абстракция ради абстракции: она нужна ровно затем, чтобы решение о дистрибутиве не было заодно решением о поставщике.

Что общего у треков

Требование git. Оба трека проходят одинаковые предварительные проверки: рабочее дерево, наличие конфигурации проекта, отсутствие файлов состояния в индексе.

И одинаковый принцип: если источника истины нет, команда падает громко со стабильным кодом ошибки, а не создаёт пустой результат.

Как выбирать

Простой вопрос: нужна ли непрерывная сверка. Если приложение можно обновить командой и этого достаточно — простой трек. Если нужно, чтобы система сама возвращалась к описанному состоянию после любого вмешательства — производственный.

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