Deploying Helm Charts with Rancher’s Native GitOps – A Practical Guide

Problem: Manual Helm Deployments Slow Down Delivery

Teams that use Rancher to manage multiple Kubernetes clusters often end up running helm install or kubectl apply from a CI pipeline for every change. That approach requires a separate Git‑to‑cluster sync step, can lead to drift, and forces developers to remember the exact command syntax.

What if the cluster could watch a Git repository and apply changes automatically, without a separate ArgoCD or Flux installation?

Thesis: Rancher 2.7+ Ships a Built‑In GitOps Controller

Starting with Rancher 2.7, the upstream Community Edition includes a native GitOps controller. It watches Git repositories, applies Helm charts or plain manifests to the target namespace, and reports status back to the Rancher UI. This eliminates the need for an external GitOps tool and keeps the entire workflow inside Rancher.

Enabling GitOps in Rancher

1. Navigate to Projects & Namespaces in the Rancher UI. Select the project you want to enable GitOps for.

2. Click the GitOps tab. If the tab is absent, your Rancher version is older than 2.7 or the OEM build has disabled the feature.

3. Click Create GitOps. Provide a name and choose a Git provider (GitHub, GitLab, Bitbucket, or a generic HTTPS/SSH endpoint).

4. Authenticate Rancher to the Git provider. For GitHub, you’ll typically supply a Personal Access Token with repo and read:org scopes.

5. Define the repository path (e.g., https://github.com/yourorg/helm-charts.git) and the target namespace (e.g., test-app). The controller will create a GitOps custom resource (CR) that looks like this:

apiVersion: rancher.com/v1
kind: GitOps
metadata:
  name: my-app-gitops
spec:
  repo: https://github.com/yourorg/helm-charts.git
  path: charts/my-app
  branch: main
  targetNamespace: test-app
  provider: github
  auth: # token reference

When you click Save, Rancher creates a GitOps CR in the selected namespace. The controller watches the repo and syncs any changes to test-app.

Concrete Example: Deploying a Helm Chart

Assume you have a simple Helm chart in charts/my-app of the repository. The chart contains an app.yaml that defines a Deployment and Service. Follow these steps:

1. Commit the chart to the main branch and push to GitHub.

2. In Rancher, verify that the GitOps tab shows the status as Synced. If not, check:

   • RBAC: The GitOps service account must have edit rights on the target namespace.
   • Network: The cluster node running the GitOps controller must reach GitHub over HTTPS.

3. Make a change to values.yaml (e.g., bump image tag) and push again.

4. Observe the GitOps resource in the UI turning from Synced to Updating and back to Synced once the controller applies the new chart.

All of this happens without any CI/CD pipeline command. The GitOps controller uses kubectl apply under the hood, so the cluster sees the same declarative changes you would manually apply.

Trade‑Offs and Limitations

• Resource Footprint: The controller runs as a Deployment in the cattle-system namespace. It consumes CPU and memory proportional to the number of repos it watches. Monitor with kubectl top pod -n cattle-system and scale if necessary.
• RBAC Requirements: The service account used by the controller needs edit or higher permissions on every namespace it syncs. Granting too many permissions can increase risk.
• Secret Management: Secrets stored in the Git repo (e.g., DB passwords) are applied in plain text. Use Kubernetes Secrets or external secret managers instead.
• Feature Availability: Only the upstream Community Edition of Rancher 2.7+ includes this controller. Some OEM builds or older versions omit it.
• Rollback Behavior: The controller automatically rolls back to the last synced state if a sync fails, but it does not perform sophisticated canary or blue‑green strategies out of the box.

Actionable Checklist for Your Team

1. Verify you’re running Rancher 2.7+ and the GitOps tab is present.
2. Ensure the GitOps service account has the necessary RBAC in target namespaces.
3. Set up a dedicated namespace for GitOps resources to keep them isolated.
4. Use Git branches or tags to control promotion: sync dev to staging and release to production.
5. Monitor controller metrics and set alerts for sync failures.
6. Document the GitOps workflow and the required Git repo layout in your team’s onboarding guide.

With Rancher’s native GitOps, you can move from ad‑hoc Helm commands to a fully declarative, audit‑friendly deployment pipeline—all within the same dashboard you already use for cluster management.