The GitOps Solution: Automating K8s Deployments with ArgoCD and Helm

You’ve become your team’s “Kubernetes person” almost by accident. What started as curiosity has turned into full responsibility for your organization’s K8s infrastructure. Now you’re drowning in YAML files, fielding urgent Slack messages about deployment issues, and nervously checking your phone during vacations because “if this goes down while I’m away, the team is completely screwed.”

Sound familiar? You’re not alone. Across Reddit and tech forums, the sentiment echoes: “I’m the only person on my team that seems to understand how it works. As a result, I’m expected to do everything.”

This article introduces a better way forward: GitOps with ArgoCD and Helm. This approach doesn’t just solve technical challenges—it addresses the human ones too, transforming you from an overwhelmed bottleneck into an empowered platform enabler.

What is GitOps? (And Why You Need It)

GitOps is a set of practices for managing infrastructure and application configurations using Git as the single source of truth. According to Red Hat, GitOps builds upon these core principles:

1. Declarative Configuration: Your entire system is described as code, specifying the desired state rather than the steps to achieve it.
2. Version Controlled: All configurations live in Git, providing complete history, rollback capabilities, and collaboration tools.
3. Automated and Self-Healing: An operator (like ArgoCD) continuously monitors the actual state and reconciles it with the desired state defined in Git.

These principles translate into tangible benefits that directly address the “sole K8s expert” pain points:

• Standardized Workflow & Reduced Toil: Developers can self-serve by submitting pull requests, freeing you from manual deployments.
• Enhanced Security & Auditability: Every change is a logged Git commit, creating a comprehensive audit trail.
• Improved Reliability & Easy Rollback: When something goes wrong, reverting to a previous known-good state is as simple as reverting a commit.
• Consistency Across Environments: Your development, staging, and production environments stay in sync through the same configuration files.

In essence, GitOps transforms the “you need to deploy this now” emergency into a structured, reviewable pull request that empowers the entire team.

The Tools of the Trade: ArgoCD and Helm

To implement GitOps effectively in a Kubernetes environment, you’ll need two key tools:

Helm: The Kubernetes Package Manager

Helm serves as the package manager for Kubernetes, simplifying the deployment of complex applications through:

• Charts: Reusable packages containing all the resources needed to deploy an application
• Values Files: YAML files that allow you to customize chart parameters without modifying the chart itself
• Templates: Parameterized Kubernetes manifests that generate the final resources

Helm brings the familiarity of package managers like apt or npm to Kubernetes, making it easier to share and reuse configurations.

ArgoCD: The GitOps Continuous Delivery Tool

ArgoCD is the engine that powers the GitOps workflow by:

• Continuously monitoring both your Git repositories and your Kubernetes clusters
• Automatically detecting when they drift out of sync
• Applying changes to bring the actual state in line with the desired state

ArgoCD’s key features include:

• Automated Synchronization: Changes pushed to Git automatically deploy to your cluster
• Self-Healing Capabilities: Reverts unauthorized manual changes to maintain the desired state
• Web UI for Visibility: Provides a dashboard showing sync status and deployment history
• Support for Multiple Templating Tools: Works with Helm, Kustomize, and Jsonnet

How-To: Practical Patterns for Deploying Helm Charts with ArgoCD

Let’s get practical and explore how to set up GitOps with ArgoCD and Helm. At the core of this setup is the ArgoCD Application manifest—a Kubernetes custom resource that defines what to deploy and where.

Here’s a basic example:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sealed-secrets
  namespace: argocd
spec:
  project: default
  source:
    chart: sealed-secrets
    repoURL: https://bitnami-labs.github.io/sealed-secrets
    targetRevision: 1.16.1
    helm:
      releaseName: sealed-secrets
  destination:
    server: "https://kubernetes.default.svc"
    namespace: kubeseal

This simple YAML file tells ArgoCD to deploy the sealed-secrets Helm chart from the Bitnami repository to your cluster. Let’s explore the three main patterns for deploying Helm charts with ArgoCD, as identified by Red Hat Developers.

Pattern 1: Pointing to a Helm Chart in a Helm Repository

This is the simplest approach, as shown in the example above. The ArgoCD Application points directly to a chart in a Helm repository.

Advantages:

• Extremely simple to set up
• Great for beginners
• ArgoCD UI auto-populates default parameters

Disadvantages:

• Difficult to troubleshoot locally with helm template
• Customization is limited by the chart’s design

Best For: Deploying well-maintained third-party charts with minimal configuration changes, like Prometheus or Nginx Ingress.

Pattern 2: Pointing to a Helm Chart in a Git Repository

In this pattern, you store the Helm chart in your Git repository, and ArgoCD points to it:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-repo.git
    path: charts/my-app
    targetRevision: HEAD
    helm:
      releaseName: my-app
  destination:
    server: "https://kubernetes.default.svc"
    namespace: my-app

Advantages:

• Full version control over the chart itself
• Enables local testing with helm template and helm lint
• Simplifies managing chart lifecycles

Disadvantages:

• Can clutter the repository with Helm-specific files
• Requires more Git operations for chart updates

Best For: Custom-developed applications or when you need to heavily customize a third-party chart.

Pattern 3: Using Kustomize to Render a Helm Chart

This advanced pattern combines Kustomize and Helm. The ArgoCD Application points to a directory with a kustomization.yaml file, which in turn specifies the Helm chart details:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-repo.git
    path: kustomize/my-app
    targetRevision: HEAD
  destination:
    server: "https://kubernetes.default.svc"
    namespace: my-app

