Вы правы, действительно о разном) В рамках плагина такого подхода реализовать не получится. Подобный сценарий можно попробовать реализовать в рамках настройки доступа к проектам созданных в ArgoCD. Пример настройки declarative-setup/#projects Сама схема звучит избыточно, и скорее будет правильнее использовать отдельный инструмент для multitenancy
Оценивать схему можно с учётом её плюсов и минусов с учётом рабочих условий. Можно обновлять официальный образ argocd-repo-server, и делать это при каждом обновлении ArgoCD, что добавляет накладные расходы на пересборку образа. Скачивание плагина можно запроксировать через какой-нибудь artifactory или nexus, чтобы всегда была возможность подтянуть из кеша, даже если github стал недоступен. При наличии ограничения emtyDir, можно прибегнуть к хранению плагина в persistent volume, либо всё же выбрать предыдущий вариант.
Альтернативу Flux + SOPS в рамках данной статьи рассматривать не получится, т.к выбор будет между ArgoCD и FluxCD. Но можно рассмотреть SOPS в качестве альтернативы AVP. Также необходимо подключить плагин, либо через пересборку образа, либо подключения через initContainer. Вариант с SOPS выглядит даже чуточку привлекательнее, т.к. не обязательно требуется внешний источник секретов, и есть варианты настроек. А Sealed secrets вообще особняком стоит как отдельное приложение, что в некоторой степени ещё более выигрышная схема. У всех решений есть свои нюансы. Взвешивая плюсы и минусы, на мой взгляд, при минимальных требованиях, проще реализовать схему с хранением секретов в Vault.
По поводу изоляции можно отметить следующее: в ArgoCD принадлежность ресурсов к Application определяется меткой по типу: app.kubernetes.io/instance: my-app-my-ns-my-proj, и один и тот же ресурс может принадлежать только одному приложению, в противном случае будет вечный out of sync, и конкурентная борьба за ресурс. В случае из статьи, принадлежность относится только к приложению app-of-secrets, т.е. сам секрет в других приложениях можно подключать только как extraSecret. И в ArgoCD Application можно использовать только один source для Application, т.е это либо хелм, либо плагин, либо иной вариант. Если хотите разные Application для создания Secret, как вариант — раздельное хранение самих манифестов Secret.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Выглядит инетресно, возьму на заметку. Спасибо
Вы правы, действительно о разном) В рамках плагина такого подхода реализовать не получится. Подобный сценарий можно попробовать реализовать в рамках настройки доступа к проектам созданных в ArgoCD. Пример настройки declarative-setup/#projects
Сама схема звучит избыточно, и скорее будет правильнее использовать отдельный инструмент для multitenancy
Пожалуй, ответи стоит разделить на пункты:
Оценивать схему можно с учётом её плюсов и минусов с учётом рабочих условий. Можно обновлять официальный образ argocd-repo-server, и делать это при каждом обновлении ArgoCD, что добавляет накладные расходы на пересборку образа. Скачивание плагина можно запроксировать через какой-нибудь artifactory или nexus, чтобы всегда была возможность подтянуть из кеша, даже если github стал недоступен. При наличии ограничения emtyDir, можно прибегнуть к хранению плагина в persistent volume, либо всё же выбрать предыдущий вариант.
Альтернативу Flux + SOPS в рамках данной статьи рассматривать не получится, т.к выбор будет между ArgoCD и FluxCD. Но можно рассмотреть SOPS в качестве альтернативы AVP. Также необходимо подключить плагин, либо через пересборку образа, либо подключения через initContainer. Вариант с SOPS выглядит даже чуточку привлекательнее, т.к. не обязательно требуется внешний источник секретов, и есть варианты настроек. А Sealed secrets вообще особняком стоит как отдельное приложение, что в некоторой степени ещё более выигрышная схема. У всех решений есть свои нюансы. Взвешивая плюсы и минусы, на мой взгляд, при минимальных требованиях, проще реализовать схему с хранением секретов в Vault.
По поводу изоляции можно отметить следующее: в ArgoCD принадлежность ресурсов к Application определяется меткой по типу:
app.kubernetes.io/instance: my-app-my-ns-my-proj, и один и тот же ресурс может принадлежать только одному приложению, в противном случае будет вечный out of sync, и конкурентная борьба за ресурс. В случае из статьи, принадлежность относится только к приложению app-of-secrets, т.е. сам секрет в других приложениях можно подключать только как extraSecret. И в ArgoCD Application можно использовать только один source для Application, т.е это либо хелм, либо плагин, либо иной вариант. Если хотите разные Application для создания Secret, как вариант — раздельное хранение самих манифестов Secret.