عمليات النشر المتقدمة في Kubernetes: الاستراتيجيات وأفضل الممارسات

استراتيجيات النشر في Kubernetes

توفّر عمليات النشر (Deployments) في Kubernetes استراتيجيات مختلفة لتحديث تطبيقاتك. ويُعدّ اختيار الاستراتيجية المناسبة أمرًا حاسمًا لتقليل انقطاعات الخدمة وضمان انتقال سلس.

استراتيجية الاستبدال (Recreate)

تقوم استراتيجية الاستبدال بإيقاف جميع نسخ الإصدار القديم قبل تشغيل النسخ الجديدة. وهي الاستراتيجية الافتراضية.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

المزايا:

• سهلة الفهم وتصحيح الأخطاء
• تضمن تشغيل إصدار واحد فقط في كل مرة

العيوب:

• توقّف الخدمة أثناء النشر
• لا يوجد تراجع تلقائي (rollback) في حال الفشل

حالات الاستخدام:

• التطبيقات التي لا تدعم تشغيل عدة إصدارات في آنٍ واحد
• بيئات التطوير أو الاختبار
• التطبيقات ذات الاعتماديات الحرجة على قاعدة البيانات

استراتيجية التحديث التدريجي (RollingUpdate)

تستبدل استراتيجية التحديث التدريجي النسخ القديمة بنسخ جديدة بشكل تدريجي، مع الحفاظ على حدّ أدنى من النسخ المتاحة.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # العدد الأقصى للـ pods الإضافية المسموح بها
      maxUnavailable: 0  # العدد الأقصى للـ pods غير المتاحة أثناء التحديث
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

المزايا:

• لا يوجد توقّف للخدمة
• تراجع تلقائي (rollback) في حال الفشل
• تحكّم دقيق في عملية التحديث

العيوب:

• أكثر تعقيدًا في الإعداد
• قد تتطلب موارد أكثر أثناء التحديث

حالات الاستخدام:

• التطبيقات في بيئة الإنتاج
• الخدمات التي تتطلب توافرية عالية
• التطبيقات التي تدعم تشغيل عدة إصدارات في آنٍ واحد

استراتيجية Blue/Green Deployment

رغم أن Kubernetes لا يوفّر بشكل أصلي نشر blue/green، يمكنك تطبيقه باستخدام الخدمات (Services) وعمليات النشر (Deployments).

# نشر "Blue" (الإصدار الحالي)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# نشر "Green" (الإصدار الجديد)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# الخدمة التي تشير إلى الإصدار النشط
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: blue  # غيّرها إلى "green" للتحويل إلى الإصدار الجديد
  ports:
  - port: 80
    targetPort: 8080

المزايا:

• تحويل فوري بين الإصدارات
• لا يحدث تدهور في الخدمة أثناء التحديث
• تراجع بسيط بمجرد تغيير محدِّد (selector) الخدمة

العيوب:

• يتطلب ضعف الموارد أثناء النشر
• إعداد أكثر تعقيدًا
• يتطلب إدارة يدوية أو سكربت لإجراء التحويل

حالات الاستخدام:

• التطبيقات الحرجة ذات نوافذ الصيانة الصارمة
• الخدمات التي تتطلب تحويلًا سريعًا عند حدوث مشكلة
• التطبيقات ذات الاعتماديات المعقدة بين الإصدارات

استراتيجية Canary Deployment

يعرّض نشر canary جزءًا صغيرًا من حركة المرور للإصدار الجديد قبل نشره بالكامل.

# النشر الرئيسي (الإصدار الحالي)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-main
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      version: main
  template:
    metadata:
      labels:
        app: myapp
        version: main
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# نشر canary (الإصدار الجديد)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      version: canary
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
      - name: myapp
        image: myapp:1.1
---
# الخدمة التي توزّع حركة المرور
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

المزايا:

• اختبار في بيئة الإنتاج بأقل قدر من المخاطر
• اكتشاف مبكر للمشكلات
• إمكانية جمع المقاييس قبل النشر الكامل

العيوب:

• إعداد أكثر تعقيدًا
• يتطلب مراقبة دقيقة خلال مرحلة canary
• قد يتطلب أدوات إضافية لتوجيه حركة المرور

حالات الاستخدام:

• التطبيقات ذات العدد الكبير من المستخدمين
• الخدمات التي تتطلب التحقق في بيئة الإنتاج
• عمليات النشر عالية المخاطر

إدارة عمليات التراجع (Rollbacks)

تُعدّ عمليات التراجع ضرورية للحفاظ على توافر تطبيقك عند حدوث مشكلة في إصدار جديد.

التراجع التلقائي مع فحوصات الصحة (Health Checks)

اضبط فحوصات الصحة (liveness وreadiness) حتى يتمكن Kubernetes من اكتشاف المشكلات تلقائيًا وإجراء التراجع.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

التراجع اليدوي باستخدام kubectl

يمكنك إجراء تراجع يدوي إلى إصدار سابق باستخدام الأمر kubectl rollout undo:

# التراجع إلى الإصدار السابق
kubectl rollout undo deployment/app-deployment

# التراجع إلى إصدار محدد
kubectl rollout undo deployment/app-deployment --to-revision=2

أفضل الممارسات لعمليات النشر

1. استخدم وسوم صور (Image Tags) محددة

تجنّب استخدام latest كوسم للصورة، لأن ذلك يصعّب تتبّع الإصدارات وقد يؤدي إلى عمليات نشر غير قابلة لإعادة الإنتاج.

# يُفضّل تجنّبه
image: myapp:latest

# موصى به
image: myapp:1.0.2

2. حدّد حدود الموارد

حدّد حدود الموارد لمنع أي pod من استهلاك موارد مفرطة والتأثير على بقية الـ pods.

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

3. استخدم قواعد Anti-Affinity

انشر الـ pods على عُقد (nodes) مختلفة لتحسين التوافرية.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - myapp
          topologyKey: kubernetes.io/hostname

4. طبّق استراتيجيات التوسّع

اضبط التوسّع الأفقي التلقائي (HPA) لتعديل عدد النسخ (replicas) تلقائيًا بحسب الحمل.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5. استخدم ConfigMaps وSecrets

افصل إعدادات التطبيق عن الشيفرة لتسهيل التعديلات دون إعادة بناء الصورة.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: base64encodedpassword
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

مثال على نشر متكامل

إليك مثالًا متكاملًا لعملية نشر في Kubernetes تطبّق أفضل الممارسات:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.2
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - myapp
              topologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

الخلاصة

توفّر عمليات النشر المتقدمة في Kubernetes مرونة كبيرة لإدارة تحديثات تطبيقاتك. فباختيار استراتيجية النشر المناسبة واتباع أفضل الممارسات، يمكنك ضمان انتقال سلس بين الإصدارات مع الحفاظ على توافر خدمتك.

في المقال القادم، سنستعرض إدارة الأسرار (Secrets) والإعدادات في Kubernetes، وهو جانب حاسم لتأمين تطبيقاتك.