استقرار روی Kubernetes اگر فقط با kubectl apply از لپ‌تاپ باشد، drift، حسابرسی ضعیف، و «چه کسی چه چیزی را عوض کرد؟» اجتناب‌ناپذیر است.

Flux خانواده پروژه‌های GitOps برای حل همین مشکل است:

Flux — the GitOps family of projects — continuous and progressive delivery solutions for Kubernetes that are open and extensible.

نسخه اعلام‌شده روی سایت: Flux 2.9 GA. ریشه در Weaveworks؛ امروز CNCF Graduated و در CI/CD Tech Radar کنار Helm در دسته Adopt. همراه نزدیک: Flagger برای progressive delivery (canary، A/B).

GitOps در یک پاراگراف

Flux این مدل را با کنترلرهای Kubernetes-native پیاده می‌کند — نه یک «سرور CD جدا با مدل کاربری خودش» به‌عنوان هسته.

Flux چیست؟

طبق مستندات رسمی:

ابزار نگه‌داشتن clusterها در sync با منابع پیکربندی (مثل Git) و خودکارسازی به‌روزرسانی وقتی کد/پیکربندی جدید آماده استقرار است.

Flux هر منبع Kubernetes را می‌تواند مدیریت کند — نه فقط Deployment اپ: CRDها، NetworkPolicy، HelmRelease، حتی تعریف cluster با Cluster API.

معماری: GitOps Toolkit

Flux v2 از GitOps Toolkit ساخته شده — مجموعه‌ای از کنترلرها، APIهای composable، و پکیج‌های Go قابل استفاده مجدد.

Git / OCI / Helm repo / S3 bucket
        │
        ▼
┌───────────────────┐
│ source-controller │  ← artifact cache + verify
└─────────┬─────────┘
          │
    ┌─────┴──────┐
    ▼            ▼
kustomize-    helm-
controller    controller
    │            │
    └─────┬──────┘
          ▼
   Kubernetes API (SSA apply)
          │
notification-controller → Slack / Teams / webhooks
image-reflector + image-automation → commit tag به Git

کنترلرها و CRDهای اصلی

هر کنترلر مستقل است؛ state در status همان CRD می‌ماند. UI اجباری نیست — flux get و kubectl کافی‌اند. برای داشبورد: Capacitor، Headlamp plugin، Freelens، VS Code GitOps Tools، Weave GitOps، Flux Operator و گزینه‌های ابری.

قابلیت‌های کلیدی

۱. Push به Git — بقیه با Flux

بازآرایی خودکار (reconciliation) دوره‌ای یا event-triggered. با Flagger: canary، A/B، feature flag rollout.

۲. منابع متنوع

• Git: GitHub، GitLab، Bitbucket، …
• OCI artifacts (شامل charts و manifests)
• Helm repositories
• S3-compatible buckets (مثلاً MinIO)

۳. امنیت Pull-based

• حداقل privilege؛ impersonation برای multi-tenant
• یکپارچگی با Kyverno / OPA / admission
• کلید deploy / fine-grained PAT به‌جای دسترسی گسترده انسان

جزئیات: Security considerations.

۴. Multi-tenancy و Multi-cluster

• RBAC واقعی Kubernetes + serviceAccountName روی Kustomization
• چند Git repo همزمان
• یک cluster می‌تواند apps را روی clusterهای دیگر مدیریت کند؛ با Cluster API lifecycle ناوگان خوشه‌ها

۵. Image automation بومی

CI فقط build و push می‌کند؛ Flux tag را طبق policy انتخاب و به Git commit می‌کند → همان مسیر PR/review → reconcile. این در هسته Flux است؛ در Argo معمولاً به Argo CD Image Updater جدا نیاز دارید.

۶. وابستگی و سلامت

dependsOn بین Kustomizationها (مثلاً اول cert-manager، بعد Ingress). health check و wait قبل از اعلام Ready.

نمونه منابع (مفهومی)

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/stefanprodan/podinfo
  ref:
    branch: master
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 30m
  path: ./kustomize
  prune: true
  sourceRef:
    kind: GitRepository
    name: podinfo
  targetNamespace: default
  wait: true

Helm:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: my-app
  namespace: apps
spec:
  interval: 10m
  chart:
    spec:
      chart: my-app
      sourceRef:
        kind: HelmRepository
        name: my-charts
        namespace: flux-system
  values:
    replicaCount: 3

نصب و Bootstrap

CLI

brew install fluxcd/tap/flux
flux check --pre

Bootstrap روی GitHub (مسیر رسمی)

export GITHUB_TOKEN=<token>
export GITHUB_USER=<user>

flux bootstrap github \
  --owner=$GITHUB_USER \
  --repository=fleet-infra \
  --branch=main \
  --path=./clusters/my-cluster \
  --personal

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

1. ساخت/استفاده از repo fleet-infra
2. push مانیفست اجزای Flux
3. نصب کنترلرها در namespace flux-system
4. پیکربندی sync مسیر ./clusters/my-cluster

