Helm Chart Linter

A Helm chart is a package of pre-configured Kubernetes resources. It consists of templates (YAML files with Go template directives), a values.yaml file with default configuration, and a Chart.yaml metadata file. Helm renders templates with the provided values and applies the resulting manifests to your Kubernetes cluster. Charts enable repeatable, parameterized deployments and are the standard packaging format for Kubernetes applications.

Helm v3 removed Tiller (the in-cluster component) for improved security, and uses apiVersion: v2 in Chart.yaml. Key differences: v3 uses Kubernetes RBAC directly instead of Tiller's service account; chart dependencies moved from requirements.yaml into Chart.yaml; the 'type' field (application or library) was introduced in v2. If your Chart.yaml has apiVersion: v1, you're using a Helm 2 chart format. Upgrade to v2 for all new charts.

Helm requires semantic versioning (semver) for the 'version' field in Chart.yaml. The format is MAJOR.MINOR.PATCH (e.g. 1.2.3). MAJOR: breaking changes, MINOR: new features (backward-compatible), PATCH: bug fixes. The 'version' field tracks the chart version, while 'appVersion' tracks the version of the application the chart deploys. Always increment 'version' when you change the chart, even if the application version stays the same.

pullPolicy: Always forces Kubernetes to contact the registry and check for image updates on every Pod start. This adds latency to Pod startup, increases registry load, and can cause deployments to fail if the registry is temporarily unavailable. When using pinned image tags (like nginx:1.25.3), use pullPolicy: IfNotPresent — Kubernetes only pulls the image if it's not cached on the node. Use Always only with mutable tags like :latest where you explicitly want the newest version.

Never put actual secret values in values.yaml — these files are committed to version control. Instead, use placeholder values and override them at deploy time: helm upgrade --set db.password=$DB_PASSWORD my-release ./chart. For production, use external secret management: Helm Secrets plugin (with SOPS encryption), External Secrets Operator, or Vault Agent Injector. Reference secrets in templates using {{ .Values.db.password | b64enc | quote }} or mount Kubernetes Secrets created outside the chart.

Application charts (type: application) contain a complete, deployable set of Kubernetes resources. Library charts (type: library) contain reusable template helpers and partials that other charts can depend on — they don't deploy any resources directly. Library charts are useful for sharing common template logic (like labels, annotations, or naming conventions) across multiple application charts in a monorepo or organization.