یک کلاستر Kubernetes کافی نیست وقتی باید:

• در چند Region یا چند cloud زنده بمانید
• edge و on-prem را کنار public cloud مدیریت کنید
• بدون بازنویسی اپ، replica را بین کلاسترها پخش و در failure جابه‌جا کنید

Karmada (مخفف Kubernetes Armada) برای همین ساخته شد:

Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration — run cloud-native apps across multiple clusters and clouds, with no changes to your applications.

یعنی یک control plane فدراتیو که به زبان API بومی Kubernetes حرف می‌زند، scheduling چندبعدی دارد، و برای multi-cloud / hybrid / edge طراحی شده است.

CNCF Incubating (پروژهٔ incubation بنیاد). سایت: karmada.io · Docs: docs · Repo: github.com/karmada-io/karmada · نسخهٔ docs رایج: v1.18

مشکل: چند کلاستر، بدون فدراسیون

بدون لایهٔ multi-cluster:
  GitOps × N کلاستر
  Helm × N
  failover دستی
  policy و image registry جدا برای هر cloud

با Karmada:
  یک Deployment (native) + PropagationPolicy
       ↓
  پخش / وزن / affinity / failover روی member clusters

Karmada جایگزین ساخت کلاستر نیست (آن کار Cluster API است) و جایگزین GitOps کامل نیست — لایهٔ workload federation و placement است. برای GitOps ببینید: Flux و Argo. برای control plane زیرساختی: Crossplane.

Karmada چیست؟

طبق karmada.io و What is Karmada?:

• سیستم مدیریت Kubernetes برای اجرای اپ‌های cloud-native روی چند کلاستر و چند cloud
• بدون تغییر در اپلیکیشن‌ها
• هدف: automation آماده برای multi-cluster در multi-cloud و hybrid — مدیریت متمرکز، HA، recovery، و traffic scheduling
• جانشین مفهومی Federation v1 و Kubefed (Federation v2) با اصلاح مدل API

چرا Karmada (از سایت رسمی)

مفاهیم اصلی

جریان منطقی (سه‌لایه):

1) Policy Controller
   PropagationPolicy + Resource template
        → ResourceBinding / ClusterResourceBinding

2) Binding Controller
   ResourceBinding
        → Work (یکی به ازای هر member هدف)

3) Execution Controller
   Work
        → اعمال resource روی member cluster

این مدل به تیم platform اجازه می‌دهد سیاست placement بنویسد و تیم سرویس همان Deployment معمولی را نگه دارد — الگوی رایج در بانک‌ها و پلتفرم‌های بزرگ (مثلاً گزارش‌های CNCF دربارهٔ ICBC).

معماری Control Plane

Control plane شبیه یک کلاستر Kubernetes «مجازی» است:

                 ┌─────────────────────────────────────┐
                 │     Karmada Control Plane           │
  kubectl/Helm/  │  karmada-apiserver                  │
  Flux/Argo ────►│  aggregated-apiserver               │
                 │  controller-manager                 │
                 │  scheduler                          │
                 │  webhook                            │
                 │  kube-controller-manager (+ etcd)   │
                 └──────────────┬──────────────────────┘
            Push │              │ Pull (agent)
                 ▼              ▼
        ┌────────────┐   ┌────────────┐   ┌────────────┐
        │ Member A   │   │ Member B   │   │ Member C   │
        │ (cloud)    │   │ (on-prem)  │   │ (edge)     │
        └────────────┘   └────────────┘   └────────────┘

اجزای نصب‌شده (معمولاً در karmada-system)

Scheduler روی fault domain، ظرفیت منابع، نسخهٔ Kubernetes و add-onهای فعال تصمیم می‌گیرد؛ framework قابل گسترش (plugin) است.

جزئیات بیشتر: Architecture در docs و CNCF: Multi-cluster with an ocean of nodes.

Push در برابر Pull

هر دو می‌توانند هم‌زمان در یک Armada باشند (مثلاً عضوهای داخلی Push، لبه Pull).

# Push — از سمت control plane
kubectl karmada join ${MEMBER_CLUSTER_NAME} \
  --cluster-kubeconfig=$HOME/.kube/member.config

# Pull — از سمت member
kubectl karmada register <control-plane-endpoint> \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

لیست اعضا:

kubectl --kubeconfig /etc/karmada/karmada-apiserver.config get clusters

PropagationPolicy — قلب placement

PropagationPolicy مشخص می‌کند کدام منابع و به کجا بروند. نمونهٔ مفهومی:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
  namespace: default
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
    replicaScheduling:
      replicaSchedulingType: Divided
      replicaDivisionPreference: Weighted
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames: ["member1"]
            weight: 2
          - targetCluster:
              clusterNames: ["member2"]
            weight: 1

نکات مهم:

• resourceSelectors می‌توانند label-based باشند تا یک سیاست platform برای همهٔ Deploymentهای HA اعمال شود
• ClusterPropagationPolicy نسخهٔ cluster-scoped است
• سیاست از manifest اپ جداست — تیم سرویس Deployment می‌نویسد؛ platform placement را مالک است

سناریوهای رایج placement:

OverridePolicy — تخصص per-cluster

وقتی یک template برای همه کافی نیست:

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: nginx-image-override
  namespace: default
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  overrideRules:
    - targetCluster:
        clusterNames: ["member-cn"]
      overriders:
        plaintext:
          - path: "/spec/template/spec/containers/0/image"
            operator: replace
            value: "registry.cn-example.com/library/nginx:1.25"

مثال‌های کلاسیک از README رسمی:

• عوض کردن image prefix بر اساس Region
• عوض کردن StorageClass بر اساس cloud provider

بدون Override مجبورید N نسخهٔ تقریباً یکسان از Deployment نگه دارید.

Resource Interpreter و CRDهای سفارشی

برای CRهای غیر استاندارد، Karmada از سازوکار Resource Interpreter (از جمله webhook) استفاده می‌کند تا بفهمد چگونه replica، status و فیلدهای حیاتی را برای فدراسیون تفسیر کند. این همان چیزی است که توزیع workloadهای پیچیده و تجمیع status را ممکن می‌کند — نه فقط Deployment و Service.

نصب و شروع سریع

پیش‌نیاز CLI: پلاگین kubectl-karmada یا باینری karmadactl (دستورات معادل‌اند). docs: Installation.

روی کلاستر موجود

# نیاز به privilege برای مسیر پیش‌فرض /etc/karmada (قابل override با --karmada-data)
kubectl karmada init

خروجی موفق معمولاً راهنمای join / register را چاپ می‌کند. کامپوننت‌ها در karmada-system:

kubectl get deployments -n karmada-system
kubectl get statefulsets -n karmada-system   # etcd

kubeconfig کنترل‌پلین پیش‌فرض: /etc/karmada/karmada-apiserver.config

HA

kubectl karmada init \
  --karmada-apiserver-replicas 3 \
  --etcd-replicas 3

Offline / سفارشی‌سازی image

kubectl karmada init --crds /$HOME/crds.tar.gz
kubectl karmada init \
  --karmada-controller-manager-image=example.registry.com/library/karmada-controller-manager:1.0

روش‌های دیگر

برای توسعهٔ محلی:

git clone https://github.com/karmada-io/karmada
cd karmada
hack/local-up-karmada.sh
export KUBECONFIG="$HOME/.kube/karmada.config"
kubectl get clusters

خروجی نمونه: member1/member2 در Push و member3 در Pull.

اولین workload

1. به context کنترل‌پلین سوییچ کنید
2. یک Deployment معمولی kubectl apply کنید (هنوز روی member نمی‌رود — فقط template است)
3. PropagationPolicy (و در صورت نیاز Override) را apply کنید
4. روی members وضعیت Pod را ببینید؛ روی hub وضعیت Binding/Work را دنبال کنید

GitOps: Flux یا Argo را فقط به karmada-apiserver وصل کنید؛ پخش به members کار Karmada است — نه تکرار ApplicationSet برای هر کلاستر (مگر hybrid آگاهانه).

مقایسه با گزینه‌های multi-cluster

جمع‌بندی انتخاب:

• می‌خواهید یک Deployment → چند کلاستر با failover → Karmada
• می‌خواهید کلاستر بسازید → Cluster API
• می‌خواهید فقط تحویل GitOps در هزاران edge → Fleet / ApplicationSet را جدی بگیرید
• روی استک Red Hat / ACM و agentهای سفارشی → OCM را هم ارزیابی کنید

بیشتر در CNCF: Karmada and OCM.

عملیات روزمره

برای کلاسترهای سبک edge: K3s. برای mesh بین سرویس‌ها داخل/بین کلاسترها: Istio.

یکپارچگی با استک P30Light

الگوی رایج پلتفرم:

Cluster API / cloud  →  member clusters
Git (Flux/Argo)      →  Karmada control plane (templates + policies)
Karmada              →  schedule / override / failover روی members

خلاصه

قدم بعدی

1. با hack/local-up-karmada.sh یا Kind یک lab سه عضوی بالا بیاورید.
2. یک Deployment + PropagationPolicy وزن‌دار بین دو member اعمال کنید.
3. یک Override برای image registry متفاوت روی یکی از members بنویسید.
4. یک member را cordon/قطع کنید و رفتار rebalancing را ببینید.
5. Flux/Argo را فقط به karmada-apiserver وصل کنید.
6. برای production، init با replicaهای HA برای apiserver و etcd، و تفکیک RBAC platform در برابر app teams.

منابع

• Karmada — سایت رسمی
• What is Karmada? (Docs)
• Installation
• Migration from Kubefed
• GitHub — karmada-io/karmada
• CNCF — Ocean of nodes
• CNCF — Karmada and Open Cluster Management

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