Prune, полномочия и ссылки на Secret

После нескольких выпусков ConfigMap generator оставляет прежние версии, а source может больше не содержать отдельный ресурс. Теперь нужно понять prune и права, с которыми выполняется это действие. Результат главы — адресное удаление лишнего прикладного набора при сохранении namespace, Git PVC и внешних Secret, которые Application не владеет.

Автор не выполнял удаление, изменение ролей или создание действующих полномочий. Состояния ожидаемые. Поведение опций сверено с Argo CD Sync Options, удаление Application — с App Deletion. Курс остаётся локальным: реальных credentials в repository и bundle нет.

Отсутствие в Git ещё не означает удаление live

Когда конфигурационные данные меняются, Kustomize создаёт новый hash ConfigMap. Deployment получает новую ссылку, а прежний ConfigMap может оставаться. Manual sync без prune не обязан удалять ресурс, который больше не входит в желаемый набор. Это позволяет отдельно увидеть обновление приложения и решение об очистке старых объектов.

Prune удаляет отслеживаемые ресурсы приложения, отсутствующие в текущем source результате. Его действие нужно читать в контексте конкретного Application. Оно не означает «удалить всё неизвестное в namespace». Если рядом существует api-demo-secret, который создан bootstrap и не принадлежит этому Application, отсутствие Secret в GitOps source не должно превращать его в кандидата для обычного удаления данного набора.

История release и список live объектов дают причины для очистки. Прежний ConfigMap может быть больше не нужен текущим Deployment, но полезен для понимания прошлой конфигурации. Если reader выбирает prune, следует сначала прочитать имена и ownership. Без такого чтения параметр может стать не объяснённым удалением, особенно когда source path случайно изменён на пустой каталог.

Очищаем один определённый набор

Будущий reader сначала refresh и diff нужного Application. Затем изучает лишние отслеживаемые ресурсы и только после этого выполняет sync с prune. В нашей серии автоматический prune не включён, поэтому сама публикация commit не запускает неожиданную очистку.

argocd app get release-dev --refresh
argocd app diff release-dev
# После просмотра лишних ресурсов именно release-dev:
argocd app sync release-dev --prune

Ожидаемый результат после осознанной очистки старой конфигурации — текущий hash ConfigMap и Deployment ссылка сохраняются, прежние отслеживаемые ConfigMap удаляются. Namespace ploshchadka-dev и Git PVC в release-lab не принадлежат прикладному source. Если список удаления содержит их, граница Application уже нарушена и сначала нужно исправить источник или ownership.

Нельзя включать allowEmpty только потому, что случайно выбранный path ничего не построил. Пустое желаемое приложение может быть намерением полного удаления, а может быть ошибкой source. В текущем комплекте нет автоматизации пустого удаления. Reader должен связать такой diff с конкретным решением, сохранив возможность восстановить известный source revision.

Удаление Application имеет отдельную семантику

Bootstrap Application не содержит resources-finalizer. Поэтому удаление самого объекта Application не описано как автоматическое каскадное удаление API/web. Это выбранная граница учебной передачи: можно прекратить управление, оставив live ресурсы для отдельного решения. При добавлении finalizer последствия изменятся, и регламент должен назвать это явно.

Если требуется полностью завершить лабораторию, reader сначала сохраняет Git рабочую копию и нужные данные вне кластера, затем адресно выбирает удаление своей kind среды. Это другое действие, чем prune release-dev. Git PVC относится к инфраструктуре источника, а удаление всего кластера может уничтожить её локальное хранение. Нельзя выдавать сохранённый main внутри удаляемого PVC за внешнюю копию.

Один контекст kind-release и конкретные namespaces присутствуют в командах, чтобы действие имело обозримую область. Курс не предлагает общую очистку всех кластеров или namespaces компьютера. Если reader использовал лабораторию совместно, решение о завершении уже зависит от владельцев реального состояния, а не от текста команды в статье.

AppProject и пользовательские политики

AppProject разрешает только Git URL, два namespaces и три вида ресурсов. Этот фильтр препятствует случайному расширению приложения на cluster-scoped инфраструктуру. Однако стандартный installation контроллера имеет широкую Kubernetes роль; AppProject не изменяет её сам. Для production нужна отдельно выбранная модель полномочий контроллера и доступа к cluster API.

Roles observer и releaser показывают разделение чтения и sync в Argo CD. По официальной RBAC документации политика относится к определённым субъектам и объектам. Просто записать роль в YAML недостаточно, чтобы реальный человек автоматически вошёл с ней. Конечный комплект не создаёт внешний SSO и не выдаёт пользователям действующие токены.

Также нужно отличать право синхронизации от права изменения источника. Git daemon read-only, но доступ kubectl exec/cp к git Pod позволяет импортировать bundle. Администратор такой границы способен поменять desired state. Поэтому защита релиза включает контроль Git публикации, управление Application и Kubernetes доступ, а не только красивую кнопку sync в UI.

SecretRef не раскрывает содержание

API Deployment хранит имя api-demo-secret и ожидает ключ DEMO_ADMIN_TOKEN. Reader создаёт учебную строку отдельно в dev и stage. В source нет действующего значения, но имя зависимости доступно для анализа. Это позволяет проверить полноту конфигурации, сохраняя содержание за пределами GitOps каталога.

Отсутствующий Secret должен дать видимый отказ запуска, а не тихую работу с пустым токеном. Поэтому ссылка обязательна. При смене содержимого env процесса не перечитывается автоматически: нужно известное действие, создающее новые экземпляры. Сам Git diff не показывает новое значение внешнего Secret, поэтому сопровождение обязано назвать его отдельного владельца и порядок применения.

Официальный раздел Secret Management описывает подходы к доставке секретов. В этой лаборатории не установлен внешний controller или плагин обработки шифрованных файлов. Нельзя называть ссылку SecretRef готовой системой ротации, аудита или шифрования. Для публичного проекта этот участок потребуется спроектировать отдельно и проверить фактическую работу.

После урока очистка и полномочия имеют разные уровни ответственности. Prune относится к лишнему отслеживаемому набору, Application deletion зависит от finalizer, bootstrap хранит инфраструктуру и Secret, Git публикация имеет отдельного владельца. Следующая глава соберёт эти границы в handoff, чтобы локальный «Релиз» можно было передать без неизвестных образов и ложного отчёта о развёртывании.

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