Kubernetes لمنصات SaaS: متى يناسب، متى ECS أفضل، وشو اخترنا

قرار Kubernetes

كل فريق هندسة بيوصل لنقطة بيسأل فيها: لازم نستخدم Kubernetes؟ الجواب الصريح: يعتمد على شو عم تشغّل، كم سيرفس عندك، وإذا تقدر تتحمل الـ overhead التشغيلي.

نحنا نشغّل ثلاث استراتيجيات compute مختلفة بالإنتاج. منصة تشتغل على Kubernetes (أكثر من 7 سيرفسات، Pimcore، OpenSearch، workers). وحدة ثانية تشتغل على ECS Fargate + Lambda (serverless-first، event-driven). والثالثة تستخدم مزيج من الاثنين. كل وحدة كانت القرار الصح لسياقها.

هالمقال يغطي إطار القرار وأنماط التنفيذ لكل نهج. لكيفية إدارتنا لـ Infrastructure as Code وراء هالـ deployments، شوف دليل IaC. للبنى التطبيقية اللي تشتغل فوقها، شوف دليل بنية النظام.

المقارنة الصريحة

تفصيل التكاليف الحقيقي

لمنصة SaaS نموذجية بـ 5 سيرفسات:

Kubernetes أرخص تحت الحمل (bin-packing فعّال، spot instances، سعة محجوزة). Lambda أرخص مع ترافيك قليل (ما تدفع شي وقت السكون). ECS Fargate هو الحل الوسط.

متى تختار Kubernetes

اختار Kubernetes لما يكون عندك:

أنظمة multi-service معقدة. إذا عندك أكثر من 7 سيرفسات مع تبعيات، تكوين مشترك، service discovery، و deployments منسقة، Kubernetes يدير هالشي بشكل ممتاز. حاويات Docker فردية على ECS بتصير صعبة الإدارة بهالحجم.

Stateful workloads. قواعد البيانات، محركات البحث (OpenSearch، MeiliSearch)، message brokers (RabbitMQ)، و cache clusters (Redis) كلها تستفيد من Kubernetes StatefulSets و PersistentVolumeClaims والـ operators. تشغيل هالأشياء على ECS يتطلب خدمات مُدارة خارجية لكل مكوّن stateful.

متطلبات multi-cloud. مانيفستات Kubernetes تشتغل على أي مزود سحابي. ECS و Lambda بس لـ AWS. إذا لازم تشتغل على AWS و Azure (أو ممكن تحتاج بالمستقبل)، Kubernetes هو الخيار القابل للنقل.

فريق منصة. Kubernetes يتطلب صيانة مستمرة: ترقيات الكلستر (كل 3-4 أشهر لباتشات الأمان)، إدارة مجموعات الـ nodes، تكوين الشبكات (ingress controllers، network policies)، وإدارة RBAC. بدون شخص أو فريق مخصص يتعامل مع هالشي، الـ overhead التشغيلي رح يبطئ كل المنظمة الهندسية.

بنية Kubernetes لمنصة PIM/Commerce

┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes Cluster                         │
│                                                              │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │ Ingress      │  │ Cert-Manager│  │ External DNS        │ │
│  │ (Nginx/Traefik)│ │ (Let's Encrypt)│ │ (Route53 sync)  │ │
│  └──────┬───────┘  └─────────────┘  └─────────────────────┘ │
│         │                                                     │
│  ┌──────▼──────────────────────────────────────────────────┐ │
│  │                    Namespaces                            │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  production namespace                             │   │ │
│  │  │                                                    │   │ │
│  │  │  pimcore-web (2-4 نسخ)                            │   │ │
│  │  │  pimcore-worker (1-3 نسخ)                         │   │ │
│  │  │  pimcore-ops (نسخة واحدة، صيانة)                  │   │ │
│  │  │  frontend (2-3 نسخ)                               │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  data namespace                                   │   │ │
│  │  │                                                    │   │ │
│  │  │  mysql (StatefulSet, نسخة واحدة أو مُدار)         │   │ │
│  │  │  redis (StatefulSet, نسخة واحدة أو مُدار)         │   │ │
│  │  │  opensearch (StatefulSet, 2-3 نسخ)                │   │ │
│  │  │  rabbitmq (StatefulSet, 1-3 نسخ)                  │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  flux-system namespace (متحكم GitOps)             │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

استراتيجية النشر: GitOps مع Flux

نحنا نستخدم Flux للنشر القائم على GitOps. مستودع Git هو المصدر الوحيد للحقيقة. Flux يطابق حالة الكلستر مع المستودع كل دقيقة.

# flux-system/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
    name: platform
    namespace: flux-system
spec:
    interval: 1m
    sourceRef:
        kind: GitRepository
        name: infrastructure
    path: ./kubernetes/resources/overlay/prod
    prune: true  # حذف الموارد المحذوفة من Git
    healthChecks:
        - apiVersion: apps/v1
          kind: Deployment
          name: pimcore
          namespace: production

مميزات مقارنة بـ kubectl apply أو الـ deployments المدارة بالـ CI:

• اكتشاف الانحراف وتصحيحه. إذا حد غيّر مورد يدوياً، Flux يرجعه خلال دقيقة واحدة.
• Git كسجل مراجعة. كل تغيير هو commit بـ Git مع المؤلف، الطابع الزمني، والفرق.
• ما في credentials للكلستر بالـ CI. Flux يسحب من Git. الـ CI يدفع لـ Git. خط الـ CI ما يحتاج أبداً وصول kubectl.
• الرجوع هو git revert. ارجع الـ commit، Flux يطابق، الرجوع تم.

Kustomize لطبقات البيئة

kubernetes/resources/
├── base/
│   ├── deployments/
│   │   ├── pimcore.yaml
│   │   ├── frontend.yaml
│   │   └── worker.yaml
│   ├── services/
│   ├── configmaps/
│   └── kustomization.yaml
├── overlay/
│   ├── prod/
│   │   ├── patches/
│   │   │   ├── pimcore-replicas.yaml    # 4 نسخ
│   │   │   ├── resource-limits.yaml      # CPU/ذاكرة أعلى
│   │   │   └── env-secrets.yaml          # أسرار الإنتاج
│   │   └── kustomization.yaml
│   ├── staging/
│   │   ├── patches/
│   │   │   ├── pimcore-replicas.yaml    # نسخة واحدة
│   │   │   └── resource-limits.yaml      # حدود أقل
│   │   └── kustomization.yaml
│   └── dev/
│       └── kustomization.yaml

المانيفستات الأساسية تعرّف البنية المشتركة. الطبقات تعدّل الفروقات الخاصة بكل بيئة (النسخ، حدود الموارد، الأسرار، النطاقات). نفس التطبيق، تكوين مختلف لكل بيئة.

متى ECS Fargate أفضل

اخترنا ECS Fargate + Lambda لمنصة تجارة إلكترونية بدل Kubernetes. الأسباب:

عمليات أبسط. ما في ترقيات كلستر، ما في إدارة nodes، ما في تكوين RBAC. ECS يتعامل مع الجدولة، التوسع، وفحوصات الصحة. الفريق يركز على كود التطبيق، مش البنية التحتية.

توسع أسرع. ECS Fargate يشغّل tasks جديدة بثواني. Kubernetes لازم يجدول pods، وممكن ينتظر توسيع الـ nodes (دقائق)، ويجتاز فحوصات الصحة. لارتفاعات الترافيك، Fargate يستجيب أسرع.

تكلفة أفضل للأحمال المتغيرة. الدفع لكل task شغال، مش لكل node. إذا الترافيك نزل لصفر بالليل، التكاليف تنزل بشكل متناسب. nodes الـ Kubernetes تضل شغالة (وتكلّف) بغض النظر عن الحمل.

// تعريف خدمة ECS (عبر CDK)
const service = new ecs.FargateService(this, 'ApiService', {
    cluster,
    taskDefinition,
    desiredCount: 2,
    assignPublicIp: false,
    vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
    circuitBreaker: { rollback: true },  // رجوع تلقائي عند فشل النشر
    capacityProviderStrategies: [
        { capacityProvider: 'FARGATE_SPOT', weight: 2 },  // 66% spot
        { capacityProvider: 'FARGATE', weight: 1 },        // 33% on-demand
    ],
});

// التوسع التلقائي
const scaling = service.autoScaleTaskCount({ minCapacity: 2, maxCapacity: 10 });
scaling.scaleOnCpuUtilization('CpuScaling', { targetUtilizationPercent: 70 });
scaling.scaleOnRequestCount('RequestScaling', {
    targetGroup,
    requestsPerTarget: 1000,
});

Lambda للأحمال Event-Driven

دوال Lambda تتعامل مع الأحمال المدفوعة بالأحداث اللي ما تبرر سيرفس دائم:

// Lambda لمعالجة الـ webhooks
const webhookHandler = new lambda.Function(this, 'WebhookHandler', {
    runtime: lambda.Runtime.NODEJS_20_X,
    handler: 'webhook.handler',
    timeout: cdk.Duration.seconds(30),
    memorySize: 256,
    environment: {
        TABLE_NAME: table.tableName,
        QUEUE_URL: queue.queueUrl,
    },
});

// API Gateway يشغّل Lambda
const api = new apigateway.RestApi(this, 'WebhookApi');
api.root.addResource('webhook').addMethod('POST',
    new apigateway.LambdaIntegration(webhookHandler)
);

الهجين: ECS + Lambda

البنية اللي نستخدمها أكثر شي لمنصات التجارة الإلكترونية:

الـ Commerce API والـ workers يشتغلون على Fargate (دائم، طويل الأمد). كل شي event-driven يشتغل على Lambda (ادفع لكل استخدام، توسع تلقائي). التوليفة أرخص من تشغيل كل شي على Kubernetes وأبسط من تشغيل كل شي على Lambda.

عزل المستأجرين المتعددين على Kubernetes

إذا عندك SaaS متعدد المستأجرين على Kubernetes، عزل المستأجرين يحتاج تكوين صريح:

عزل الـ Namespace

# Network Policy: الـ pods بـ namespace الـ tenant-a بس يقدرون يتكلمون مع بعض
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
    name: tenant-isolation
    namespace: tenant-a
spec:
    podSelector: {}
    policyTypes:
        - Ingress
        - Egress
    ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    tenant: tenant-a
    egress:
        - to:
            - namespaceSelector:
                matchLabels:
                    tenant: tenant-a
        - to:  # السماح بحل DNS
            - namespaceSelector: {}
              podSelector:
                matchLabels:
                    k8s-app: kube-dns
            ports:
                - port: 53
                  protocol: UDP

Resource Quotas

امنع مستأجر واحد من استهلاك كل موارد الكلستر:

apiVersion: v1
kind: ResourceQuota
metadata:
    name: tenant-a-quota
    namespace: tenant-a
spec:
    hard:
        requests.cpu: "4"          # أقصى 4 نوى CPU
        requests.memory: "8Gi"     # أقصى 8GB رام
        limits.cpu: "8"
        limits.memory: "16Gi"
        pods: "20"                 # أقصى 20 pod
        services: "10"
        persistentvolumeclaims: "5"

مشكلة الجار المزعج

حتى مع resource quotas، حمل I/O ثقيل لمستأجر واحد يقدر يأثر على الباقي على نفس الـ node. الحلول:

لأغلب تطبيقات SaaS، الـ nodes المشتركة مع resource quotas كافية. احجز مجموعات nodes مخصصة لمستأجرين enterprise مع متطلبات عزل صارمة. لأنماط عزل طبقة التطبيق (API middleware، فلاتر الاستعلام، السياسات)، شوف دليل تصميم Multi-Tenant.

تحسين التكاليف

Spot Instances (Kubernetes)

الـ Spot instances أرخص بـ 60-90% من on-demand. استخدمها للـ stateless workloads اللي تتحمل الانقطاع:

# EKS Managed Node Group مع Spot Instances
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
    name: production
    region: eu-central-1
managedNodeGroups:
    - name: spot-workers
      instanceTypes: ["t3.large", "t3.xlarge", "m5.large"]
      spot: true
      minSize: 2
      maxSize: 10
      desiredCapacity: 3
      labels:
          node-type: spot
    - name: on-demand-workers
      instanceTypes: ["t3.large"]
      minSize: 1
      maxSize: 3
      desiredCapacity: 1
      labels:
          node-type: on-demand

شغّل الـ stateless services (خوادم الويب، workers) على spot. شغّل الـ stateful services (قواعد البيانات، محركات البحث) على on-demand. استخدم pod anti-affinity لتوزيع النسخ على عدة nodes حتى انقطاع spot ما ينزّل كل النسخ.

التحجيم الصحيح

أغلب الفرق تبالغ بالتخصيص. سيرفس يطلب 1 CPU و 2GB رام ممكن فعلياً يستخدم 0.2 CPU و 400MB. التخصيص الزائد يضيع فلوس. التخصيص الناقص يسبب OOM kills.

# فحص الاستخدام الفعلي للموارد مقابل الطلبات
kubectl top pods -n production
# مقارنة مع طلبات الموارد بمانيفستات النشر
kubectl get pods -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].resources.requests}{"\n"}{end}'

