ویرگول
ورودثبت نام
فرهاد صادقی
فرهاد صادقیمهندس نرم افزار، طراحی و راه اندازی سیستم های نرم افزاری بر پایه معماری میکروسرویس
فرهاد صادقی
فرهاد صادقی
خواندن ۷ دقیقه·۳ ساعت پیش

آموزش Kubernetes - قسمت دوازدهم (Job-CronJob-Helm/Chart)

1.Job

Job در Kubernetes یک منبع (Resource) است که برای اجرای کارهای یک‌باره (Batch یا Run-to-Completion) استفاده می‌شود. برخلاف Deployment که همیشه سعی می‌کند Podها در حال اجرا باشند، Job پس از اینکه کار موردنظر با موفقیت انجام شد، به پایان می‌رسد.

Job چه زمانی استفاده می‌شود؟

موارد رایج استفاده از Job:

  • اجرای اسکریپت‌های Backup

  • پردازش فایل‌ها

  • Import یا Export داده‌ها

  • اجرای Migration پایگاه داده

  • ارسال گزارش‌های دوره‌ای (اگر زمان‌بندی لازم باشد، معمولاً با CronJob)

  • اجرای تست‌های Batch

نحوه کار Job

فرض کنید یک Job ایجاد می‌کنید.

  1. Kubernetes یک یا چند Pod ایجاد می‌کند.

  2. Pod برنامه را اجرا می‌کند.

  3. اگر برنامه با Exit Code = 0 تمام شود، Job موفق (Succeeded) می‌شود.

  4. اگر برنامه با خطا خارج شود، Job بسته به تنظیمات، Pod جدیدی ایجاد کرده و دوباره تلاش می‌کند.

به عبارت دیگر:

Job
 │
 └── Pod
      │
      ├── اجرای برنامه
      ├── موفق → Job Complete
      └── ناموفق → Retry

یک مثال ساده

apiVersion: batch/v1
kind: Job
metadata:
  name: hello-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: hello
        image: busybox
        command:
        - echo
        - "Hello Kubernetes Job"

ایجاد Job:

kubectl apply -f job.yaml

مشاهده Job:

kubectl get jobs

مشاهده Pod:

kubectl get pods

لاگ:

kubectl logs <pod-name>

جزئیات:

kubectl describe job hello-job

حذف:

kubectl delete job hello-job

restartPolicy

در Job فقط دو مقدار مجاز هستند:

restartPolicy: Never
یا
restartPolicy: OnFailure

Never

اگر برنامه شکست بخورد:

Pod 1 → Failed
        ↓
Job یک Pod جدید ایجاد می‌کند.

OnFailure

اگر Container داخل همان Pod کرش کند:

Container
    ↓
همان Pod دوباره اجرا می‌شود.

backoffLimit

تعداد دفعات Retry را مشخص می‌کند.

مثال:

spec:
  backoffLimit: 4

یعنی اگر Job چهار بار شکست بخورد:

Attempt 1 ❌

Attempt 2 ❌

Attempt 3 ❌

Attempt 4 ❌

Job Failed

completions

تعداد دفعاتی که Job باید با موفقیت اجرا شود.

مثال:

spec:
  completions: 5

یعنی:

Success 1 ✔

Success 2 ✔

Success 3 ✔

Success 4 ✔

Success 5 ✔

Job Complete

parallelism

چند Pod همزمان اجرا شوند.

مثال:

spec:
  completions: 10
  parallelism: 3

خروجی:

Pod1
Pod2
Pod3     ← همزمان

وقتی یکی تمام شد

Pod4

بعد Pod5

...

در نهایت باید ۱۰ اجرای موفق داشته باشید، اما حداکثر ۳ Pod همزمان اجرا می‌شوند.

activeDeadlineSeconds

حداکثر زمان اجرای Job.

spec:
  activeDeadlineSeconds: 300

بعد از ۵ دقیقه:

Job → Failed

حتی اگر هنوز کامل نشده باشد.

ttlSecondsAfterFinished

حذف خودکار Job بعد از اتمام.

spec:
  ttlSecondsAfterFinished: 600

یعنی:

Job Complete

↓

۱۰ دقیقه بعد

↓

حذف Job و Pod

نمونه کامل

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5
  parallelism: 2
  backoffLimit: 3
  ttlSecondsAfterFinished: 300

  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: busybox
        command:
        - sh
        - -c
        - |
          echo Start
          sleep 10
          echo Done

2.CronJob

  • Job: یک بار اجرا می‌شود.

  • CronJob: بر اساس زمان‌بندی، به‌صورت خودکار Jobهای جدید ایجاد می‌کند (مشابه cron در لینوکس).

به طور خلاصه، CronJob یک زمان‌بند است که در هر نوبت، یک Job جدید می‌سازد؛ بنابراین هر قابلیتی که برای Job وجود دارد (مانند backoffLimit، parallelism و completions) را می‌توانید داخل بخش jobTemplate نیز پیکربندی کنید

