Home
Kubernetes Helm Chart
DevOps & Cloud-Native Utilities

Kubernetes Helm Chart (Chart.yaml & values.yaml) Generator

Generate standard Kubernetes Helm v3 Chart.yaml, values.yaml, and deployment templates with service, ingress, and resource limits.

100% Client-Side Privacy
Helm v3 Specification
Quick Presets:
Chart Configuration & Values
Chart.yaml Metadata
Workload, Replicas & Container Image
Networking: Service & Ingress
Compute Resources & HPA Autoscaling
Security Hardening & Health Probes
Environment Variables (3)
1# Default values for web-api-service.
2# This is a YAML-formatted file.
3# Declare variables to be passed into your templates.
4
5replicaCount: 3
6
7image:
8 repository: ghcr.io/org/api-service
9 pullPolicy: IfNotPresent
10 # Overrides the image tag whose default is the chart appVersion.
11 tag: "v1.4.2"
12
13imagePullSecrets: []
14nameOverride: ""
15fullnameOverride: ""
16
17serviceAccount:
18 # Specifies whether a service account should be created
19 create: true
20 # Automatically mount a ServiceAccount's API credentials?
21 automount: true
22 # Annotations to add to the service account
23 annotations: {}
24 # The name of the service account to use.
25 # If not set and create is true, a name is generated using the fullname template
26 name: ""
27
28podAnnotations: {}
29podLabels: {}
30
31podSecurityContext:
32 fsGroup: 2000
33
34securityContext:
35 capabilities:
36 drop:
37 - ALL
38 readOnlyRootFilesystem: true
39 runAsNonRoot: true
40 runAsUser: 1000
41
42service:
43 type: ClusterIP
44 port: 80
45 targetPort: 8080
46
47ingress:
48 enabled: true
49 className: "nginx"
50 annotations:
51 cert-manager.io/cluster-issuer: letsencrypt-prod
52 nginx.ingress.kubernetes.io/ssl-redirect: "true"
53 hosts:
54 - host: api.example.com
55 paths:
56 - path: /
57 pathType: ImplementationSpecific
58 tls:
59 - secretName: api-example-tls
60 hosts:
61 - api.example.com
62
63resources:
64 limits:
65 cpu: 500m
66 memory: 512Mi
67 requests:
68 cpu: 100m
69 memory: 128Mi
70
71autoscaling:
72 enabled: true
73 minReplicas: 2
74 maxReplicas: 10
75 targetCPUUtilizationPercentage: 80
76 targetMemoryUtilizationPercentage: 80
77
78livenessProbe:
79 httpGet:
80 path: /healthz
81 port: http
82 initialDelaySeconds: 15
83 periodSeconds: 20
84
85readinessProbe:
86 httpGet:
87 path: /ready
88 port: http
89 initialDelaySeconds: 5
90 periodSeconds: 10
91
92env:
93 - name: NODE_ENV
94 value: "production"
95 - name: PORT
96 value: "8080"
97 - name: LOG_LEVEL
98 value: "info"
99
100envFrom: []
101volumes: []
102volumeMounts: []
103nodeSelector: {}
104tolerations: []
105affinity: {}
Chart Structure
web-api-service (0.1.0)
Helm v3 • 8 Manifests Generated • App 1.4.2
Workload & Network
3 Pods • ClusterIP
Port 80:8080 • Ingress: Active
Security Hardening
100/100Hardened
Non-Root • Probes Active

100% Client-Side Helm Generation

Synthesize valid Helm v3 charts, Chart.yaml metadata, values.yaml configurations, and Go template manifests entirely in your browser without sending internal infrastructure secrets or cluster details to external servers.

Production-Hardened Kubernetes Defaults

Includes non-root container security contexts, drop-all Linux capabilities, HTTP liveness/readiness health probes, resource requests and limits, and Horizontal Pod Autoscaling (HPA) specifications.

Full Helm v3 Template Compatibility

Standard _helpers.tpl naming definitions, DNS-safe truncations (63 chars), dynamic ingress rules, service bindings, and ready-to-run helm lint and install bash automation scripts.

Technical Reference & Architecture Guide

Kubernetes Helm Chart (Chart.yaml & values.yaml) Generator — Reference Guide

Generate standard Kubernetes Helm v3 Chart.yaml, values.yaml, and deployment templates with service, ingress, and resource limits.

Key Parameters & Controls

namestring

