home / skills / eyadsibai / ltk / helm-charts

This skill helps you create, configure, and deploy Helm charts for Kubernetes applications across environments.

npx playbooks add skill eyadsibai/ltk --skill helm-charts

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.5 KB
---
name: helm-charts
description: Use when creating Helm charts, packaging Kubernetes applications, managing multi-environment deployments, or asking about "Helm", "Helm chart", "values.yaml", "chart templating", "Helm dependencies"
version: 1.0.0
---

# Helm Chart Development

Create, organize, and manage Helm charts for Kubernetes applications.

## Chart Structure

```
my-app/
├── Chart.yaml           # Chart metadata
├── values.yaml          # Default values
├── charts/              # Dependencies
├── templates/
│   ├── NOTES.txt        # Post-install notes
│   ├── _helpers.tpl     # Template helpers
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
└── .helmignore
```

## Chart.yaml

```yaml
apiVersion: v2
name: my-app
description: A Helm chart for My Application
version: 1.0.0
appVersion: "2.1.0"

dependencies:
  - name: postgresql
    version: "12.0.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
```

## values.yaml Structure

```yaml
image:
  repository: myapp
  tag: "1.0.0"
  pullPolicy: IfNotPresent

replicaCount: 3

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  hosts:
    - host: app.example.com
      paths:
        - path: /
          pathType: Prefix

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

autoscaling:
  enabled: false
  minReplicas: 2
  maxReplicas: 10
```

## Template Helpers (_helpers.tpl)

```yaml
{{- define "my-app.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-app.labels" -}}
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version }}
app.kubernetes.io/name: {{ include "my-app.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}
```

## Deployment Template

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-app.fullname" . }}
  labels:
    {{- include "my-app.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "my-app.selectorLabels" . | nindent 6 }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        resources:
          {{- toYaml .Values.resources | nindent 12 }}
```

## Multi-Environment Configuration

```
my-app/
├── values.yaml          # Defaults
├── values-dev.yaml      # Development
├── values-staging.yaml  # Staging
└── values-prod.yaml     # Production
```

Install with environment:

```bash
helm install my-app ./my-app -f values-prod.yaml -n production
```

## Common Patterns

### Conditional Resources

```yaml
{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
...
{{- end }}
```

### Iterating Lists

```yaml
env:
{{- range .Values.env }}
- name: {{ .name }}
  value: {{ .value | quote }}
{{- end }}
```

## Validation Commands

```bash
helm lint my-app/
helm template my-app ./my-app --dry-run
helm install my-app ./my-app --dry-run --debug
```

## Best Practices

1. Use semantic versioning
2. Document all values with comments
3. Use template helpers for repeated logic
4. Pin dependency versions explicitly
5. Include NOTES.txt with usage instructions
6. Add labels consistently
7. Test in all environments

Overview

This skill helps you create, organize, and maintain Helm charts for Kubernetes applications. It focuses on chart structure, values management, templating patterns, multi-environment deployments, and dependency handling. Use it to produce consistent, versioned charts that are safe to deploy across dev, staging, and production.

How this skill works

The skill inspects common chart files (Chart.yaml, values.yaml, templates/, charts/) and suggests structure and content that follow Helm best practices. It explains template helpers, conditional rendering, list iteration, and how to wire values into manifests. It also guides packaging, linting, dry-run validation, and environment-specific value overrides for safe releases.

When to use it

  • When creating a new Helm chart for an application
  • When refactoring templates to remove duplication and improve maintainability
  • When packaging or publishing charts with pinned dependencies
  • When managing multi-environment deployments with separate values files
  • When validating templates and performing dry-run installs before production

Best practices

  • Follow Chart.yaml v2 and semantic versioning for chart and appVersion
  • Document all values in values.yaml with clear comments and sensible defaults
  • Use _helpers.tpl for repeated labels, names, and selectors to avoid duplication
  • Pin dependency versions and use conditions/requirements to control subcharts
  • Keep environment overrides in values-<env>.yaml and install with -f per environment
  • Run helm lint, helm template --dry-run, and helm install --dry-run --debug before real installs

Example use cases

  • Create a chart with Chart.yaml, values.yaml, templates/, and .helmignore following the standard layout
  • Add a helper that generates a trimmed fullname and use it across Deployment and Service manifests
  • Implement conditional Ingress resources driven by values.ingress.enabled
  • Manage dev/staging/prod by maintaining values-dev.yaml, values-staging.yaml, values-prod.yaml and installing with -f
  • Iterate environment variables or ports using range over lists in values.yaml to keep templates generic

FAQ

How do I manage different settings for dev and prod?

Keep defaults in values.yaml and create values-dev.yaml and values-prod.yaml. Install with helm install -f values-prod.yaml to override defaults per environment.

When should I use a helper in _helpers.tpl?

Use helpers for any repeated logic: names, labels, selectors, or complex template expressions to ensure consistency and reduce duplication.