استخدم Vertical Pod Autoscaler (VPA) بوضع التوصية لتشوف شو pods الخاصة فيك فعلاً تحتاج:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
    name: pimcore-vpa
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: pimcore
    updatePolicy:
        updateMode: "Off"  # توصية فقط، لا تطبق تلقائياً

التوسع التلقائي

الـ Horizontal Pod Autoscaler (HPA) يوسّع بناءً على المقاييس:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
    name: pimcore-hpa
spec:
    scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: pimcore
    minReplicas: 2
    maxReplicas: 8
    metrics:
        - type: Resource
          resource:
              name: cpu
              target:
                  type: Utilization
                  averageUtilization: 70
        - type: Resource
          resource:
              name: memory
              target:
                  type: Utilization
                  averageUtilization: 80
    behavior:
        scaleDown:
            stabilizationWindowSeconds: 300  # انتظر 5 دقائق قبل التقليص
            policies:
                - type: Pods
                  value: 1
                  periodSeconds: 60  # أزِل أقصى pod واحد بالدقيقة

الـ stabilizationWindowSeconds يمنع التذبذب (توسع، تقليص، توسع). الـ scaleDown.policies تمنع التقليص العدواني اللي ممكن يسبب مشاكل سعة عند الارتفاع التالي بالترافيك.

