Настройка ArgoCD и GitOps в Kubernetes: практическое руководство

ArgoCD без GitOps: почему состояние кластера расходится с репозиторием

Чаще всего ArgoCD попадает в кластер как удобная панель состояния: видно, что развёрнуто, видно расхождения, но изменения по-прежнему вносят руками. Во время разбора инцидента кто-то поднимает число реплик, расширяет лимиты или подменяет образ прямо в кластере — «временно, чтобы быстрее». Патч остаётся в живом состоянии, а в репозитории о нём никто не помнит.

Так начинается дрейф конфигурации: фактическое состояние перестаёт совпадать с описанным в репозитории. Пока синхронизация не запускается, рассинхрон незаметен — приложение работает, метрики в норме. Но стоит включить автосинхронизацию, как кластер вернётся к версии из репозитория и вместе с ней потеряется обходное изменение, на котором держится работа сервиса.

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

Цена — незапланированный простой в самый неудачный момент: во время выката, отката или ночного перезапуска узла. ArgoCD без замкнутого цикла GitOps остаётся зеркалом, а не механизмом управления. Разбираем, как это закрывается.

Что даёт управляемая доставка: скорость, откат и предсказуемость

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

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

История изменений перестаёт быть устной. У каждой правки есть автор, причина и связь с задачей, а откат оставляет такой же явный след. Отсюда вырастает предсказуемость релизов: команда заранее знает, что именно и в какой момент окажется в кластере, и может показать это на любой момент времени.

Отдельно стоит назвать устранённый класс отказов — «на стенде работало, в рабочем контуре конфигурация другая». Правка кластера в обход репозитория становится видимой аномалией, а не скрытой нормой, и её замечают до того, как она дойдёт до пользователей. ArgoCD в такой схеме только исполняет зафиксированное в репозитории — поэтому состояние окружения воспроизводимо, а не восстанавливается по памяти. Именно эти показатели мы снимаем на приёмке: время отката, долю успешных выкаток и число ручных операций на релиз.

Режимы доставки изменений: синхронизация из репозитория и альтернативы

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

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

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

Как идёт внедрение: от разбора кластера до передачи регламентов

Внедрение GitOps — это не установка ArgoCD в кластер, а перестройка того, как изменения попадают в прод. Порядок этапов важнее скорости: без инвентаризации и продуманной схемы репозиториев синхронизация начнёт расходиться с реальным состоянием уже через неделю.

1. Инвентаризация кластера. Собираем рабочие нагрузки, пространства имён, привязки ролей и ручные правки через kubectl. Фиксируем расхождения между манифестами и живым состоянием — это и есть реальный объём работ.
2. Схема репозиториев. Разделяем конфигурацию приложений и окружений, задаём структуру каталогов и границы ответственности команд. От неё зависит, сколько ручных согласований останется при каждой выкатке.
3. Настройка синхронизации. Подключаем ArgoCD, описываем Application и AppProject, включаем автосинхронизацию и восстановление состояния после ручных правок. Секреты уходят в Git только в зашифрованном виде.
4. Проверка политик. Ограничиваем проектами доступные пространства имён и типы ресурсов, включаем валидацию манифестов на ревью. Ошибка конфигурации отлавливается до попадания в кластер.
5. Тестовая выкатка. Прогоняем релиз на стенде, затем на некритичном сервисе в проде: смотрим время синхронизации и поведение при откате. Откат проверяем возвратом коммита, а не ручными командами.
6. Передача в сопровождение. Отдаём регламенты, описываем роли и доступы, показываем дежурному, как читать статус синхронизации и что делать при зависшем релизе.

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

Что передаём на руки: манифесты, роли, регламенты и схемы

Передаём не набор чартов, а работающий контур: Argo CD уже настроен, репозитории связаны, дежурный инженер может воспроизвести окружение, откатить релиз и увидеть, кто и что менял. Ниже — что именно остаётся у команды заказчика вместе с исходниками и доступом к хранилищу конфигураций.

