Mustafa ERBAY

Posted on Aug 16 Originally published at mustafaerbay.com.tr

Introduction to GitOps: Pull-Based Deployment Model with Argo CD

#kubernetes #deployment

What is GitOps?

GitOps defines the principle of managing infrastructure and application configurations by using a Git repository as the single source of truth. This approach minimizes human error through declarative definitions and automated synchronization. The core advantage of GitOps is that every change is fully traceable and reversible by the entire team; when a commit is rolled back, the system can automatically revert to its previous desired state.

ℹ️ Why GitOps?

GitOps combines change auditing with Git's robust version control mechanism, significantly simplifying auditing, compliance, and rollback processes.

How Does Argo CD Work?

Argo CD is a controller that monitors Git repositories and automatically pulls and applies application manifests to a Kubernetes cluster. In the Pull-Based model, Argo CD defines the target repository and path via an Application custom resource; the control loop checks the repository every 3 minutes (180 seconds) by default and initiates a synchronization if differences are detected. This process displays real-time sync and health statuses directly in the Argo CD UI.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-app
spec:
  project: default
  source:
    repoURL: https://github.com/example/demo
    targetRevision: HEAD
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

In the Application manifest above, setting spec.syncPolicy.automated.prune: true ensures that resources deleted from the Git repository are also automatically removed from the Kubernetes cluster. Setting selfHeal: true ensures that when drift from the state defined in Git is detected within the live cluster, Argo CD automatically reverts those changes to keep the cluster state matched with Git.

What is the Pull-Based Deployment Model?

The Pull-Based deployment model refers to the control plane (controller) pulling and applying configurations from a Git repository independently of manual user interaction. In this model, instead of push commands like kubectl apply, an operator like Argo CD periodically reads the repository and automatically synchronizes differences. The pull approach simplifies firewall rules because it requires only an outbound connection and eliminates the need to expose an external listener within your internal network, significantly reducing security risks.

Argo CD Installation Steps

Installation can be done using Helm charts or kubectl manifests. Here is a simple example using kubectl. The first step is to create the argocd namespace and apply the necessary manifests.

⚠️ Production Environment Warning

The kubectl apply command below installs Argo CD with cluster administrator (cluster-admin) privileges and is a non-HA (High Availability) setup, which is not recommended for production environments. For production, installing via Helm and pinning to a specific Argo CD version is recommended. Additionally, rather than applying manifests directly from https://raw.githubusercontent.com, downloading, inspecting, and then applying them is much safer.

# Create namespace
kubectl create namespace argocd

# Apply Argo CD manifests
# --server-side and --force-conflicts flags are recommended due to CRD size limits.
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Next, configure a LoadBalancer or Ingress to expose the argocd-server service externally. Once the installation is complete, the admin password is stored directly inside a secret, allowing you to log in to the UI.

ℹ️ Port Forwarding for Local Testing

This command is used to access the Argo CD UI from your local machine and should not be used in production environments. The terminal session will remain attached while the command runs.

# Port forward for UI access (for local testing)
kubectl port-forward svc/argocd-server -n argocd 8080:443

After installation, you can authenticate via the CLI using argocd login; this allows you to bypass the UI in script-based automations. For Argo CD v1.9 and later, the initial admin password is stored in the argocd-initial-admin-secret secret under the password key.

⚠️ Security Warning: Change the Default Password

It is strongly recommended to change the default admin password immediately after your first login. You can also delete the argocd-initial-admin-secret secret once the password has been updated.

# Retrieve the admin password (for Argo CD v1.9+)
ADMIN_PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)
echo "Argo CD Admin Password: $ADMIN_PASSWORD"

# Authenticate via CLI (--insecure flag may be required for local testing)
argocd login localhost:8080 --username admin --password "$ADMIN_PASSWORD" --insecure

Application Deployment Workflow

The Mermaid diagram below shows how a Git commit reaches Kubernetes through Argo CD. This workflow includes the detect change → synchronize → health check → report steps. Logs are recorded at each phase.

In a production-like environment, changes can be inspected beforehand using the dry-run option during sync. In the Argo CD CLI, running argocd app sync --dry-run executes a client-side dry-run by default. For a server-side dry-run, additional configuration or an alternative approach may be needed.

To reproduce this workflow in a lab environment, simply create an Application manifest and replace the repoURL and path fields with your own test repository. After synchronization, you can verify that the deployment succeeded by running kubectl get pods -n <namespace>.

Best Practices and Common Pitfalls

Best Practice 1 – Declarative Manifests: Make manifest files as parameter-driven as possible; overlays based on kustomize or helm allow you to manage environment differences (dev, staging, prod) within a single repository. Common Pitfall 1 – Direct Pushes: Direct push operations like kubectl apply defeat the entire purpose of GitOps and stop Git from being the single source of truth; route all changes exclusively through Git.

Best Practice 2 – Automated Self-Heal: The syncPolicy.automated.selfHeal feature automatically remediates drift (state divergence) without requiring manual intervention. Common Pitfall 2 – Prune Disabled: Failing to clean up deleted resources automatically leads to resource leakage over time; enabling prune: true eliminates this risk.

Best Practice 3 – RBAC Configuration: Using the default admin account in production creates a serious security vulnerability; define project-based roles instead and grant access only to the necessary namespaces. Common Pitfall 3 – Overly Broad Permissions: Granting broad cluster-admin roles can cause a single faulty commit to impact the entire cluster; strictly enforce the principle of least privilege.

Conclusion

Argo CD puts the pull-based model of GitOps into practice, making Kubernetes deployments consistent and observable. Declarative manifests, automated self-healing, and granular RBAC controls ensure the long-term sustainability of this approach. Because the setup and core workflow are straightforward, teams can quickly transition to production; however, if security and resource management practices are neglected, the benefits of GitOps can quickly erode. The next natural step is to integrate your existing CI pipeline with Argo CD and introduce post-sync automated testing and canary deployment strategies.

DEV Community