ما هي Deployments وReplicaSets، وكيف تعمل التحديثات المتدرّجة (rolling updates) وعمليات التراجع (rollbacks)؟

Question

IT Interview Practice · Accepted Answer

الـ **Deployment** هو الـ controller القياسي لتشغيل التطبيقات عديمة الحالة (stateless). يدير **ReplicaSets**، ويُبقي الـ ReplicaSet عدداً محدّداً من الـ Pods المتطابقة قيد التشغيل. أنت تعدّل الـ Deployment؛ وهو يُنسّق **التحديثات المتدرّجة (rolling updates)** و**التراجعات (rollbacks)** نيابةً عنك.

## التسلسل الهرمي

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## manifest الخاص بـ Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # بحدّ أقصى Pod واحد متوقّف أثناء التحديث
      maxSurge: 1            # بحدّ أقصى Pod واحد زائد فوق العدد المرغوب
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## التحديث المتدرّج: تغيير النسخة دون توقّف

```bash
kubectl set image deployment/web web=myapp:2.0   # إطلاق تحديث متدرّج
kubectl rollout status deployment/web            # متابعة التقدّم
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## التراجع عندما يسوء إصدار

```bash
kubectl rollout history deployment/web       # سرد النُّسخ (revisions)
kubectl rollout undo deployment/web          # التراجع إلى النسخة السابقة
kubectl rollout undo deployment/web --to-revision=3
```

ولأن الـ ReplicaSet القديم يُحتفَظ به (مُقلَّصاً إلى 0)، يكون التراجع سريعاً: يكتفي Kubernetes بتوسيع الـ ReplicaSet السابق مجدّداً وتقليص الجديد.

## التوسيع (scaling)

```bash
kubectl scale deployment/web --replicas=10   # تغيير العدد المرغوب
```

## لماذا يهم

الـ Deployments هي حصان العمل لتشغيل التطبيقات عديمة الحالة على Kubernetes، لذا فإن فهمها وعلاقتها بالـ ReplicaSets معرفةٌ يومية ضرورية. التّطبيق يكمن في الاستنتاج المفتاحي: أنت تدير **Deployment**، وهو يملك **ReplicaSets** (واحداً لكل نسخة)، وكل ReplicaSet يضمن تشغيل عدد محدّد من الـ Pods المتطابقة — سلسلة من حلقات المطابقة (reconciliation) تحقّق معاً المعالجة الذاتية وعدداً ثابتاً من النسخ. القوّة الحقيقية في كيفية تعامل الـ Deployment مع التغيير: فالـ **التحديث المتدرّج** يُنشئ ReplicaSet جديداً وينقل الـ Pods من القديم إلى الجديد تدريجياً، محكوماً بـ `maxSurge` و`maxUnavailable`، بحيث تُحفَظ السعة — وبالاقتران مع فحوص readiness التي تحدّد أيّ الـ Pods تتلقّى حركة المرور — يجري الإصدار **دون توقّف**. ولأن الـ ReplicaSet السابق يُحتفَظ به (مُقلَّصاً إلى صفر بدلاً من حذفه)، يكون **التراجع** سريعاً وآمناً: يكتفي `kubectl rollout undo` بتوسيع النسخة القديمة مجدّداً وتقليص السيّئة، وهو بالضبط ما تلجأ إليه حين تسيء نسخةٌ التصرّف. إن فهم هذه الآليات — إضافةً إلى كيفية التوسيع (`kubectl scale`) وفحص التقدّم (`kubectl rollout status/history`) — أساسٌ لشحن البرمجيات بأمان على Kubernetes، ويعكس النموذج التصريحي المُوجَّه بالـ controllers الذي يحدّد كيفية عمل المنصّة في الإنتاج.

التسلسل الهرمي

manifest الخاص بـ Deployment

التحديث المتدرّج: تغيير النسخة دون توقّف

التراجع عندما يسوء إصدار

التوسيع (scaling)

لماذا يهم

أسئلة ذات صلة