استقرار یک اپ واقعی روی Kubernetes یعنی ده‌ها YAML: Deployment، Service، ConfigMap، RBAC، Ingress، CRD، … تکرار این‌ها بین envها و نسخه‌ها بدون ابزار، یعنی copy-paste و drift.

Helm پاسخ استاندارد اکوسیستم است:

The package manager for Kubernetes — Find, share, and use software built for Kubernetes.

نسخه جاری اعلام‌شده روی سایت: Helm 4.2.4 (خط ۳ هنوز به‌صورت 3.21.x نگهداری می‌شود). CNCF Graduated. جامعه بزرگ charts روی Artifact Hub.

Helm برای اپ داخل cluster است — نه برای ساختن خود cluster (آن کار kubeadm / K3s / اپراتور زیرساخت است).

مشکل و راه‌حل

طبق معماری رسمی: Helm مثل Homebrew / apt / yum برای Kubernetes است.

سه مفهوم کلیدی

یک chart را می‌توان چند بار نصب کرد (مثلاً دو MySQL) — هر بار یک release جدا.

Chart (package) + values.yaml
        │
        ▼  helm install / upgrade
   Release (instance in cluster)
        │
        ▼
 Kubernetes resources (Secret holds release metadata)

معماری

از Helm 3 به بعد:

• بدون Tiller (سرور داخل-cluster قدیمی حذف شد)
• Client CLI روی ماشین شما / CI
• Helm library (Go) منطق install/upgrade/uninstall
• ارتباط مستقیم با Kubernetes API
• وضعیت release در Secrets داخل cluster (نه DB جدا)

نقش‌های کاربر (طبق docs):

آناتومی یک Chart

mychart/
├── Chart.yaml          # نام، نسخه، وابستگی‌ها، apiVersion
├── values.yaml         # مقادیر پیش‌فرض
├── values.schema.json  # اختیاری — اعتبارسنجی values
├── charts/             # subcharts وابستگی
├── crds/               # CRDها (رفتار خاص در install)
├── templates/          # قالب‌های Go template → YAML
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl
│   └── NOTES.txt
└── README.md

ساخت اسکلت:

helm create mychart

Chart.yaml (مفهومی)

apiVersion: v2
name: mychart
description: A sample chart
type: application
version: 0.1.0        # نسخه chart
appVersion: "1.2.3"   # نسخه نرم‌افزار داخل
dependencies:
  - name: postgresql
    version: "15.x.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

apiVersion: v2 هنوز استاندارد غالب است. در Helm 4، Charts v3 آزمایشی است (HELM_EXPERIMENTAL_CHART_V3=1).

Templates و values

# templates/deployment.yaml (خلاصه)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mychart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# values.yaml
replicaCount: 2
image:
  repository: ghcr.io/example/app
  tag: "1.0.0"

helm install myapp ./mychart -f values-prod.yaml --set replicaCount=3
helm template myapp ./mychart -f values-prod.yaml   # فقط رندر، بدون apply
helm lint ./mychart

توابع رایج: include، required، default، toYaml، nindent، lookup (با احتیاط)، و در Helm 4 امکان custom template functions از طریق پلاگین.

جریان روزمره CLI

# نصب CLI
brew install helm
helm version

# مخزن کلاسیک
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx
helm show values bitnami/nginx

# نصب / ارتقا / برگشت
helm install web bitnami/nginx -n apps --create-namespace
helm list -A
helm status web -n apps
helm upgrade web bitnami/nginx -n apps -f values.yaml
helm history web -n apps
helm rollback web 1 -n apps
helm uninstall web -n apps

# OCI (مدرن)
helm pull oci://ghcr.io/example/charts/myapp --version 1.2.0
helm install myapp oci://registry.example.com/charts/app@sha256:abc123...

پرچم‌های مهم:

Hooks، Lifecycle و Dependencies

Hooks اجازه می‌دهند Job یا منبعی در لحظات خاص اجرا شود: pre-install، post-install، pre-upgrade، post-delete، … مفید برای migration دیتابیس یا seed — اما در GitOps و post-renderer باید با دقت مدیریت شوند (در Helm 4 رفتار stream با post-renderer تغییر کرده).

Dependencies:

helm dependency update ./mychart   # دانلود subcharts به charts/
helm dependency build

شرط‌ها (condition / tags) subchart را اختیاری می‌کنند.

CRDs: پوشه crds/ در install اول اعمال می‌شود؛ upgrade خودکار CRD محدودیت‌هایی دارد — برای CRDهای پیچیده اغلب Operator یا مسیر جدا توصیه می‌شود.

توزیع Chart: Repo کلاسیک در برابر OCI

helm package ./mychart
helm push mychart-0.1.0.tgz oci://harbor.example.com/charts
helm registry login harbor.example.com

در Helm 4: نصب با digest برای supply-chain؛ helm registry login فقط با domain (نه URL کامل).

Deep Dive: Helm 4

