write-helm-chart
정보
이 스킬은 템플릿, 값 관리, 의존성 처리를 통해 Kubernetes 애플리케이션을 패키징하기 위한 프로덕션 준비가 완료된 Helm 차트를 생성합니다. 차트 구조, Go 템플릿, 버전 관리, 유지보수 가능한 배포를 위한 모범 사례를 다룹니다. 여러 환경에 대한 매니페스트를 매개변수화하거나 표준화된 버전 관리 롤백으로 복잡한 애플리케이션을 관리하는 데 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/write-helm-chartClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Write Helm Chart
Create production-ready Helm charts for deploying applications to Kubernetes.
Cuándo Usar
- Need to package Kubernetes application for repeatable deployments
- Want to parameterize manifests for different environments (dev/staging/prod)
- Managing complex multi-component applications with dependencies
- Sharing reusable deployment patterns across teams or organizations
- Implementing versioned application releases with rollback capability
- Need template-based configuration management for Kubernetes resources
- Want to standardize deployment practices across projects
Entradas
- Requerido: Kubernetes manifests for your application (deployment, service, etc.)
- Requerido: Application name and version
- Requerido: List of configurable parameters (image tag, replicas, resources, etc.)
- Opcional: Dependencies on other Helm charts (databases, message queues)
- Opcional: Pre/post-install hooks for migrations or setup
- Opcional: Chart repository URL for publishing
- Opcional: Values for different environments
Procedimiento
See Extended Examples for complete template files, values structures, and hooks.
Paso 1: Initialize Chart Structure and Metadata
Create the Helm chart directory structure and define chart metadata.
Install Helm:
# Linux
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# macOS
brew install helm
# Windows (Chocolatey)
choco install kubernetes-helm
# Verify installation
helm version
Create chart structure:
# Create new chart
helm create my-app
# Chart structure created:
# my-app/
# Chart.yaml # Chart metadata
# values.yaml # Default configuration values
# charts/ # Chart dependencies
# templates/ # Template files
# deployment.yaml
# service.yaml
# ingress.yaml
# _helpers.tpl # Template helpers
# NOTES.txt # Post-install notes
# .helmignore # Files to ignore
# Or create from scratch
mkdir -p my-app/{templates,charts}
cd my-app
Define Chart.yaml:
# Chart.yaml (excerpt - see EXAMPLES.md for complete file)
apiVersion: v2
name: my-app
description: A Helm chart for deploying my-app to Kubernetes
version: 0.1.0
appVersion: "1.0.0"
maintainers:
- name: Platform Team
email: [email protected]
# ... (keywords, dependencies, kubeVersion - see EXAMPLES.md)
Create .helmignore:
# .helmignore
# Patterns to ignore when packaging chart
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
*.swp
*.bak
*.tmp
*.orig
*~
.DS_Store
.project
.idea/
*.tmproj
.vscode/
Esperado: Chart directory structure created with all required files. Chart.yaml contains complete metadata. Dependencies listed if applicable. Chart validates: helm lint my-app.
En caso de fallo:
- Check YAML syntax in Chart.yaml:
helm lint my-app - Verify apiVersion is v2 (v1 deprecated)
- Ensure version follows SemVer (x.y.z)
- Check dependency repository URLs are reachable
- Use
helm show chart <chart>to inspect existing charts for examples
Paso 2: Design values.yaml Structure
Create well-organized values.yaml with sensible defaults and documentation.
Create comprehensive values.yaml:
# values.yaml (excerpt - see EXAMPLES.md for complete structure)
global:
imageRegistry: ""
image:
registry: docker.io
repository: mycompany/my-app
tag: ""
replicaCount: 3
service:
type: ClusterIP
port: 80
resources:
limits: {cpu: 1000m, memory: 512Mi}
requests: {cpu: 100m, memory: 128Mi}
# ... (ingress, autoscaling, probes, persistence - see EXAMPLES.md)
See EXAMPLES.md for the complete values.yaml structure and values.schema.json
Esperado: values.yaml organized logically with sections. All values documented with comments. Sensible defaults that work out-of-box. Schema validates value types. No hardcoded environment-specific values.
En caso de fallo:
- Validate YAML syntax:
yamllint values.yaml - Check schema validation:
helm lint my-app - Review against Helm best practices:
helm lint --strict my-app - Ensure all template references have corresponding values
- Test with minimal values:
helm template my-app --set image.repository=test
Paso 3: Create Template Files with Go Templating
Write Kubernetes resource templates using Go template syntax and Helm functions.
Create deployment template:
# templates/deployment.yaml (excerpt)
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-app.fullname" . }}
labels:
{{- include "my-app.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
# ... (see EXAMPLES.md for complete template with probes, volumes, etc.)
See EXAMPLES.md for the complete deployment template
Create helper template file:
# templates/_helpers.tpl (excerpt)
{{- define "my-app.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- 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 }}
# ... (labels, serviceAccountName, hpa.apiVersion - see EXAMPLES.md)
Create conditional templates:
# templates/ingress.yaml (excerpt)
{{- if .Values.ingress.enabled -}}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ include "my-app.fullname" . }}
# ... (see EXAMPLES.md for complete ingress and HPA templates)
See EXAMPLES.md for complete _helpers.tpl and conditional templates
Esperado: Templates generate valid Kubernetes YAML. Conditionals work correctly (if/with). Helper functions produce expected output. Resources properly labeled and named. No hardcoded values in templates.
En caso de fallo:
- Test template rendering:
helm template my-app - Check for template syntax errors:
helm lint my-app - Validate Go template syntax carefully (dashes, spaces matter)
- Use
helm template --debugfor detailed error messages - Test with different values files:
helm template my-app -f values-prod.yaml - Verify output is valid Kubernetes YAML:
helm template my-app | kubectl apply --dry-run=client -f -
Paso 4: Add Hooks for Pre/Post-Install Actions
Create hooks for database migrations, setup tasks, or cleanup.
Create pre-install hook for migrations:
# templates/hooks/pre-install-migration.yaml (excerpt)
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "my-app.fullname" . }}-migration
annotations:
"helm.sh/hook": pre-install,pre-upgrade
"helm.sh/hook-weight": "-5"
spec:
template:
spec:
containers:
- name: migration
image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"
command: ["/app/migrate"]
# ... (see EXAMPLES.md for test hook, pre-delete backup, NOTES.txt)
See EXAMPLES.md for complete hook templates and NOTES.txt
Esperado: Hooks execute in correct order (weights determine sequence). Pre-install migration completes before deployment. Test hook validates deployment. Pre-delete hook runs cleanup. NOTES.txt provides helpful post-install information.
En caso de fallo:
- Check hook annotations syntax exactly matches Helm spec
- Verify hook jobs have
restartPolicy: Never - Review hook execution:
kubectl get jobs -n <namespace> - Check hook logs:
kubectl logs job/<job-name> -n <namespace> - Ensure hook-delete-policy appropriate (before-hook-creation, hook-succeeded, hook-failed)
- Test hooks independently:
helm install --dry-run --debug my-app
Paso 5: Test and Package Chart
Validate chart, run tests, and package for distribution.
Lint and validate chart:
# Basic linting
helm lint my-app
# Strict linting
helm lint --strict my-app
# Test template rendering
helm template my-app
# Test with custom values
helm template my-app -f values-prod.yaml
# Validate against Kubernetes cluster (dry-run)
helm install my-app my-app --dry-run --debug
# Check for deprecated API versions
helm install my-app my-app --dry-run | kubectl apply --dry-run=server -f -
Create chart tests:
# Run Helm tests
helm install my-app my-app -n test --create-namespace
helm test my-app -n test
kubectl logs -n test -l "helm.sh/hook=test" --tail=-1
# See EXAMPLES.md for complete test script (test-chart.sh)
Package chart:
# Update dependencies first
helm dependency update my-app
# Package chart
helm package my-app
# Creates: my-app-0.1.0.tgz
# Verify package
helm verify my-app-0.1.0.tgz
# Generate index for repository
helm repo index . --url https://charts.example.com/
# Creates: index.yaml
Create different values files for environments:
# values-dev.yaml (excerpt)
replicaCount: 1
resources:
limits: {cpu: 500m, memory: 256Mi}
ingress:
hosts: [my-app-dev.example.com]
# values-prod.yaml (excerpt)
replicaCount: 5
autoscaling: {enabled: true, minReplicas: 3, maxReplicas: 10}
# ... (see EXAMPLES.md for complete env-specific values)
tls:
- secretName: my-app-tls
hosts:
- my-app.example.com
podDisruptionBudget:
enabled: true
minAvailable: 2
postgresql:
enabled: true
primary:
persistence:
size: 50Gi
resources:
limits:
cpu: 4000m
memory: 8Gi
Test with different environments:
# Test development values
helm install my-app-dev my-app -f values-dev.yaml --dry-run --debug
# Test production values
helm install my-app-prod my-app -f values-prod.yaml --dry-run --debug
# Install to dev namespace
helm install my-app my-app -f values-dev.yaml -n development --create-namespace
# Install to prod namespace
helm install my-app my-app -f values-prod.yaml -n production --create-namespace
Esperado: Chart passes all lint checks. Template rendering produces valid Kubernetes YAML. Tests pass successfully. Chart packages without errors. Different values files work for each environment. Installation succeeds without warnings.
En caso de fallo:
- Review lint output for specific issues
- Check template syntax errors with
--debugflag - Verify all required values are set:
helm get values <release> - Test dependency resolution:
helm dependency list my-app - Validate packaged chart:
tar -tzf my-app-0.1.0.tgz - Check for missing files in package
Paso 6: Publish to Chart Repository
Set up chart repository and publish versioned releases.
Options for publishing:
# GitHub Pages
git checkout -b gh-pages && mkdir charts
cp my-app-0.1.0.tgz charts/
helm repo index charts/ --url https://username.github.io/repo/charts
# OCI registry (Helm 3.8+)
helm registry login registry.example.com -u $USER -p $PASS
helm push my-app-0.1.0.tgz oci://registry.example.com/charts
# Install from repo
helm repo add myrepo https://charts.example.com
helm install my-app myrepo/my-app -f custom-values.yaml
See Extended Examples for ChartMuseum setup, release automation, and complete README template.
Esperado: Chart published to repository successfully. Chart discoverable via helm search. Installation works from repository. Versioning follows SemVer.
En caso de fallo:
- Verify repository URL accessible
- Check index.yaml generated:
helm repo index --help - For OCI registries, ensure authentication working
- Test repository addition:
helm repo add test <url>
GitHub 저장소
연관 스킬
content-collections
메타이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
polymarket
메타이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
creating-opencode-plugins
메타이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
sglang
메타SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