With a corresponding kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: redis
  repo: https://charts.bitnami.com/bitnami
  version: 17.3.14
  releaseName: redis
  namespace: redis

Advantages:

• Unlocks Kustomize’s powerful patching capabilities
• Maintains consistency in a Kustomize-centric environment
• Allows for post-rendering modifications

Disadvantages:

• Adds complexity for troubleshooting
• Requires enabling the --enable-helm flag in ArgoCD

Best For: Teams already invested in Kustomize who need to patch objects generated by Helm charts.

Advanced Configuration and Best Practices

Mastering Helm Values in ArgoCD

ArgoCD offers several methods for passing configuration values to Helm charts, with a strict precedence order:

1. parameters via argocd app set (highest priority)
2. valuesObject key in the spec.source.helm block
3. values key (a multi-line string) in the spec.source.helm block
4. valueFiles list in the spec.source.helm block
5. The chart’s default values.yaml file (lowest priority)

For environment-specific configurations, the valueFiles approach works well:

spec:
  source:
    helm:
      valueFiles:
      - values.yaml
      - values-production.yaml

Scaling with the “App of Apps” Pattern

As your deployment grows, managing dozens of Application manifests becomes unwieldy. The “App of Apps” pattern solves this by creating a hierarchy:

1. Create a root ArgoCD Application that points to a directory of other Application manifests
2. These child Applications each manage actual applications or services

This pattern, exemplified in the argocd-example-apps repository, provides structure and organization for complex deployments across multiple clusters or environments.

From Kubernetes Hero to GitOps Enabler

GitOps with ArgoCD and Helm transforms your role from the overburdened Kubernetes expert to a platform enabler who builds the “paved road” for developers. Instead of being the bottleneck for every deployment, you create a system where:

• Developers deploy through pull requests, not by asking you
• Changes are automatically applied and verified
• The system is self-healing, reducing late-night emergencies
• Everything is auditable and reversible

As one Reddit user wisely suggested, “automate the deployment of manifests to K8s in a way that devs can get manifests into clusters easily on a git merge.” This is exactly what the GitOps approach achieves.

Remember to “keep it simple to start.” Begin with one application and one deployment pattern, then iterate as your comfort and needs grow. The goal is a manageable system that reduces your stress, not a perfect but overly complex one.

By implementing GitOps with ArgoCD and Helm, you’re not just solving a technical problem—you’re addressing the very real human challenge of being the lone Kubernetes expert. And perhaps most importantly, you might finally be able to take that vacation without checking your phone every hour.

Frequently Asked Questions

What is GitOps and why is it important for Kubernetes management?

GitOps is a methodology for managing Kubernetes infrastructure and applications where Git is the single source of truth for declarative configuration. It’s important because it automates deployments, improves reliability, and enhances security by treating infrastructure as code. This approach transforms manual, error-prone deployment processes into a standardized, auditable workflow. By using pull requests to manage changes, it empowers developers to self-serve while maintaining control and visibility, directly addressing the “sole Kubernetes expert” bottleneck.

How do ArgoCD and Helm work together in a GitOps workflow?

Helm packages Kubernetes applications into reusable charts, while ArgoCD acts as the GitOps operator that automatically deploys and synchronizes these charts with the cluster. Helm simplifies the definition and configuration of your applications. ArgoCD then continuously monitors your Git repository for changes to these Helm charts and their values. When a change is detected, ArgoCD automatically applies it to the cluster, ensuring the live state always matches the desired state defined in Git.

What is the best pattern for deploying Helm charts with ArgoCD?

There is no single “best” pattern; the right choice depends on your specific use case. The article outlines three common patterns: pointing to a Helm repository, pointing to a chart in a Git repository, or using Kustomize to render a Helm chart. For simple, third-party applications, pointing directly to a Helm repository is easiest. For custom applications requiring heavy modification, storing the chart in your own Git repository provides more control. For teams already using Kustomize who need advanced patching, the Kustomize pattern is most effective.

How should I manage secrets like passwords and API keys in a GitOps repository?

You should never store plain-text secrets in a Git repository. A common and secure practice is to use a tool like Sealed Secrets, which encrypts your Kubernetes Secrets so they can be safely committed to Git. Sealed Secrets works by providing a public key that you use to encrypt your secrets before committing them. A controller running in your cluster holds the private key and is the only entity that can decrypt them, allowing you to manage secrets declaratively without compromising security.

What happens if a bad configuration is merged into the main branch?

One of the core benefits of GitOps is the ability to quickly and easily roll back to a previous known-good state. Since every change is a commit in Git, rolling back is as simple as reverting the problematic commit. Once you revert the commit, ArgoCD will detect the change and automatically synchronize the cluster back to the previous stable configuration. This provides a powerful safety net, making deployments less risky and reducing recovery time when issues occur.

Does GitOps replace my existing CI/CD pipeline?

GitOps is focused on continuous delivery (CD)—the deployment part of the process—and is designed to complement your existing continuous integration (CI) pipeline, not replace it entirely. Your CI pipeline (e.g., Jenkins, GitHub Actions) is still responsible for building, testing, and packaging your application (e.g., creating a Docker image). Once a new image is ready, the CI process can update a configuration file in your Git repository, which then triggers the GitOps CD workflow managed by ArgoCD to deploy the new version.