Rollouts و Probes و Resources

الهدف من الدرس

ستتعلم كيف تنفذ تحديث آمن، كيف تمنع traffic عن Pod غير جاهز، وكيف تضبط requests و limits حتى يستطيع scheduler اتخاذ قرار صحيح.

الفكرة ببساطة

Kubernetes لا يعرف إن كان تطبيقك جاهزا من الداخل إلا لو أعطيته probes. ولا يعرف أين يضع Pod إلا لو أعطيته requests. لذلك أي Deployment جاد يحتاج rollout strategy و probes و resources.

الفكرة ببساطة

readinessProbe تحمي المستخدمين من Pod غير جاهز. livenessProbe تعيد تشغيل container عالق. startupProbe مفيدة للتطبيقات التي تبدأ ببطء.

YAML كامل

احفظ الملف باسم web-rollout.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-rollout
  labels:
    app: web-rollout
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: web-rollout
  template:
    metadata:
      labels:
        app: web-rollout
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - name: http
              containerPort: 80
          startupProbe:
            httpGet:
              path: /
              port: http
            failureThreshold: 12
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            failureThreshold: 3
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

كيف تفكر في الثلاثة؟

الجزء	السؤال	قرار عملي
Rollout	كيف أحدث بدون downtime؟	maxUnavailable: 0 للتطبيقات الحساسة
readinessProbe	هل Pod جاهز لاستقبال traffic؟	ضع endpoint يعتمد على جاهزية التطبيق
livenessProbe	هل التطبيق عالق ويحتاج restart؟	لا تجعلها حساسة جدا حتى لا تسبب restarts زائدة
resources.requests	ما الحد الأدنى الواقعي؟	استخدم قياسات metrics وليس تخمين فقط
resources.limits	ما الحد الأعلى المقبول؟	انتبه: memory limit قد يسبب OOMKilled

أوامر التحديث

kubectl apply -f web-rollout.yaml
kubectl rollout status deployment/web-rollout
kubectl set image deployment/web-rollout nginx=nginx:1.28
kubectl rollout status deployment/web-rollout
kubectl rollout history deployment/web-rollout

Expected output:

deployment.apps/web-rollout created
deployment "web-rollout" successfully rolled out
deployment.apps/web-rollout image updated
deployment "web-rollout" successfully rolled out

تشخيص فشل Rollout

flowchart TD
  A[Rollout عالق] --> B[kubectl get pods]
  B --> C{Pod status?}
  C -->|ImagePullBackOff| D[راجع image و registry]
  C -->|CrashLoopBackOff| E[راجع logs --previous]
  C -->|Running not Ready| F[راجع readinessProbe]
  C -->|Pending| G[راجع resources والـ events]

أوامر مهمة:

kubectl rollout status deployment/web-rollout --timeout=90s
kubectl describe deployment web-rollout
kubectl get pods -l app=web-rollout
kubectl describe pod -l app=web-rollout
kubectl logs -l app=web-rollout --tail=50

QoS بشكل مختصر

الحالة	متى تحدث؟	النتيجة
Guaranteed	request يساوي limit لكل CPU و memory	أعلى حماية عند ضغط الموارد
Burstable	توجد requests أو limits لكنها غير متساوية	مناسب لمعظم تطبيقات web
BestEffort	لا توجد requests ولا limits	أول المرشحين للطرد عند الضغط

ستجد شرحا أعمق في درس QoS و Eviction.

Lab: Rollout آمن مع probes و resources

المستوى: مبتدئ الوقت: 45 دقيقة الأدوات: kubectl

الهدف: تشغيل Deployment كامل، تحديث image، ثم تشخيص حالة rollout.

Prerequisites

• Cluster محلي يعمل.
• اتصال بالإنترنت لسحب images.

Steps

1. احفظ YAML في web-rollout.yaml.
2. طبق الملف:

kubectl apply -f web-rollout.yaml
kubectl rollout status deployment/web-rollout

3. راقب Pods أثناء التحديث:

kubectl get pods -l app=web-rollout -w

4. من terminal آخر نفذ:

kubectl set image deployment/web-rollout nginx=nginx:1.28
kubectl rollout status deployment/web-rollout

5. جرب rollback:

kubectl rollout undo deployment/web-rollout
kubectl rollout status deployment/web-rollout

Expected output

deployment "web-rollout" successfully rolled out
NAME                           READY   STATUS    RESTARTS
web-rollout-xxxxxxxxxx-aaaaa   1/1     Running   0
web-rollout-xxxxxxxxxx-bbbbb   1/1     Running   0
web-rollout-xxxxxxxxxx-ccccc   1/1     Running   0

Cleanup

kubectl delete -f web-rollout.yaml

الربط بالمشروع النهائي

أي مشروع production-style في نهاية الكورس يجب أن يحتوي readinessProbe و resources على الأقل. بدونها لن تستطيع ضمان rollout آمن أو capacity planning واضح.

اختبر فهمك

لماذا قد يكون `livenessProbe` الخاطئ خطيرا؟

إظهار الإجابة

لأنه قد يعيد تشغيل container سليم لكنه بطيء مؤقتا، فيسبب loop من restarts ويزيد المشكلة بدلا من حلها.