Helm + Kustomize together — combining the tools safely

Combining Helm and Kustomize is a common production pattern. This lesson walks the hybrid, the boundaries, the conflicts to avoid, and the operational discipline.

The hybrid pattern

flowchart LR
    A[Production deployment] --> B["Helm: platform packages"]
    A --> C["Kustomize: application manifests"]
    B --> B1[ingress-nginx]
    B --> B2[cert-manager]
    B --> B3[Argo CD]
    B --> B4[Prometheus]
    C --> C1["base/"]
    C --> C2["overlays/dev/"]
    C --> C3["overlays/staging/"]
    C --> C4["overlays/prod/"]

The hybrid: Helm for platform packages, Kustomize for application manifests with environment overlays.

• Helm manages platform packages (ingress-nginx, cert-manager, Argo CD, monitoring stack). These are complex third-party packages with templated configuration.
• Kustomize manages application manifests with environment overlays. The base is the application; overlays add environment-specific configuration.

The integration via Argo CD

flowchart LR
    A[Argo CD] --> B["Helm source: ingress-nginx chart"]
    A --> C["Kustomize source: apps/myapp overlay"]
    B --> D[Cluster]
    C --> D

Argo CD supports both Helm and Kustomize sources:

# Platform: Helm source
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ingress-nginx
spec:
  source:
    repoURL: https://kubernetes.github.io/ingress-nginx
    chart: ingress-nginx
    helm:
      valueFiles:
        - values-prod.yaml

---
# Applications: Kustomize source
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  source:
    repoURL: https://github.com/example/manifests
    path: overlays/prod

The same GitOps controller manages both. The discipline is consistency: same review process, same deployment pipeline, same monitoring.

Boundaries

flowchart LR
    A[Helm] -->|owns| B[Platform packages]
    C[Kustomize] -->|owns| D[Application manifests]
    B -.->|no overlap| D

The boundaries:

• Helm owns: Platform packages (ingress-nginx, cert-manager, Argo CD, monitoring).
• Kustomize owns: Application manifests (Deployments, Services, ConfigMaps for the application’s own code).

A resource is owned by exactly one tool. The boundaries are documented in the runbook.

Conflicts to avoid

flowchart TD
    A[Conflict types] --> B["Same resource, both tools"]
    B --> C[Kustomize overlay patches a Helm-managed resource]
    C --> D["Drift detected, both tools revert each other"]
    D --> E[Loop]

The conflict scenarios:

• Same resource managed by both tools. Helm manages the resource; Kustomize patches it; both try to revert each other.
• Kustomize overlay patches a Helm-managed resource. The overlay applies changes; the next helm upgrade reverts them.

The discipline is to define ownership clearly and to not patch resources across the boundary.

Quiz

The operational discipline

Helm + Kustomize in production rests on five non-negotiable elements:

• Define ownership clearly. Each resource is owned by exactly one tool.
• No overlapping patches. Patches stay within the tool’s boundary.
• Consistent review process. All changes go through GitOps with PR review.
• Single deployment pipeline. Argo CD or Flux manages both.
• Document the boundary. The runbook lists which tool owns which resource.

The discipline is to treat the hybrid as a single configuration system with clear boundaries. Overlap is the failure mode; clarity is the fix.