برای مثال، اگر بخواهید هر شب ساعت ۲ بامداد از پایگاه داده نسخه پشتیبان تهیه کنید، از CronJob استفاده می‌کنید که در هر نوبت، یک Job جدید برای انجام عملیات Backup ایجاد می‌کند.

مثال: اجرای Job هر دقیقه

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello-cronjob
spec:
  schedule: "* * * * *"

  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: hello
            image: busybox
            command:
            - sh
            - -c
            - |
              echo "Current time: $(date)"

اعمال آن:

kubectl apply -f cronjob.yaml

مشاهده CronJob

kubectl get cronjobs

نمونه خروجی:

NAME            SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE
hello-cronjob   * * * * *     False     0        30s

مشاهده Jobهای ایجادشده

kubectl get jobs

نمونه خروجی:

NAME                         COMPLETIONS   DURATION
hello-cronjob-28692340       1/1           5s
hello-cronjob-28692341       1/1           4s
hello-cronjob-28692342       1/1           5s

هر بار که زمان‌بندی فرا برسد، یک Job جدید ساخته می‌شود.

مشاهده لاگ

اگر نام Pod را ندانید:

kubectl logs job/hello-cronjob-28692342

یا:

kubectl logs <pod-name>

فرمت زمان‌بندی (Cron Expression)

CronJob از ۵ فیلد برای زمان‌بندی استفاده می‌کند:

* * * * *
│ │ │ │ │
│ │ │ │ └── روز هفته (0-6)
│ │ │ └──── ماه (1-12)
│ │ └────── روز ماه (1-31)
│ └──────── ساعت (0-23)
└────────── دقیقه (0-59)

مثال واقعی: Backup دیتابیس هر شب

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mysql-backup
spec:
  schedule: "0 2 * * *"

  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: backup
            image: mysql:8
            command:
            - sh
            - -c
            - |
              mysqldump -h mysql-service \
                        -u root \
                        -p$MYSQL_PASSWORD \
                        mydb > /backup/mydb.sql

در این مثال، هر شب ساعت ۲ یک Job جدید ایجاد می‌شود که از پایگاه داده نسخه پشتیبان تهیه می‌کند.

تنظیمات مهم CronJob

جلوگیری از اجرای هم‌زمان

اگر اجرای قبلی هنوز تمام نشده باشد:

concurrencyPolicy: Forbid

گزینه‌های ممکن:

  • Allow (پیش‌فرض): اجرای هم‌زمان مجاز است.

  • Forbid: اگر Job قبلی هنوز در حال اجرا باشد، Job جدید ایجاد نمی‌شود.

  • Replace: Job قبلی متوقف شده و Job جدید جایگزین آن می‌شود.

نگهداری تاریخچه Jobها

successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1

یعنی فقط ۳ Job موفق و ۱ Job ناموفق نگه داشته شوند و بقیه حذف شوند.

متوقف کردن CronJob

برای جلوگیری موقت از اجرای زمان‌بندی:

spec:
  suspend: true

برای فعال‌سازی مجدد:

spec:
  suspend: false

3.Helm/Chart

اگر Kubernetes را با apt مقایسه کنیم، Helm همان چیزی است که apt برای لینوکس یا npm برای Node.js است.

به عبارت ساده:

  • Kubernetes = سیستم‌عامل اجرای کانتینرها

  • Helm = Package Manager برای Kubernetes

  • Chart = بسته (Package) که شامل تمام فایل‌های موردنیاز برای نصب یک برنامه روی Kubernetes است.

چرا Helm به وجود آمد؟

فرض کنید می‌خواهید یک برنامه مانند Jenkins را روی Kubernetes نصب کنید.

بدون Helm باید فایل‌های زیر را خودتان بنویسید:

  • Deployment

  • Service

  • ConfigMap

  • Secret

  • PersistentVolumeClaim

  • Ingress

  • ServiceAccount

  • Role

  • RoleBinding

  • NetworkPolicy

ممکن است بیش از ۲۰ فایل YAML داشته باشید.

ساختار:

jenkins/
 ├── deployment.yaml
 ├── service.yaml
 ├── pvc.yaml
 ├── ingress.yaml
 ├── secret.yaml
 ├── configmap.yaml
 ├── role.yaml
 ├── rolebinding.yaml
 └── ...

مدیریت این فایل‌ها سخت می‌شود. Helm این مشکل را حل می‌کند.

Helm Chart چیست؟

یک Chart مجموعه‌ای از Templateهای Kubernetes است که به همراه مقادیر قابل تنظیم (Values) بسته‌بندی شده‌اند.

ساختار یک Chart:

mychart/
│
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── pvc.yaml
└── .helmignore

Chart.yaml

اطلاعات خود Chart را نگهداری می‌کند.

مثال:

apiVersion: v2
name: nginx
description: My nginx chart
type: application
version: 1.0.0
appVersion: "1.27"

