Kubernetes Argo CD Application Generator

Build an Argo CD Application with the options that are off by default turned on deliberately: pruning, self-healing, namespace creation and the finalizer that makes a delete actually delete. Each one is explained beside the output.

Application

This object is created in Argo CD's namespace, not in the namespace it deploys to.

Source
Destination

Without this the first sync fails on every object at once, because the namespace is not there.

Sync policy

Every option here is off by default in Argo CD. None of them are on unless you put them on.

Off means every change waits for someone to press Sync.

Off means deleting a file leaves the resource running in the cluster forever.

Off means a kubectl edit sticks and the app just reads OutOfSync.

Adds the finalizer. Without it, deleting the Application orphans everything it created.

Without this, an HPA and Argo CD fight over spec.replicas forever.

application.yaml

updates as you type

    Common mistakes

    These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

    1. Expecting sync to prune removed resources

      Prune is off by default, so a resource deleted from Git stays in the cluster indefinitely and drifts silently.

      Instead:Set syncPolicy.automated.prune: true once you trust the repository.

    2. Leaving selfHeal off and wondering why drift persists

      Without it, a manual kubectl edit stays applied and Argo reports OutOfSync forever without correcting it.

      Instead:Enable selfHeal, and accept that manual edits will be reverted.

    3. Pointing targetRevision at HEAD

      Every commit to the branch deploys immediately, including ones that were not meant for this environment.

      Instead:Pin a tag or a specific revision for production.

    The Argo CD defaults that are the opposite of what people assume

    An Application is a short manifest and most of its interesting behaviour is off unless you turn it on. Nothing warns you, because none of these are errors: they are a system doing exactly what it was configured to do, which happens not to be what anyone expected.

    The Application lives in Argo CD's namespace

    Not in the namespace it deploys to. Argo CD watches its own namespace for Application objects, and one created anywhere else is stored by the API server without complaint and never reconciled. There is no error, no event and no entry in the UI, because as far as Argo CD is concerned the object does not exist.

    metadata:
  name: api
  namespace: argocd          <- where Argo CD runs

spec:
  destination:
    namespace: production    <- where the app goes

# these are different namespaces and the first one is
# the one that decides whether anything happens at all.

    prune is false, so deleting from git deletes nothing

    Removing a manifest from the repository does not remove the resource from the cluster. It keeps running, and the Application still reports Synced, because Argo CD compares what git declares against what exists and a resource git no longer mentions is simply not compared. Orphaned Services, PVCs and LoadBalancers build up this way for months.

    syncPolicy:
  automated:
    prune: true      <- not the default

# without it:
#   delete service.yaml from git
#   -> Application: Synced, Healthy
#   -> the Service, and its cloud load balancer,
#      are still there and still billed

    selfHeal is false, so a manual edit sticks

    Without it, a kubectl edit against a managed resource is not reverted. The Application reads OutOfSync, which on most dashboards is a colour rather than a page. So a fix applied by hand at 3am quietly becomes the running configuration until someone syncs, at which point it disappears with no warning and the incident repeats.

    selfHeal: false   (default)
  kubectl edit deploy/api    -> change persists
  Application status         -> OutOfSync
  next manual sync           -> silently reverted

selfHeal: true
  the change is reverted within a couple of minutes,
  which is the point, and it means emergency fixes
  must go through git.

    Without the finalizer, deleting the Application orphans everything

    Deleting an Application deletes the Application. Every Deployment, Service, PVC and cloud load balancer it created keeps running, unmanaged, with nothing pointing at them any more. The cascade only happens if the finalizer is present, and it has to be there before the delete, not added afterwards.

    metadata:
  finalizers:
    - resources-finalizer.argocd.argoproj.io

# with it:    delete the Application -> resources go
# without it: delete the Application -> resources stay,
#             now owned by nobody and invisible to
#             every GitOps dashboard you have

    Synced is not Healthy, and alerting on the wrong one is common

    Synced means the cluster matches git. That is all it means. A sync that applies perfectly is Synced even if every pod then crash-loops on startup, because the manifests were written successfully. Health is a separate status computed from the resources themselves, and a pipeline that gates on Synced reports a successful deploy for a completely broken release.

    argocd app get api

Health Status:  Degraded
Sync Status:    Synced          <- both are true

# Synced  = the YAML in the cluster matches the YAML
#           in git
# Healthy = the things that YAML created are working

    Related kubernetes tools

    Kubernetes YAML Generator Answer a few questions, get a manifest Kubernetes Deployment Generator See the capacity dip before you deploy Kubernetes Service Generator port, targetPort, and which one you meant Kubernetes Ingress Generator pathType, and the TLS secret that fails quietly Kubernetes CronJob Generator The fields that decide whether it runs Kubernetes YAML Validator Is this YAML valid, and where is it wrong?
    All 55 kubernetes tools

    Elsewhere on the site

    Terraform Validator & Formatter AWS IAM Policy Validator & Analyzer Docker Container Image Reference Parser VPC Subnet & CIDR Calculator