• Манифесты и конфигурации — описания приложений и наборов приложений с политикой синхронизации: автосинхронизация, восстановление после ручных правок в кластере, удаление ресурсов, которых больше нет в Git. Единый источник правды — репозиторий, а не живой кластер.
• Ролевая модель и политики доступа — проекты с ограничением по репозиториям, пространствам имён и типам ресурсов; связка с единым входом и группами, отдельное право на синхронизацию в продуктив.
• Схема окружений — карта разработки, предпродакшна и прода: какие ветви и оверлеи им соответствуют, в каком порядке идёт выкладка и где конфигурации расходятся осознанно.
• Регламент релиза — пошаговый порядок: ревью изменения, слияние, синхронизация, проверка здоровья сервисов, решение об откате и фиксация результата.
• Работа с секретами — где хранятся учётные данные, чем расшифровываются внутри кластера, у кого есть доступ и как проходит ротация ключей.
• Инструкции для дежурных — что смотреть при расхождении состояния, как отличить сбой выкладки от сбоя приложения, типовые действия и порядок эскалации.
• Схемы и документация — диаграмма потока изменений от коммита до кластера, карта репозиториев и чек-лист подключения нового сервиса.

Каждый артефакт мы разбираем с вашей командой на передаче — чтобы через месяц никто не искал, где зашита логика выкладки.

Кейс: ArgoCD снял ручные деплои в кластере из 40 сервисов

До внедрения GitOps кластер на 40 сервисов жил на ручных выкатках: инженер собирал образ, правил манифесты прямо в кластере и применял их через командную строку. Состояние среды никто не мог воспроизвести — описания расходились с тем, что реально работало, а правки «на минуту» оседали в кластере навсегда.

Перенесли все описания в Git и отдали синхронизацию Argo CD: репозиторий стал единственным источником правды, а расхождение между ним и кластером — видимым и устранимым. Включили автоматическую синхронизацию и самовосстановление: если ресурс меняют вручную или под падает, контроллер возвращает заявленное состояние без участия человека.

Метрики до и после

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

Чем отличается ArgoCD от самописного конвейера доставки?

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

Отсюда разница в наблюдаемости и откате. В декларативной модели видно, какие ресурсы отклонились от репозитория, в каком окружении зависла синхронизация и какой коммит ей предшествовал; откат изменений — возврат к предыдущему состоянию, а не повторный прогон. В скриптах откат часто получается частичным: часть шагов уже применилась, часть нет.

Ответственность за фактическое состояние тоже разная. В декларативной модели эталон — репозиторий: если ресурс поправили напрямую, дрейф проявится и будет устранён. В самописном конвейере фактическое состояние не описывает никто — оно складывается из побочных эффектов запусков.

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

Вопросы по доступам, средам и уже работающим кластерам

Перед стартом мы разбираем с командой заказчика пять вопросов — они определяют, станет внедрение управляемым контуром или ещё одним слоем, который инженеры начнут обходить. Ниже — техническая суть ответов, без общих слов.

Как изолировать контуры разработки, тестирования и продуктивный?

Разделяем экземплярами или проектами с ограничением по пространствам имён. Продуктивный контур отличается обязательным ручным подтверждением синхронизации и запретом на автоприменение из общей ветки.

Подключится ли уже работающий кластер?

Да, без простоя. Сначала сервис берётся в режим наблюдения: состояние читается, расхождения с манифестами фиксируются, но ничего не применяется. Когда описания совпали с фактом — включаем автоприменение, по одному сервису за раз.

Что с планом отката?

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

Что входит в сопровождение после внедрения?

Дежурство по инцидентам, обновление контроллера и правил доступа, подключение новых сервисов, ревизия расхождений между описанием и фактом. Отдельно — разбор, какие сервисы остались вне контура и почему.

Обсудим задачу: разберём ваш кластер и вернёмся с планом

Предметная оценка внедрения ArgoCD строится на фактах о вашем кластере, а не на общих словах. Чем точнее вводные, тем меньше допущений останется в плане и тем быстрее начнётся работа.

• Схема контуров: сколько кластеров и окружений, где они размещены, связаны ли сетью и общим реестром образов.
• Текущий способ выкатки: ручные команды, задачи в сборочной линии, чарты или отдельные манифесты — и что именно делается руками перед релизом.
• Структура репозиториев: где лежат описания ресурсов, есть ли отдельные ветки под окружения, кто имеет право вливать изменения.
• Ограничения по доступам: можно ли выдать учётную запись только на чтение, есть ли закрытый контур без внешней сети, свои центры сертификатов.
• Требования к откату и окна релизов: как быстро нужно возвращать предыдущую версию, есть ли периоды, когда выкатка запрещена.
• Что уже пробовали: пилот ArgoCD, самописные скрипты, ограничения, на которых всё остановилось.

Взамен присылаем не общие соображения, а рабочий комплект:

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

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