Format a Helm Values File

Helm is the package manager for Kubernetes — it packages Kubernetes manifests as reusable charts and lets you customize deployments by providing values. The values.yaml file is the primary interface for configuring a Helm chart: it provides default values that users can override at install time without modifying the chart templates themselves. Understanding values file structure is essential for both chart users (who override defaults) and chart authors (who design the configurable interface). This example shows values for a typical web application chart covering the most commonly configured settings: replica count for high availability, image repository and tag for specifying which container to deploy, service type and port for network access, ingress configuration for external routing, resource requests and limits for Kubernetes scheduling, and autoscaling settings. How values override works: when you run helm install or helm upgrade, Helm merges your values.yaml with the chart's default values.yaml. Your values take precedence over defaults. You can also override individual values on the command line with --set replicaCount=5 or supply a completely different values file with -f custom-values.yaml. This layered override system lets you maintain environment-specific values files (values-dev.yaml, values-prod.yaml) that override only the settings that differ between environments. Image tag quoting is important: YAML treats unquoted values like 1.5.0 as floats and values like latest as strings, but some tags like 20240101 look like integers. Always quote image tags to be safe, as shown in this example with tag: "1.5.0". The autoscaling block shows a common pattern: when enabled is false, the HPA (Horizontal Pod Autoscaler) is not created and replicaCount controls the deployment. When enabled is true, the HPA manages the replica count between minReplicas and maxReplicas based on CPU or memory metrics. The chart template uses an if block to conditionally include the HPA manifest. Real-world scenarios: a platform engineering team maintains a single internal chart and provides environment-specific values files for each team's services; a third-party chart requires customizing just the image repository and ingress host while using chart defaults for everything else. Tips: use helm template to render the manifests with your values without connecting to a cluster — this lets you verify the rendered YAML before applying it, catching values that produce invalid or unintended configurations.

replicaCount: 2

image:
  repository: myregistry.io/myapp
  tag: "1.5.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  host: api.example.com
  tls: true

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

autoscaling:
  enabled: false
  minReplicas: 2
  maxReplicas: 10