Argo CD: Diff и drift после ручного изменения

Первый выпуск применил dev overlay. Теперь представим обычную ситуацию: разработчик увеличил API replicas напрямую, чтобы разобраться в поведении, и не обновил Git. В этой главе «Релиз» покажет drift — расхождение live состояния с выбранной декларацией. Результат — умение найти конкретное поле и решить, сохранить новое намерение в Git либо вернуть согласованный вариант.

Автор не выполнял scale, diff или sync. Состояния и команды ниже ожидаемые, рассчитаны на отдельный kind-release после предыдущего урока. Приёмы сравнения сверены с официальной документацией Argo CD о diff. Не будем превращать исключения сравнения в способ скрыть любое неудобное расхождение.

Live изменение имеет другого автора

Git dev overlay задаёт одну API копию. Reader может адресно изменить live Deployment до двух. Kubernetes создаст дополнительный Pod, поскольку контроллер Deployment реагирует на текущий spec независимо от того, каким инструментом поле изменено. Argo CD затем сравнит live replicas два с желаемым один и покажет отличие.

Это не противоречие двух систем. Kubernetes выполняет live spec, Argo CD хранит связь с Git намерением. В выбранной ручной политике Argo CD не обязан немедленно возвращать один. Поэтому наблюдаемый drift остаётся до следующего решения. Если человек ожидал автоматический возврат, ему нужно было бы отдельно выбрать selfHeal политику, а не считать manual sync ошибкой установки.

Смена числа копий не означает новую версию API. Image и конфигурация могут остаться прежними. Так же смена ConfigMap сама по себе не гарантирует, что процесс уже перечитал окружение. Diff нужно связывать с конкретным полем и механизмом его действия, а не интерпретировать любое красное изменение как один и тот же «неправильный релиз».

Читаем изменение в контексте ресурса

Следующая последовательность предназначена reader для будущего локального разбора. Scale меняет только API в dev, не оба окружения одновременно.

kubectl --context kind-release -n ploshchadka-dev scale deployment/api --replicas=2
argocd app get release-dev --refresh
argocd app diff release-dev

Ожидаемая существенная разница — spec.replicas Deployment api. Diff также может содержать признаки других ранее выполненных действий. Reader должен прочитать kind, name и namespace каждого ресурса, чтобы не приписать всё одной команде. Например, image api два мог попасть из другого commit, а лишний ConfigMap остаться от прошлой конфигурации.

Git revision в get связывает diff с исходным набором. Если main уже переместилась после публикации bundle, желаемое состояние может отличаться от того, что reader помнит из первого sync. Поэтому перед решением важно прочитать разрешённый commit. Сравнение с воображаемой «старой версией» мешает понять, какой именно источник контроллер считает текущим.

Возвращаем согласованную декларацию

Если увеличение replicas было временным, reader выполняет manual sync release-dev после просмотра difference. Желание Git остаётся прежним: одна копия. Deployment должен постепенно привести live к ней. Дополнительный Pod исчезнет по правилам контроллера. Это ожидаемый возврат управляемого поля, а не удаление всех ресурсов приложения.

Повторный get/diff должен показать отсутствие этого расхождения после завершения операции. Если поле снова меняется, нужно найти другого владельца: ручной процесс, HPA или оператор. Постоянно нажимать sync в споре двух контроллеров неразумно. Одно поле должно иметь определённого ответственного, а декларация должна отражать выбранное разделение управления.

В нашем комплекте HPA не включён. Это важно, поскольку прежняя Kubernetes серия показывала его только как условную отдельную ветку с Metrics API. Новый GitOps маршрут не переносит её автоматически. Replicas остаётся полем Git overlay, поэтому ручной drift имеет простой и объяснимый источник. Подключение HPA потребовало бы изменить модель владения этим полем.

Сохраняем намеренное изменение через Git

Если две dev копии действительно нужны, reader меняет replicas count в gitops/overlays/dev/kustomization.yaml. Затем создаёт commit, публикует bundle и делает refresh. Если live уже содержит те же два, разница этого поля исчезнет без дополнительного создания новой копии. История Git теперь объясняет причину желаемого числа и будет воспроизводить его на новом окружении.

Важно записывать изменение в исходный overlay, а не только в сгенерированный YAML. Kustomize снова построит результат из исходников при следующем refresh. Ручная правка временного вывода не изменит repository path и потеряется. То же правило относится к APP_VERSION и image: desired state принадлежит versioned source, а не последнему скопированному листингу.

После commit публикация bundle необходима, потому что daemon читает bare repository в PVC, а не working tree ноутбука. Reader может видеть правильный Git log у себя, но repo-server ещё получает прежний main. Это не кеш браузера; это незавершённый путь доставки source. Регламент специально разделяет commit и доступность его контроллеру.

Исключение сравнения требует причины

Argo CD поддерживает настройку diff для полей, которые управляются другим механизмом или нормализуются API. Однако исключение replicas только ради исчезновения текущего drift скрыло бы главное поле нашей учебной декларации. Сначала определяют владельца, затем выбирают, действительно ли это поле должно перестать участвовать в контроле данного Application.

Пример разумной причины — отдельный autoscaler, которому передано масштабирование. Тогда Git описывает его политику, а replicas может иметь другой договор сравнения и применения. Но такой autoscaler в текущем архиве отсутствует. Поэтому статья не предлагает готовое ignoreDifferences, создающее ложное впечатление, будто HPA уже установлен и его поведение проверено.

Ignore в diff и поведение при sync также следует различать. Настройка отображения расхождения не всегда означает, что apply никогда не изменит это поле. При выборе дополнительных sync options reader должен сверить их официальный смысл и последствия. В нашей ручной base никаких таких исключений нет; простое сравнение помогает сначала понять причинную связь.

Drift полезен как свидетельство

Расхождение сообщает, что кто-то изменил live либо source, но само по себе не доказывает инцидент. Две API копии могут нормально обслуживать каталог, хотя организация намерений нарушена. Обратная ситуация тоже возможна: всё Synced, но код отдаёт неправильный ответ. Поэтому diff становится одним наблюдением рядом с history, Pod событиями и пользовательским маршрутом.

Для передачи полезно записать время своего действия, объект, поле и причину. Не нужно копировать весь вывод кластера без интерпретации. Следующий разработчик должен понять, было ли scale временной диагностикой, новым выбранным состоянием или непреднамеренной правкой. Эта информация определяет следующий шаг точнее, чем общая фраза «Argo CD красный».

После урока manual sync имеет ясный смысл в сопровождении. Reader находит drift, решает его судьбу и либо возвращает Git декларацию, либо сохраняет новое намерение commit и публикует его источнику. Следующая глава расширит source структуру до двух overlays, чтобы перенос выпуска между dev и stage происходил осознанно и не требовал копирования всего набора YAML.

Оглавление серии