values.yaml

تمام تنظیمات قابل تغییر اینجاست.

مثلاً:

replicaCount: 2

image:
  repository: nginx
  tag: latest

service:
  type: ClusterIP
  port: 80

اگر بخواهید تعداد Replica را تغییر دهید، لازم نیست Deployment را ویرایش کنید؛ فقط این فایل را تغییر می‌دهید.

templates/

داخل این پوشه Templateهای Kubernetes قرار دارند.

مثلاً Deployment:

apiVersion: apps/v1
kind: Deployment

metadata:
  name: {{ .Release.Name }}

spec:
  replicas: {{ .Values.replicaCount }}

  template:

    spec:

      containers:

      - name: nginx

        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

دقت کنید:

{{ .Values.replicaCount }}

از فایل values.yaml خوانده می‌شود.

نحوه کار Helm

فرض کنید:

values.yaml

replicaCount: 3

Template:

replicas: {{ .Values.replicaCount }}

بعد از نصب Helm:

replicas: 3

تولید می‌شود.

یعنی Helm قبل از ارسال فایل به Kubernetes، Templateها را Render می‌کند.

نصب یک Chart

مثلاً نصب Nginx:

helm install my-nginx bitnami/nginx

اتفاقی که می‌افتد:

Helm
↓
Template Rendering
↓
Deployment
Service
ConfigMap
PVC
...
↓
Kubernetes API

نصب با مقادیر سفارشی

فرض کنید می‌خواهید سه Replica داشته باشید:

helm install my-nginx bitnami/nginx --set replicaCount=3

یا

helm install my-nginx bitnami/nginx -f values-production.yaml

Upgrade

یکی از بزرگ‌ترین مزیت‌های Helm:

helm upgrade my-nginx bitnami/nginx

بدون حذف برنامه، تنظیمات را به‌روزرسانی می‌کند.

Rollback

اگر نسخه جدید مشکل داشت:

ابتدا تاریخچه نسخه‌ها را ببینید:

helm history my-nginx

سپس به نسخه قبل برگردید:

helm rollback my-nginx 1

این یکی از ویژگی‌هایی است که مدیریت نسخه و بازگشت سریع را بسیار ساده می‌کند.

حذف برنامه

helm uninstall my-nginx

تمام Resourceهایی که Helm ایجاد کرده بود حذف می‌شوند.

ساخت یک Chart جدید

helm create myapp

ساختار زیر ایجاد می‌شود:

myapp/
Chart.yaml
values.yaml
templates/
charts/

دستورات مهم Helm

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

helm search repo nginx

helm install my-nginx bitnami/nginx

helm list

helm status my-nginx

helm upgrade my-nginx bitnami/nginx

helm rollback my-nginx 1

helm uninstall my-nginx

مثال عملی

فرض کنید می‌خواهید یک برنامه را در سه محیط مختلف اجرا کنید.

Development

replicaCount: 1

image:
  tag: dev

Staging

replicaCount: 2

image:
  tag: staging

Production

replicaCount: 5

image:
  tag: stable

برای هر محیط فقط فایل مقادیر (Values) تغییر می‌کند:

helm install app-dev ./mychart -f values-dev.yaml

helm install app-stage ./mychart -f values-stage.yaml

helm install app-prod ./mychart -f values-prod.yaml

بدون اینکه Templateها را تغییر دهید، Helm تنظیمات مناسب هر محیط را اعمال می‌کند.

جمع‌بندی

Helm سه مفهوم کلیدی دارد:

  1. Chart: بسته‌ای شامل Templateها و تنظیمات یک برنامه.

  2. Values: مقادیر قابل تنظیم که بدون تغییر Templateها، رفتار برنامه را تغییر می‌دهند.

  3. Release: هر بار که یک Chart را نصب می‌کنید، Helm یک Release ایجاد می‌کند و نسخه‌های آن را مدیریت می‌کند.

به همین دلیل، Helm به استاندارد رایج برای استقرار و مدیریت برنامه‌های پیچیده روی Kubernetes تبدیل شده است؛ زیرا نصب، به‌روزرسانی، بازگشت به نسخه قبل و سفارشی‌سازی برنامه‌ها را به‌صورت یکپارچه فراهم می‌کند.

برای نصب Helm، به راهنمای موجود در سایت رسمی آن رجوع کنید:

https://helm.sh

https://helm.sh/docs/intro/install

همچنین در سایت زیر می توانید مجموعه کاملی از پکیج ها و نرم افزارهای Cloud Native را جستجو کرده و آنها را از طریق Helm/Chart نصب کنید:

https://artifacthub.io

kubernetes
۰
۰
فرهاد صادقی
فرهاد صادقی
مهندس نرم افزار، طراحی و راه اندازی سیستم های نرم افزاری بر پایه معماری میکروسرویس
شاید از این پست‌ها خوشتان بیاید