Кластер расходится с Git: где ломается auto-sync kubernetes
Синхронизация кластера с Git редко отказывает целиком — обычно она включена, но с исключениями. Кто-то поправил лимиты у пода через kubectl «на пять минут», кто-то добавил аннотацию руками, пока разбирался с инцидентом. Пока auto-sync kubernetes настроен по принципу «применить и забыть», такие правки спокойно живут в кластере до следующего релиза и не попадают ни в один коммит.
Через несколько недель рассинхронизация кластера перестаёт быть набором мелочей. Ручные правки в кластере накапливаются, Git описывает одну среду, а работает другая, и разница нигде не зафиксирована. Дрейф конфигураций бьёт в самом неудачном сценарии: окружение пересоздают с нуля из репозитория, и приложение поднимается не так, как в продуктивной среде, — потому что часть рабочего состояния жила только в живом кластере.
Ломается это в предсказуемых местах. Автоматическое переприменение (self-heal) выключено, поэтому расхождение просто копится. Удаление объектов, пропавших из репозитория, не включено — мусорные ресурсы остаются в кластере. Список исключений для сравнения состояний разросся до того, что инструмент перестаёт замечать реальные изменения. Плюс у инженеров остаётся прямой доступ на запись, а значит, обход Git снова возможен в любой момент.
Воспроизводимость окружений держится ровно на одном условии: единственный источник правды — репозиторий, а всё остальное от него не отклоняется незаметно. Разбираем, как это закрывается в ArgoCD и Flux, и что нужно проверить до включения автоматического применения.
Что даёт автоматическая синхронизация состояния кластера
Главный эффект — состояние кластера перестаёт быть результатом ручных действий. Манифесты, политики и параметры окружений лежат в репозитории как единственный источник истины, а контроллер сверяет фактическое состояние с описанным и приводит расхождения к нужному виду. Автоматическая синхронизация в Kubernetes убирает прослойку «инженер вспомнил и поправил»: изменение попадает в кластер только после того, как прошло ревью и зафиксировано коммитом.
Отсюда первый измеримый эффект — время восстановления. Раньше потеря узла, сбой обновления или разрушенное окружение означали ручной разбор: вспомнить, что и когда настраивалось, найти актуальные конфигурации, повторить шаги в правильном порядке. Теперь восстановление сводится к раскатке из репозитория, и счёт идёт на минуты вместо часов. Тот же механизм закрывает целый класс отказов из-за незадокументированных правок — тех, что внесли напрямую в кластер и никто не помнит.
Контроллер находит такой дрейф при очередной сверке и либо возвращает объект к описанному состоянию, либо помечает его как расхождение, которое видно в интерфейсе.
Откат релиза становится предсказуемым. Выпуск откатывается не набором ручных команд под давлением, а обратным коммитом: возвращается предыдущее описанное состояние, и контроллер сам приводит кластер к нему, включая удаление лишних объектов. Мы настраиваем это заранее и проверяем на учебном окружении, а не в момент инцидента.
Наконец, контроль изменений перестаёт держаться на дисциплине. История коммитов показывает, кто, что и зачем поменял, любая правка привязана к ревью, а расхождение между репозиторием и кластером видно как метрика, а не как сюрприз при следующем релизе.
Сравнение режимов синхронизации кластера с репозиторием
Режим синхронизации определяет, кто и когда применяет изменения из репозитория к кластеру. У ArgoCD и Flux набор режимов одинаковый: авто-применение по коммиту, авто-применение с самовосстановлением, подтверждение перед выкаткой и запуск по расписанию. Разница только в том, что происходит с ручной правкой в кластере и с ошибочным коммитом.
Обычно режим закрепляют за окружением: ветка разработки — на контур разработки с полной автоматикой, ветка релизов — на предпродуктивный, тег или отдельная ветка — на продуктив с подтверждением. Это уживается в одном кластере, потому что режим задаётся на уровне приложения, а не всего кластера целиком.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Автосинхронизация с самовосстановлением | контуры разработки и тестирования, где дрейф недопустим | ручная правка откатывается за минуты, ошибочный коммит уезжает сразу |
| Автосинхронизация без самовосстановления | окружения, где инженеры правят ресурсы напрямую | расхождение копится молча, видно только в отчёте |
| Синхронизация с подтверждением перед выкаткой | продуктив и регулируемые контуры | применение зависит от дежурного: слияние есть, выкатки нет |
| Запуск по расписанию или по событию в репозитории | редкие контуры, ночные окна, тяжёлые миграции | задержка между коммитом и применением — минуты и часы |
| Наблюдение без синхронизации | аудит, инвентаризация, приёмка чужого кластера | изменений в кластер не вносит, обратной записи нет |
Ограничения здесь важнее возможностей: автоматика ускоряет выкатку только тогда, когда до слияния в репозиторий проходят проверки конфигурации.
Этапы внедрения: аудит, схема, настройка, проверка, передача
Работу ведём этапами: от инвентаризации текущего состояния до передачи в сопровождение. Автоматическая синхронизация Kubernetes — это смена модели работы с кластером, а не переключатель, поэтому каждый шаг опирается на артефакты предыдущего.
- Аудит кластера. Собираем инвентарь объектов, отдельно отмечаем созданное руками и управляемое вне репозитория. Эти расхождения становятся первыми кандидатами на приведение к описанному состоянию.
- Схема синхронизации. Определяем границы: какие контуры управляются из Git, какие остаются ручными, где нужны отдельные ветки под окружения. Согласуем модель доступа и порядок применения изменений.
- Подготовка репозитория. Раскладываем манифесты по каталогам, выносим параметры окружений, подключаем проверки на этапе коммита — так ошибка ловится до попадания в кластер.
- Настройка контроллера. Разворачиваем ArgoCD или Flux в режиме наблюдения: автоматическое применение выключено, видно только фактическое расхождение с репозиторием.
- Проверка на стенде. Прогоняем сценарии: правка манифеста, откат, недоступный репозиторий, ручное изменение прямо в кластере. Смотрим, за какое время состояние сходится и как ведёт себя контроллер под нагрузкой.
- Перевод в автоматический режим. Сначала некритичные контуры, затем остальные. Удаление объектов, которых нет в репозитории, включаем последним — когда инвентарь сошёлся с фактом.
- Передача в сопровождение. Отдаём схему, регламент изменений и набор проверок, обучаем команду — дальше изменения идут обычным коммитом.
Конфигурации, схемы и регламенты на выходе проекта
Проект закрывается не презентацией, а набором артефактов, которые применяются без нашего участия. Ниже — то, что остаётся у заказчика после настройки автоматической синхронизации кластера с Git: рабочая конфигурация, схема связей, права и регламенты, по которым команда сопровождения работает самостоятельно.
- Рабочие конфигурации. Манифесты кластеров и приложений в Git, разложенные по окружениям; различия между ними вынесены в отдельные файлы значений, а не скопированы в несколько веток.
- Схема синхронизации. Какой репозиторий связан с каким кластером, какие политики применяются при расхождении — удаление лишних объектов, автоматическое приведение к состоянию из Git, — и где заканчивается зона ручных изменений.
- Матрица ролей доступа. Кто правит манифесты, кто подтверждает слияние, у кого есть права на секреты, а у кого — доступ к кластеру только на чтение.
- Регламент отката. Пошаговый порядок возврата к предыдущему состоянию: отмена коммита, синхронизация, проверка результата — с указанием, сколько времени занимает операция.
- Порядок работы с секретами. Где они хранятся, как ротируются, что делать при компрометации; правки прямо в кластере исключены как класс.
- Документация по сопровождению. Что делать при расхождении, при недоступности контроллера синхронизации, как подключить новое окружение или новый кластер.
- Сигналы и оповещения. Какие метрики состояния синхронизации собираются, при каких значениях приходит уведомление дежурному и кто его разбирает.
Приёмка идёт по этому же списку: разворачиваем окружение с нуля строго по документации, намеренно вносим ручное изменение и расхождение, после чего проверяем, укладывается ли откат в заявленный регламент.
Кейс: восстановление кластера за минуты вместо часов
Кластер на три среды — разработка, предрелиз, продуктив — держался на ручных правках: инженеры подключались напрямую и меняли объекты по месту. Часть настроек вообще не доезжала до репозитория, часть расходилась с ним. Восстановление после неудачного обновления или отказа узла занимало 4–6 часов: разворачивали из резервной копии, затем вручную догоняли всё, что успело измениться после её снятия, и сверяли среды между собой по памяти участников.
Что изменили
Описания объектов перенесли в Git как единственный источник истины, а сверку и подтягивание состояния поручили Argo CD: он сравнивает кластер с репозиторием по расписанию и сам возвращает любое отклонение назад. Права на запись в кластер выдали только контроллеру синхронизации, людям остались чтение и разбор инцидентов. Изменения теперь проходят через запрос на слияние — с ревью, историей и откатом одной ревизией.
Метрики до и после
- Время восстановления продуктивной среды: 4–6 часов → 12–20 минут, причём без участия дежурного инженера.
- Доля изменений, прошедших мимо репозитория: около трети → менее 2%, и это только аварийные разовые правки.
- Расхождения конфигурации между средами: несколько инцидентов в месяц → ни одного за квартал.
Ушёл целый класс отказов — «поправили на проде и забыли перенести»: при расхождении с репозиторием кластер возвращается к описанному состоянию сам, а не копится в виде уникальной снежинки, которую страшно трогать.
Кластер уже настроен, но auto-sync kubernetes сбоит: что делать
Конфликт синхронизации почти всегда означает не сбой контроллера, а два источника истины в одном кластере. Часть объектов правится руками — через панель управления, локальный kubectl или скрипты релиза, — а часть приходит из репозитория. При включённом самовосстановлении контроллер молча возвращает свою версию, и ручная правка исчезает; без него приложение висит в расхождении, и auto-sync kubernetes не проходит.
Для уже развёрнутого кластера первый шаг — инвентаризация владения: по метаданным последнего применённого конфига и аннотациям отслеживания видно, какие поля выставлялись вручную и какие объекты вообще не создавались из репозитория. Обычно всплывают ресурсы, которые правили при инциденте и забыли перенести в Git.
Дальше — поэтапный переход, без единовременного удаления расхождений. Сначала контроллер (ArgoCD или Flux) работает в режиме сравнения: показывает разницу, но ничего не применяет. Затем миграция конфигураций — живые манифесты снимаются из кластера, из них убираются поля, которые генерирует сам кластер.
После этого включается авто-синхронизация без удаления объектов вне репозитория, и только при стабильно нулевом расхождении — очистка и самовосстановление. Границы очерчиваются заранее: секреты, объекты операторов и привязанные к железу хранилища в репозиторий не переносятся, а исключения задаются по конкретным путям, а не отключением контроля над объектом целиком.
Итог — состояние кластера снова читается из репозитория, откат делается одной ревизией, а любая ручная правка либо попадает в Git, либо видна как отклонение.
Технические сомнения: права, секреты и откаты изменений
Автоматическая синхронизация упирается не в установку контроллера, а в границы: кто может менять состояние кластера, где живут чувствительные данные и что будет, если связь с репозиторием пропадёт. Ниже — то, что инженеры спрашивают до старта работ.
Кто получает право менять прод через Git?
Права выдаются послойно: разработчик пушит в свою ветку, изменение в ветку окружения проходит проверку и подтверждение, а ручной доступ к кластеру закрывается. Иначе состояние в Git и в кластере расходится — и следующая синхронизация откатывает чужую правку.
Где хранятся секреты, если всё описано в репозитории?
Открытых паролей и ключей в Git не остаётся: их либо шифруют перед коммитом, либо подтягивают из внешнего хранилища в момент применения, оставляя в описании только ссылку. Расшифровка доступна контроллеру синхронизации и узкому кругу администраторов.
Можно ли включить автоматизацию частично, а не на весь кластер?
Да, и это обычный порядок внедрения: автоприменение включают сначала на тестовом контуре и некритичных сервисах, прод первое время работает по подтверждению. Настраивается и порядок применения — сначала зависимости, потом сервисы, а частичная синхронизация видна построчно: какие объекты отстали и на какой проверке упали.
Что произойдёт при сбое сервиса синхронизации?
Кластер продолжает работать на последнем применённом состоянии — запущенные приложения не останавливаются, изменения из Git просто не применяются. После восстановления связи синхронизация догоняет разницу, а оповещение о потере связи приходит раньше, чем расхождение заметит пользователь.
Обсудим задачу: что нужно для оценки вашей схемы
Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен срез вашей текущей схемы: как устроены окружения, кто имеет права менять кластер, что уже описано декларативно, а что делается руками. Ниже — то, что снимает основную часть неопределённости при оценке.
- Состав окружений: сколько кластеров и пространств имён, чем отличаются контуры разработки, предпродакшена и продакшена.
- Текущий порядок выкладки: как изменения попадают в кластер сегодня — ручные команды, скрипты, конвейер сборки, и на каком шаге процесс чаще всего останавливается.
- Что уже в репозитории: манифесты, шаблоны, конфигурации окружений и какие объекты остались вне него.
- Роли и доступы: кто коммитит, кто подтверждает выкладку в прод, как выданы учётные данные для автоматической синхронизации.
- Ограничения: политики безопасности, закрытые реестры образов, окна изменений, контуры без внешнего доступа.
- Целевое поведение: полная автосинхронизация или подтверждение на прод, нужен ли возврат к предыдущей версии одной операцией.
Опишите задачу в свободной форме — этого достаточно, чтобы вернуться с оценкой и планом. Схема окружений или пример текущего процесса ускорят разбор: по ним видно, где синхронизация даст эффект сразу, а где потребуется поэтапный переход.
