Блог

Вот распространенный сценарий, которого мы придерживались:

1. Приложение Argocd, созданное и синхронизированное с Helm, имеет развертывание с 1 модулем, все зеленые.
2. Мы обновляем тег образа развертывания с некоторым нарушенным значением, которого нет в нашем реестре образов Docker, и вносим изменения в репозиторий git.
3. Argo получает обновления из репозитория git, состояние синхронизации-зеленое состояние синхронизации, но работоспособность приложения»Обрабатывается»
4. В результате развертывания изменений пытается развернуть новый модуль со сломанным тегом изображения и, очевидно, не может этого сделать.
5. Приложение Agrocd застряло в состоянии «Обработка» работоспособности приложения примерно на 10 минут и в конечном итоге перешло в состояние «Деградация».

Теперь вопрос, можем ли мы ограничить это время и получить состояние «Деградации» за 1 или 2 минуты вместо 10?

Вы создаете приложение с графическим интерфейсом или файлом yaml?
Если вы создаете приложение с файлом yaml, вы можете сделать это, установив ограничение поля или максимальное значение при повторной попытке.
Вот пример

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata:  name: guestbook  # You'll usually want to add your resources to the argocd namespace.  namespace: argocd  # Add a this finalizer ONLY if you want these to cascade delete.  finalizers:  - resources-finalizer.argocd.argoproj.io spec:  # The project the application belongs to.  project: default   # Source of the application manifests  source:  repoURL: https://github.com/argoproj/argocd-example-apps.git  targetRevision: HEAD  path: guestbook   # helm specific config  helm:  # Release name override (defaults to application name)  releaseName: guestbook   # Helm values files for overriding values in the helm chart  # The path is relative to the spec.source.path directory defined above  valueFiles:  - values-prod.yaml   # Optional Helm version to template with. If omitted it will fall back to look at the 'apiVersion' in Chart.yaml  # and decide which Helm binary to use automatically. This field can be either 'v2' or 'v3'.  version: v2   # Destination cluster and namespace to deploy the application  destination:  server: https://kubernetes.default.svc  namespace: guestbook   # Sync policy  syncPolicy:  automated: # automated sync by default retries failed attempts 5 times with following delays between attempts ( 5s, 10s, 20s, 40s, 80s ); retry controlled using `retry` field.  prune: true # Specifies if resources should be pruned during auto-syncing ( false by default ).  selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ).  allowEmpty: false # Allows deleting all application resources during automatic syncing ( false by default ).  syncOptions: # Sync options which modifies sync behavior  - Validate=false # disables resource validation (equivalent to 'kubectl apply --validate=false') ( true by default ).  - CreateNamespace=true # Namespace Auto-Creation ensures that namespace specified as the application destination exists in the destination cluster.  - PrunePropagationPolicy=foreground # Supported policies are background, foreground and orphan.  - PruneLast=true # Allow the ability for resource pruning to happen as a final, implicit wave of a sync operation  # The retry feature is available since v1.7  retry:  limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0  backoff:  duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")  factor: 2 # a factor to multiply the base duration after each failed retry  maxDuration: 3m # the maximum amount of time allowed for the backoff strategy