Deploy an application with Kustomize

Kustomize adapts plain YAML to each environment without a template language. There are no {{ }} placeholders, and there is nothing to install: it ships inside kubectl and runs as apply -k, so your manifests stay valid YAML you can read and apply on their own. Use it when Helm's templating is more than you need and your environments (dev, staging, prod) differ in only a handful of fields.

Base and overlays 

One base holds the real manifests; one overlay per environment patches what differs.

				app/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/kustomization.yaml
    prod/kustomization.yaml
			

The base's kustomization.yaml lists its resources. Each overlay points back at the base and layers the environment on top:

				resources:
  - ../../base
namePrefix: prod-
images:
  - name: your/app
    newTag: "1.4.0" # prod pins a released tag
patches:
  - path: replicas.yaml # prod runs more replicas per pool
  - path: lb-location.yaml # place the LoadBalancer in Falkenstein
  - path: storage-class.yaml # bind PVCs to local-nvme
			

The last two patches hold the cluster-specific settings: lb-location.yaml sets load-balancer.hetzner.cloud/location: fsn1 on the Service, and storage-class.yaml points the PersistentVolumeClaims at local-nvme. Keep these in the overlay rather than the base, so each environment can use different values. Apply the overlay with kubectl apply -k overlays/prod, but render it first: kubectl kustomize overlays/prod | less shows the exact YAML before it reaches the cluster, which catches most mistakes.

What an overlay can change 

• images swaps a tag per environment: prod pins a release, staging tracks latest.
• namePrefix / nameSuffix and namespace keep each environment's objects distinct.
• patches rewrite any field (replica count, resource requests, an env var, a LoadBalancer annotation) as a strategic-merge or JSON patch.
• configMapGenerator / secretGenerator build config from files or literals and hash the name, so editing the content changes the name and the rollout happens on its own. That is the same trick a checksum annotation does by hand, done for you.

Helm or Kustomize 

Both parameterize manifests; they start from opposite ends. Use Kustomize to adapt manifests you already own, layering small per-environment differences over a shared base in plain YAML. Use Helm to install and version packaged software, especially third-party charts. Many teams run both: Helm for off-the-shelf components, Kustomize for their own manifests, and let Argo CD render either straight from Git so a merged pull request is the deploy.