طبق Helm 4 Overview: charts قدیمی (v2) سازگار می‌مانند؛ CLI و پلاگین‌ها تغییرات شکستی دارند.

خلاصه تازه‌ها

SSA و ارتقا از Helm 3

• نصب تازه با Helm 4 → SSA پیش‌فرض
• upgrade/rollback release قدیمی → به‌طور پیش‌فرض همان روش apply قبلی (client-side) تا پیوستگی حفظ شود
• با --server-side می‌توان صریح override کرد

Post-renderer

دیگر نمی‌توانید مستقیم sed یا اسکریپت را به --post-renderer بدهید — باید plugin نصب کنید و نامش را پاس دهید. اگر با Flux یا Kustomize post-render کار می‌کنید، استراتژی hooks (combined / separate / nohooks) را در مسیر مهاجرت تست کنید.

چک‌لیست مهاجرت

1. charts موجود را با helm template / install آزمایشی روی v4 تست کنید
2. پلاگین‌ها و post-rendererها را به‌روز کنید
3. اسکریپت‌های CI را برای پرچم‌های تغییرنام‌یافته اصلاح کنید
4. OCI login و digest را در pipeline خصوصی بررسی کنید
5. Charts v3 را فقط آزمایشی بگیرید

Helm در GitOps

Helm خودش GitOps نیست — ابزار بسته‌بندی و release است. لایه reconcile معمولاً:

الگوی رایج: chart در OCI (Harbor) + values در Git + Flux/Argo برای اعمال.

مقایسه: Helm در برابر گزینه‌های دیگر

Helm در برابر Kustomize

بسیاری تیم‌ها: upstream با Helm، پوشش سازمانی با Kustomize/patches.

Helm در برابر Operator / Crossplane

Operator اغلب خودش را با Helm نصب می‌کنید؛ سپس CRهای Operator کار روزمره را می‌گیرند.

Helm در برابر «فقط kubectl»

برای یک Deployment ساده، kubectl کافی است. وقتی نسخه، وابستگی، چند env و اشتراک تیمی مطرح شد، Chart ارزش پیدا می‌کند.

امنیت و عملیات

• values را commit کنید؛ اسرار را با SOPS / Sealed Secrets / External Secrets نگه دارید — نه plaintext در Git
• charts را از منبع معتبر بکشید؛ OCI digest در Helm 4
• helm lint و سیاست admission (Kyverno و مشابه)
• RBAC حداقل برای ServiceAccount داخل chart
• --wait و rollback-on-failure در production
• releaseهای یتیم را با helm list و labels استاندارد رصد کنید
• نسخه Helm CLI در CI را pin کنید (۳ در برابر ۴ رفتار متفاوت دارد)

TLS و گواهی لبه: cert-manager. Mesh روی سرویس‌های نصب‌شده با Helm: Istio / Linkerd.

الگوی Chart خوب

1. values.yaml مستند با توضیح هر کلید
2. values.schema.json برای جلوگیری از typo
3. helpers در _helpers.tpl برای نام و label یکسان
4. برچسب‌های استاندارد Kubernetes (app.kubernetes.io/*)
5. منابع و probeها را پیش‌فرض معقول بگذارید
6. subchart را با condition اختیاری کنید
7. NOTES.txt راهنمای post-install
8. نسخه semver chart را جدی بگیرید (breaking → major)
9. README با مثال values برای dev/staging/prod
10. تست با helm template + kubeconform / Conftest در CI

چه زمانی Helm؟

✅ استفاده کنید

• نصب نرم‌افزارهای رایج (Ingress، DB، monitoring، …) از Artifact Hub
• بسته‌بندی اپ داخلی برای چند تیم/محیط
• نیاز به upgrade/rollback نسخه‌دار
• توزیع chart خصوصی روی Harbor OCI
• ورودی به GitOps با Flux HelmRelease / Argo

⚠️ شاید نه / مکمل

جمع‌بندی

Helm پیچیدگی YAML را حذف نمی‌کند — آن را بسته‌بندی، نسخه‌بندی و قابل اشتراک می‌کند. با Helm 4 مسیر supply-chain (OCI digest) و انعطاف پلاگین قوی‌تر شده، در حالی که charts موجود همچنان کار می‌کنند.

قدم بعدی

1. brew install helm و Quick Start
2. helm create و یک Deployment را قالب کنید
3. یک chart عمومی از Artifact Hub با -f سفارشی نصب کنید
4. همان chart را به OCI روی Harbor push کنید
5. یک HelmRelease در Flux یا Application در Argo بسازید
6. اگر روی Helm 3 هستید، staging را با CLI ۴.۲ تست و چک‌لیست مهاجرت را بروید

منابع

• Helm — helm.sh
• Architecture
• Helm 4 Overview
• Charts guide
• Artifact Hub
• GitHub — helm/helm
• Flux (مقاله P30Light)
• Argo (مقاله P30Light)
• Harbor (مقاله P30Light)

منتشر شده در P30Light — بخش زیرساخت و سرور.