И маленькое уточнение, а то может показаться, что я выше описал какой-то «правильный стек».

Terraform, Ansible, Flux и GitLab CI — не единственные варианты. Это вообще инструменты разных классов, и я бы сначала делил задачи, а уже потом выбирал, чем их решать.

Условно:

Provisioning инфраструктуры — Terraform, OpenTofu, Pulumi и т.д.
Их задача — получить VM, сеть, диски, балансировщики и прочие ресурсы.

Configuration management — Ansible, Salt, Puppet, Chef.
Тут уже ОС, пакеты, пользователи, файлы, systemd и всё, что находится внутри машины.

CI — GitLab CI, GitHub Actions, Jenkins и куча других вариантов.
Собрать, проверить, протестировать, упаковать изменение.

GitOps / CD для Kubernetes — Flux, Argo CD.
И вот это уже тот слой, который смотрит на состояние в Git и приводит кластер к нему.

То есть названия можно заменить почти в каждой строке. Я просто взял то, с чем хорошо знаком и работаю.

Причём Flux я сам использую в основном в пэтах и небольших контурах. В проде у меня Argo CD.

Не потому что Flux «хуже». Просто мне нет смысла тащить Argo туда, где Flux решает задачу несколькими CRD и почти не требует внимания. И наоборот — когда кластеров, приложений, команд, политик и зависимостей становится много, мне удобнее уже Argo.

Собственно, в этом и ещё одна мысль всего репозитория.

Не надо учить Terraform + Ansible + Flux + GitLab как связку.

Надо понять, какая проблема сейчас перед тобой, какой слой за неё отвечает и какой класс инструментов эту проблему решает.

А конкретный продукт выбирается уже после.

Иначе очень быстро получается Kubernetes ради Kubernetes, Argo ради Argo и двадцать операторов ради красивой схемы в README.