Chart package name adhering to Kubernetes RFC 1123 DNS subdomain specifications (lowercase alphanumeric and hyphens).

Default: my-app
apiVersionstring

Helm chart API schema version. Helm v3 requires 'v2', whereas deprecated Helm v2 used 'v1'.

Default: v2
versionstring

SemVer 2 compliant chart release version. Must increment with any template or values change.

Default: 0.1.0
appVersionstring

Version string indicating the underlying application or workload container image tag.

Default: 1.0.0
replicaCountinteger

Desired number of pod replicas scheduled across cluster worker nodes.

Default: 2
image.repositorystring

Container image registry path and repository name (e.g., docker.io/library/nginx or gcr.io/project/service).

Default: nginx
service.typestring

Kubernetes Service exposure strategy: ClusterIP (internal), NodePort, or LoadBalancer (cloud provider external IP).

Default: ClusterIP
resourcesobject

Compute resource reservations (requests) and ceilings (limits) for CPU (millicores) and RAM (Mi/Gi).

Default: requests: { cpu: 100m, memory: 128Mi }, limits: { cpu: 500m, memory: 512Mi }

Pro Tips & Best Practices

Always execute 'helm lint ./my-chart'

Always execute 'helm lint ./my-chart' and 'helm template my-release ./my-chart --debug' before deploying to detect syntax bugs and Go template rendering regressions without touching the Kubernetes cluster API.

Maintain strict separation between

Maintain strict separation between the chart's 'version' in Chart.yaml and the 'appVersion'. Changing helper templates or default resource requests warrants a chart patch or minor version bump even if the underlying workload image tag remains identical.

Never omit pod resources

Never omit pod resources in values.yaml. Accurate CPU/memory requests allow the kube-scheduler to make informed bin-packing decisions, while limits prevent memory leaks from starving neighbor containers on shared nodes.

Configure ingress.annotations

Configure ingress.annotations with 'cert-manager.io/cluster-issuer: letsencrypt-prod' and define ingress.tls hosts to automatically provision and rotate X.509 SSL certificates via cert-manager.

Common Gotchas & Troubleshooting

Helm install fails with 'cannot re-use a name that is still in use'

An earlier failed installation left an orphaned Helm release secret in the namespace. Either use 'helm upgrade --install <release-name> <chart>' to perform an idempotent rollout, or run 'helm uninstall <release-name>' followed by 'kubectl delete secret -l name=<release-name>'.

Upgrade rejected with 'field is immutable' on Deployment selector

Kubernetes spec.selector labels on Deployments cannot be mutated after initial creation. Ensure your chart's matchLabels templates use immutable identifiers like 'app.kubernetes.io/name', or perform a controlled rollout by deleting the old deployment manifest before upgrading.

Pods stuck in CrashLoopBackOff or OOMKilled immediately after deployment

The application either exceeds the memory limit or fails container health checks. Increase 'resources.limits.memory' in values.yaml and verify that liveness/readiness probes have adequate initialDelaySeconds (e.g., 15-30s) to accommodate JVM or runtime initialization.

Frequently Asked Questions

What is the structural difference between Chart.yaml and values.yaml?▼

Chart.yaml contains high-level package metadata consumed by Helm (such as chart name, schema version, dependencies, and SemVer tags). values.yaml defines the configurable parameters and default inputs that feed into the Go templates located under the templates/ directory to generate raw Kubernetes YAML manifests.

Why does Helm v3 require apiVersion: v2 in Chart.yaml?▼

Helm v3 transitioned the chart API version from 'v1' to 'v2' to reflect the architectural removal of Tiller (the in-cluster server-side daemon), chart dependency management restructuring (moving 'requirements.yaml' directly into Chart.yaml 'dependencies'), and native OCI registry support.

How should sensitive production secrets and credentials be handled?▼

Avoid committing plaintext passwords or API keys to values.yaml. Instead, inject sensitive credentials using external operators such as External Secrets Operator (integrating with AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager), Sealed Secrets, or by referencing pre-existing Kubernetes Secret resources via 'existingSecret' values overrides.

What is the precedence hierarchy when overriding Helm values?▼

Helm merges configurations in a strict precedence hierarchy: default values in values.yaml have the lowest priority, followed by custom values files passed via '-f / --values' in the order specified on the command line, and finally individual parameters supplied via '--set' or '--set-string' which hold the highest evaluation priority.

Related Tools & Utilities

All Tools →