سپس source و kustomization را با flux create ... --export به Git اضافه کنید — همان الگوی Get Started.

flux get kustomizations --watch
flux get sources git
flux suspend kustomization podinfo   # توقف موقت reconcile
flux resume kustomization podinfo
flux reconcile kustomization flux-system --with-source

برای GitLab و سایر providerها: مستندات Bootstrapping.

Flagger — Progressive Delivery

Flux اپ را sync می‌کند؛ Flagger rollout را هوشمند می‌کند:

یکپارچه با mesh/Ingressهایی مثل Istio، Linkerd، Contour، NGINX، … متریک از Prometheus.

مقایسه جامع: Flux در برابر Argo CD

هر دو CNCF Graduated و production-readyاند. انتخاب معمولاً فرهنگی و عملیاتی است، نه «کدام GitOps است».

چه زمانی Flux؟

• می‌خواهید همه‌چیز CRD و Git باشد؛ بدون state مخفی UI
• image automation داخل همان stack مهم است
• Helm واقعی و rollback Helm برای تیم آشنا است
• multi-tenant با impersonation و least privilege دقیق

چه زمانی Argo؟

• داشبورد و diff بصری برای توسعه‌دهندگان حیاتی است
• ApplicationSet برای صدها cluster/app الگوی اصلی شماست
• از قبل اکوسیستم Argo (Workflows، Events، Rollouts) دارید — مقاله Argo Project

بسیاری سازمان‌ها یکی را برای CD انتخاب می‌کنند؛ ترکیب CI (GitHub Actions / Tekton / Argo Workflows) با Flux برای sync رایج است.

چه چیزی پشتیبانی می‌شود / چه چیزی خارج از هسته است

✅ پشتیبانی قوی

⚠️ خودتان باید طراحی کنید

❌ سوءتفاهم‌های رایج

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

• Bootstrap با حساب ربات و حداقل دسترسی repo
• جدا کردن repo infra از repo اپ در صورت نیاز
• prune: true را آگاهانه — حذف از Git یعنی حذف از cluster
• مانیتورینگ کنترلرها با Prometheus؛ هشدار روی Ready=False
• flux suspend قبل از troubleshooting دستی اورژانسی
• نسخه‌های کنترلر را با bootstrap/upgrade رسمی هم‌تراز کنید
• TLS لبه و گواهی: cert-manager

ارتباط با stack شما

Developer PR → Git / OCI
       │
       ▼
   Flux controllers
       ├── sync apps & infra
       ├── image automation → commit
       └── Flagger → canary (اختیاری)
              │
              ▼
         Kubernetes ([K3s](/blog/k3s-lightweight-kubernetes-edge-guide/) / kubeadm / …)
              ├── mesh: Istio / Linkerd
              ├── registry: Harbor
              └── GitOps آلترناتیو: Argo CD

Best practices

1. ساختار clusters/<name>/ و جداسازی apps/ / infra/
2. از bootstrap برای نصب اولیه استفاده کنید — نه apply دستی فراموش‌شدنی
3. dependsOn برای ترتیب (CRDها قبل از نمونه‌ها)
4. interval را با webhook ترکیب کنید (سریع + مطمئن)
5. برای secrets مسیر encrypted را از روز اول اجباری کنید
6. در staging همان الگوی production؛ فقط path/overlay فرق کند
7. ImagePolicy سمانتیک (semver / latest از branch) را صریح بنویسید
8. Alert روی failure reconcile — قبل از این که کاربر ببیند
9. Document کنید چه چیزی را Flux مدیریت می‌کند و چه چیزی خارج از GitOps است
10. POC موازی Flux در برابر Argo روی یک اپ واقعی — جدول تصمیم تیم

چه زمانی Flux؟

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

• GitOps pull-based برای apps و infra
• نیاز به image update خودکار به Git
• ترجیح CLI و Kubernetes RBAC خالص
• ناوگان multi-cluster با CAPI یا bootstrapهای متعدد
• همراهی با Flagger برای progressive delivery

⚠️ شاید Argo یا چیز دیگر

جمع‌بندی

Flux وعده ساده دارد: وضعیت مطلوب را در Git بنویسید؛ cluster خودش را هم‌تراز نگه می‌دارد. بقیه — Flagger، image automation، multi-tenant RBAC — همان خانواده را برای CD در مقیاس کامل می‌کند.

قدم بعدی

1. Get started روی kind یا K3s
2. flux bootstrap به یک repo آزمایشی
3. یک GitRepository + Kustomization برای اپ نمونه (podinfo)
4. یک HelmRelease و یک Alert به Slack
5. ImagePolicy روی تگ semver را امتحان کنید
6. مقاله Argo را کنار این یکی بگذارید و برای تیم تصمیم بگیرید

منابع

• Flux — fluxcd.io
• Flux Documentation
• Get Started
• Flagger
• Security
• GitHub — fluxcd
• Argo Project (مقاله P30Light)
• Harbor (مقاله P30Light)
• K3s (مقاله P30Light)

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