GitOps — это подход к управлению инфраструктурой и приложениями, при котором Git выступает единственным источником правды. Все изменения в кластере Kubernetes или в конфигурации описываются в репозитории, а деплой идёт через pull-модель: оператор сверяет желаемое состояние из Git с реальным и приводит систему в соответствие.
Основные принципы
- Декларативность — в Git хранится описание желаемого состояния (манифесты, Helm values), а не пошаговые скрипты.
- Версионирование и аудит — каждая смена окружения фиксируется коммитом: кто, когда и что изменил.
- Автоматизация — инструменты (Argo CD, Flux и др.) постоянно сверяют кластер с репозиторием и применяют изменения.
Зачем это нужно
Команды получают единый процесс для разработки и эксплуатации: один workflow через Git, откат через revert, ревью через merge request. Это уменьшает дрейф конфигурации и упрощает compliance. GitOps хорошо сочетается с CI/CD: pipeline собирает образ и обновляет манифесты в Git, а оператор уже разворачивает изменения в кластере.
GitOps и CI/CD
В классической схеме CI/CD pipeline не только собирает артефакты, но и сам пушит изменения в кластер (push-модель). В GitOps сборка и деплой разделены: CI собирает образ, обновляет тег в манифестах в Git и пушит коммит. Отдельный контроллер (Argo CD, Flux) в кластере забирает изменения из репозитория и применяет их. Так кластер не нуждается в доступе «наружу», все права можно ограничить чтением одного репо — это удобно с точки зрения безопасности и модели «least privilege».
Инструменты
На практике чаще всего используют Argo CD и Flux. Оба умеют подписываться на Git-репозиторий (ветку или каталог), сравнивать желаемое состояние с текущим в кластере и выполнять apply. Argo CD даёт веб-интерфейс и удобен для визуального контроля; Flux легче встраивается в pipeline и хорошо интегрируется с Helm и Kustomize. Выбор зависит от предпочтений команды и того, насколько глубоко вы хотите автоматизировать обновления.
Плюсы и ограничения
Плюсы GitOps очевидны: полная история изменений, откат одной командой (git revert), ревью конфигурации так же, как кода. Ограничения тоже есть: не всё удобно описывать в Git (секреты, часть внешних сервисов), нужна дисциплина — все изменения только через репо, без ручных правок в кластере. Для команд, которые уже держат инфраструктуру «в коде», GitOps становится естественным следующим шагом.
Итого: GitOps — это не один инструмент, а способ организации процесса. Git как единственный источник правды, декларативное описание и автоматическое приведение кластера к этому состоянию. В связке с CI/CD и современными контроллерами это даёт предсказуемый и прозрачный цикл доставки приложений в Kubernetes.