Defining Application Manifests for GitOps

Create Argo CD Application custom resources that map specific Git source paths to target namespaces within your cluster.

In this lesson, you will learn how to bridge your Git repository and your Kubernetes cluster by crafting Argo CD Application custom resources to automate the reconciliation of your desired state.

The Role of the Application CRD

At the heart of a GitOps workflow is the Application custom resource definition (CRD). While your Git repository acts as the single source of truth for your infrastructure configuration, the Application manifest acts as the "controller" that tells Argo CD exactly where to look for those files and where to apply them within your cluster.

Think of the Application manifest as a pointer: it tells the cluster’s reconciliation loop which Git directory contains the "target state" and which namespace represents the "live state."

Mapping Source to Target

To define this relationship, you create a YAML file that declares the source (your repo and path) and the destination (your cluster and namespace). Here is a standard configuration:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/my-apps.git'
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod-frontend
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

In this snippet, source.path points to the specific directory containing your Helm charts or raw manifests. By mapping this to the destination.namespace, you ensure that any change pushed to the k8s/overlays/production directory in your Git repository is automatically detected by Argo CD and reconciled against the prod-frontend namespace.

Why This Matters

By explicitly defining these mappings, you decouple the deployment mechanism from the application logic. You are no longer running kubectl apply manually; instead, you are declaring the relationship between your code and your cluster. If someone manually modifies a service in the prod-frontend namespace, Argo CD will detect the drift because the live state no longer matches the configuration defined in your Application manifest, and it will automatically revert the cluster to the version defined in your Git repository.

Key Takeaway: The Application CRD serves as the essential bridge in GitOps, binding a specific Git source path to a target Kubernetes namespace to enable automated, declarative synchronization.