حقل ألغام الشبكات

شبكات Kubernetes هي المكان اللي أغلب الفرق تعلق فيه.

Ingress Controllers

لأغلب منصات SaaS، Nginx Ingress + cert-manager (Let's Encrypt) كافي. أضف service mesh (Istio، Linkerd) بس إذا تحتاج mTLS بين السيرفسات، توجيه ترافيك متقدم (canary deployments، traffic splitting)، أو observability مفصلة بين السيرفسات.

مشاكل حل DNS

مشكلة إنتاج شائعة: الـ pods ما تقدر تحل أسماء المضيفين الخارجيين لأن تكوين DNS غلط.

# إيجاد IP خدمة DNS الصحيح بالكلستر
kubectl get svc -n kube-system kube-dns -o jsonpath='{.spec.clusterIP}'

# إذا إعدادات nginx تشير لـ resolver، استخدم هالـ IP
# خطأ شائع: استخدام 10.0.0.10 لما الـ DNS الفعلي على 10.2.0.10

إذا nginx sidecar الخاص فيك يوجه طلبات لسيرفسات خارجية (تخزين سحابي، APIs خارجية)، توجيه الـ resolver لازم يشير لـ IP الـ kube-dns بالكلستر، مش لقيمة مكتوبة يدوياً.

الأخطاء الشائعة

1. اختيار Kubernetes لأن "الكل يستخدمه." إذا عندك 3 سيرفسات وفريق صغير، ECS Fargate أبسط وأرخص. Kubernetes يصير منطقي من 7+ سيرفسات مع فريق منصة.

2. بدون GitOps. kubectl apply من لابتوب المطور مش استراتيجية نشر. استخدم Flux أو ArgoCD للنشر القائم على المطابقة.

3. كلستر مشترك بدون resource quotas. مستأجر واحد أو pod خرج عن السيطرة يستهلك كل الموارد. كل namespace يحتاج resource quotas.

4. كل الـ pods على instances عند الطلب. الـ Spot instances أرخص بـ 60-90% للـ stateless workloads. استخدمها للويب سيرفرات والـ workers.

5. التخصيص الزائد للموارد. Pods تطلب 2 CPU وتستخدم 0.2 CPU تضيع فلوس. استخدم توصيات VPA للتحجيم الصحيح.

6. التوسع التلقائي العدواني. التقليص السريع يسبب مشاكل سعة عند الارتفاع التالي. استخدم نوافذ استقرار وسياسات تقليص تدريجية.

7. بدون network policies. بدونها، أي pod يقدر يتكلم مع أي pod ثاني بالكلستر. بإعداد multi-tenant، هذي مشكلة أمنية.

8. تجاهل ترقيات الكلستر. إصدارات Kubernetes توصل نهاية عمرها كل 12-15 شهر. خطط لنوافذ ترقية ربع سنوية. التأخر يخلق ثغرات أمنية ويمنع ميزات جديدة.

9. خلط stateful و stateless على نفس الـ nodes. pod الـ OpenSearch وpod الويب سيرفر يتنافسون على I/O على نفس الـ node يضعف الاثنين. استخدم node affinity لفصلهم.

10. بدون sealed secrets. وضع أسرار عادية بـ Git هو اختراق أمني ينتظر يصير. استخدم Sealed Secrets أو External Secrets Operator أو AWS Secrets Manager.

أهم النقاط

• Kubernetes للمنصات المعقدة متعددة السيرفسات. أكثر من 7 سيرفسات، stateful workloads، متطلبات multi-cloud، وفريق يقدر يتعامل مع الـ overhead التشغيلي.

• ECS Fargate للأحمال الحاوية الأبسط. نفس الحاويات، تعقيد تشغيلي أقل. أفضل لفرق بدون خبرة Kubernetes.

• Lambda للأحمال المدفوعة بالأحداث. Webhooks، مهام مجدولة، معالجة الصور، وأي حمل متفجر وقصير العمر. صفر تكلفة بوقت السكون.

• الهجين (ECS + Lambda) عادةً هو أفضل جواب. سيرفسات دائمة على Fargate، شغل event-driven على Lambda. أرخص من كل شي Kubernetes، أبسط من كل شي Lambda.

• GitOps مع Flux يعطي مطابقة حقيقية. مش بس أتمتة نشر. اكتشاف انحراف، سجل مراجعة، ورجوع عبر git revert.

• Spot instances توفر 60-90% على الـ stateless workloads. شغّل خوادم الويب والـ workers على spot. شغّل قواعد البيانات ومحركات البحث على on-demand.

• عزل المستأجرين المتعددين يحتاج network policies و resource quotas. عزل الـ namespace لوحده ما يكفي. افرض حدود الشبكة وحدود الموارد لكل مستأجر.

نحنا ننشر وندير بنية Kubernetes و ECS و Lambda التحتية كجزء من خدماتنا السحابية. إذا تحتاج مساعدة باختيار استراتيجية compute أو تحسين الـ deployment الحالي، تكلم مع فريقنا أو اطلب عرض سعر. شوف كمان دليل ترقية Pimcore لأنماط نشر Kubernetes الخاصة بـ Pimcore.