You've installed ArgoCD and understand its architecture. Now comes the core GitOps practice: creating an Application resource that tells ArgoCD what to sync, where to sync it, and how often to check for changes.
An Application is a Kubernetes Custom Resource Definition (CRD) that acts as a contract between Git and your cluster. When you create an Application, you're saying: "Watch this Git repository for changes. When something changes, apply it to my cluster."
In this chapter, you'll:
By the end, you'll have your Module 6 FastAPI agent running on your cluster, managed by ArgoCD.
An Application resource looks like this:
Let's break down each section:
repoURL: The Git repository containing your manifests. This can be:
path: The directory within the repository containing Kubernetes manifests or Helm charts. Examples:
targetRevision: Which Git ref to sync from:
helm (optional): If syncing a Helm chart, override values without modifying Git:
server: The Kubernetes API server URL:
namespace: The target namespace. ArgoCD creates it if it doesn't exist (with CreateNamespace=true).
Manual sync (default):
You click "Sync" manually in the UI or run argocd app sync fastapi-agent in the CLI.
Automated sync (this chapter's approach):
prune: If you remove a resource from Git, ArgoCD deletes it from the cluster.
selfHeal: If someone manually edits a resource in the cluster (or it crashes), ArgoCD detects the drift and reapplies the Git state.
The ArgoCD UI provides a visual way to create applications. This is useful for learning and one-off applications, but production typically uses declarative YAML (GitOps).
Make sure you have port-forwarding running (from Chapter 7):
Output:
Navigate to https://localhost:8080 and log in.
You'll see an empty Applications list. Click the "+ NEW APP" button in the top right.
A form appears with sections:
For this chapter, we'll use a public Helm chart as an example. In practice, you'd use your own repository.
If your repository is private, you'll configure Git credentials in future chapters.
In the SYNC POLICY section, you'll see checkboxes:
Then click "CREATE".
ArgoCD now watches your repository. The Application status starts as OutOfSync because the cluster doesn't have the manifests yet.
Click the Application card to view details. You'll see:
Click "Sync" in the top right. A dialog appears:
Click "SYNCHRONIZE".
ArgoCD now:
Watch the UI update. After 30 seconds, the Status changes to Synced and Health updates to Healthy (or Progressing if pods are still starting).
The CLI approach is faster for experts and enables scripting. You'll use argocd app create.
If you haven't already, authenticate:
Output:
Output:
The --auto-prune and --self-heal flags enable automated sync. Without them, sync would be manual.
Output:
Output:
The Application is now synced and healthy.
This is the GitOps way: define your Application as YAML in a Git repository, then apply it with kubectl.
Create a file argocd/fastapi-agent.yaml:
Output:
Kubernetes creates the Application resource. The ArgoCD Application Controller detects it and immediately starts syncing.
Output:
Wait 10-20 seconds:
Output:
Output:
Your Application is now synced and healthy, managed entirely by GitOps.
When ArgoCD compares Git with the cluster, it produces a Sync Status.
What it means: Git has resources that the cluster doesn't have, or Git has removed resources the cluster still has.
Why it happens:
How to fix: Click "Sync" in the UI or run argocd app sync <app-name> in the CLI.
Example:
Output:
What it means: ArgoCD is actively applying changes to the cluster.
Why it happens:
How to monitor: Watch the UI or run:
What it means: The cluster state matches the Git state. Everything is in sync.
Why it's good: Your cluster is exactly as defined in Git. You have a single source of truth.
Example:
Output:
Sync Status tells you if Git and cluster match. Health Status tells you if the deployed resources are actually working.
What it means: All resources are running and reporting healthy. Deployments have desired replicas running, Services have endpoints, StatefulSets are ready.
Example:
Output:
What it means: Resources are deploying. Pods are starting, but not all replicas are ready yet.
Why it happens:
How to monitor: This usually resolves within 30-60 seconds. If it stays Progressing for more than 5 minutes, check pod logs:
What it means: Resources are deployed but not functioning. Pods are CrashLooping, Services have no endpoints, or Deployments have failed replicas.
Why it happens:
How to fix: Check pod logs and events:
What it means: ArgoCD hasn't checked health yet, or it can't determine health.
Why it happens:
How to fix: Wait 10 seconds and refresh. If it stays Unknown, check ArgoCD logs:
What it means: A resource defined in Git doesn't exist in the cluster.
Why it happens:
How to fix: Trigger a sync or check ArgoCD logs for RBAC errors.
After your Application is synced, verify the actual resources were created:
Output:
These resources came from the Helm chart that ArgoCD rendered and applied. You can verify this by comparing with Git:
This shows you exactly what ArgoCD rendered before applying.
Here's the complete flow when you push changes to Git:
The Repository Server fetches your repo every 3 seconds (default interval, configurable). When it detects a new commit, the Application status changes to OutOfSync.
If you have automated: { enabled: true } in syncPolicy, ArgoCD immediately syncs:
Syncing → Synced as changes are applied.
ArgoCD checks if all resources are healthy (Deployments have desired replicas, Services have endpoints, etc.).
Progressing → Healthy (assuming no errors).
Users see the new version. If something breaks, you revert the Git commit and push again. Rollback is just git revert <commit>.
If your repository contains plain Kubernetes YAML files (no Helm, no Kustomize):
ArgoCD uses the YAML as-is. No templating.
If you're syncing a Helm chart, specify the chart values:
ArgoCD runs helm template with these values before applying.
If your manifests use Kustomize:
ArgoCD runs kustomize build before applying.
You can register multiple clusters and deploy to them:
ArgoCD then syncs the same manifests to multiple clusters.
You built a gitops-deployment skill in Chapter 0. Test and improve it based on what you learned.
Ask yourself:
If you found gaps: