TL;DR

ArgoCD has established itself as the industry standard for Continuous Delivery in Kubernetes. By implementing the GitOps paradigm, it transforms infrastructure management from imperative pipelines to declarative state management. This enables automated synchronization (“Self-Healing”), seamless auditability, and a strict separation of CI (Continuous Integration) and CD (Continuous Delivery).

1. The Architectural Principle: Pull Instead of Push

Traditional deployment tools operate on a “push-based” model. An external pipeline (e.g., Jenkins or GitLab CI) accesses the cluster and executes commands to apply updates. This poses a security risk as CI servers require extensive permissions within the cluster.

ArgoCD reverses this model (“pull principle”). The ArgoCD controller runs within the Kubernetes cluster and monitors linked Git repositories.

1. Observation: The controller continuously compares the current state in the cluster with the desired state in Git (manifests, Helm charts, Kustomize).
2. Synchronization: As soon as a change is detected in Git (e.g., a new image tag), ArgoCD applies this change to the cluster.

Since only the cluster needs read-only access to the Git repo, and no external tools have write permissions in the cluster, the attack surface is drastically reduced.

2. Core Feature: Drift Detection and Self-Healing

A key differentiator of ArgoCD is its ability to detect deviations (“drift”) that are not triggered by Git.

If an administrator manually changes a resource using kubectl (e.g., increases a pod’s memory limit), a discrepancy with the Git definition arises.

• Drift Detection: ArgoCD immediately marks the application as OutOfSync.
• Self-Healing: If automatic synchronization is enabled, ArgoCD immediately overwrites the manual change with the state from Git.

This enforces discipline: Git is the single source of truth. Manual “hotfixes” bypassing the cluster are technically prevented, significantly increasing the stability of production environments.

3. Multi-Cluster Management and Transparency

ArgoCD offers a central management interface (UI) and CLI to control deployments across hundreds of clusters. Instead of logging into each cluster individually, the ArgoCD instance serves as a control plane. This provides transparency over which version of an application is currently running in which environment (Dev, Staging, Prod).

4. Operational Models Compared: AWS EKS vs. ayedo Managed Kubernetes

Here, it is decided whether GitOps truly remains portable or if one inadvertently maneuvers into vendor lock-in.

Scenario A: ArgoCD on AWS EKS (Building Your Own Golden Cage)

Operating ArgoCD on EKS often leads to the trap of “deep integration.” To make ArgoCD productive and secure, teams usually rely on native AWS services, which destroys independence:

• Identity Coupling (IRSA): Permissions for ArgoCD are managed via IAM Roles for Service Accounts (IRSA) and proprietary annotations in the ServiceAccounts. This logic only works on AWS.
• Ingress Dependency: To securely provide the UI, the AWS Load Balancer Controller with ACM certificates is often used. The result: Ingress manifests are “contaminated” with AWS-specific annotations and do not run on any other cluster.
• The Result: Although ArgoCD is open source, the specific implementation is no longer portable. Switching to another provider requires a complete refactoring of the deployment manifests, meaning the theoretical portability of containers is practically null and void.

Scenario B: ArgoCD with Managed Kubernetes by Ayedo

In the Ayedo App Catalog, ArgoCD is a core component (First Class Citizen) designed for maximum portability.

• Standard Compliance: Integration is done through open standards (Nginx Ingress, Cert-Manager for certificates, OIDC via Keycloak/Dex).
• No Cloud Annotations: Manifests remain clean from provider-specific noise.
• True Portability: The setup is identical, whether running on AWS, Azure, or in a local data center. Vendor lock-in is prevented at the architectural level.

Technical Comparison of Operational Models

FAQ: ArgoCD & GitOps

How do I handle sensitive data (secrets) in Git?

Since GitOps requires that the entire state is in Git, passwords and API keys should never be stored in plain text. In professional setups (like in the Ayedo stack), this is solved with additional tools: either through Sealed Secrets (encryption that only the cluster can decrypt) or the External Secrets Operator (synchronization from an external vault like HashiCorp Vault). ArgoCD then manages only the encrypted references, not the secrets themselves.

Does ArgoCD replace my existing CI tool (Jenkins, GitLab CI)?

No, it complements it. ArgoCD is solely responsible for Continuous Delivery (CD). Your CI tool (e.g., Jenkins) still builds the images and runs tests. At the end of the pipeline, Jenkins no longer pushes to the cluster but merely updates the image version in the Git repository. ArgoCD detects this change and takes over the rollout. This creates a clean separation of responsibilities.

ArgoCD vs. Flux: What is the difference?

Both are CNCF-graduated GitOps tools. The main difference lies in operation and architecture: Flux is a pure CLI tool without a graphical interface, focused on automation. ArgoCD offers a powerful web UI that provides developers with visual feedback on deployment status. Due to the better “developer experience” and transparency, ArgoCD is often the preferred choice for platforms used by multiple teams.

What happens if Git and the cluster are not synchronized (drift)?

By default, ArgoCD only indicates that the application is “OutOfSync.” In production environments, however, Auto-Sync with Self-Heal is often enabled. In this mode, ArgoCD immediately overwrites any manual change in the cluster with the state from Git. This prevents “configuration drift” and ensures that the cluster always looks exactly as defined in the code.

Conclusion

ArgoCD is the technological answer to the complexity of modern microservices architectures. It enforces clean processes through GitOps and increases fault tolerance through automatic self-healing. While operating on pure hyperscaler clusters like EKS often leads to hidden dependencies, platforms like Ayedo offer a standardized GitOps stack. This guarantees companies the freedom to own their infrastructure, whether as a managed service or independently, without enforcing dependencies on a hyperscaler.