Kubernetes 1.36: ملخص القرارات اللي لازم تاخدها بالظبط

المشكلة باختصار

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

1) HPA Scale-to-Zero بقى افتراضي: ليه ده مهم

تخيّل عندك صنبور مياه في حوش فاضي طول الليل. لو الصنبور بيقطّر ولو نقطة كل ثانية، إنت بتدفع مياه بدون فايدة. الـ Pod اللي شغّال 24 ساعة وما بيخدمش طلبات في الليل هو بالظبط نفس الصنبور ده. الفاتورة بتنزل في حسابك بدون أي قيمة.

الشرح العلمي: الـ Horizontal Pod Autoscaler (HPA) هو متحكم في Kubernetes بيقيس مقاييس زي CPU أو ذاكرة أو metric خارجي، وبيغيّر عدد الـ replicas بناءً على عتبات. قبل الإصدار 1.36 كان أقل عدد ينفع توصله صفر بس عبر feature gate إسمه HPAScaleToZero اللي ظهر في 1.16 وفضل alpha 7 سنين. في 1.36 بقى enabled by default. القيد الوحيد إنك محتاج external metric source زي KEDA علشان يقدر يرجّع الكلاستر لفوق من صفر، لإن الـ HPA بنفسه ما بيقدرش يقيس CPU على pod مش موجود.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
    - type: External
      external:
        metric:
          name: rabbitmq_queue_messages
          selector:
            matchLabels:
              queue: jobs
        target:
          type: AverageValue
          averageValue: "5"

الـ trade-off هنا: بتوفّر 40-70% من فاتورة الـ compute على workloads متذبذبة (cron jobs، dev environments، internal tools). بتدفع cold start ~5-15 ثانية كل ما حد يستخدم الخدمة بعد فترة سكون. ده مش مناسب لـ APIs بترد على مستخدمين مباشرين بعتبة P99 تحت ثانية.

2) gitRepo Volume اتشال نهائيًا: لو لسه بتستخدمه، الكلاستر مش هيشتغل

الـ gitRepo volume كان بيخليك تعمل clone لـ Git repo داخل Pod وقت الإقلاع. الموضوع كان مغرٍ للـ config files والـ static content، بس فيه ثغرة معروفة من 2018: أي حد عنده صلاحية يعدّل في الـ repo يقدر يحقن أوامر تتنفّذ على الـ node نفسه.

التحقق من إنك مش مستخدمه:

kubectl get pods --all-namespaces -o json \
  | jq '.items[] | select(.spec.volumes[]?.gitRepo) | "\(.metadata.namespace)/\(.metadata.name)"'

البديل: استخدم init container بيعمل git clone على emptyDir، أو الأفضل استخدم ConfigMap/Secret لو المحتوى نصّي صغير، أو CSI driver زي git-sync sidecar من kubernetes-sigs لو محتاج تحديث دوري.

3) IPVS mode في kube-proxy راح: شوف بدائلك دلوقتي

قبل ما ندخل في الحل، خد المثال البسيط ده: تخيّل مكتب فيه موظف استقبال بيوزّع مكالمات على 50 موظف. في طريقة قديمة الموظف عنده دفتر ورقي بيكتب الاسم والامتداد لكل مكالمة، وكل مرة بيقعد يقلّب الصفحات. الطريقة دي هي iptables. الطريقة الأحدث (IPVS) شبه برنامج كمبيوتر بيلاقي الامتداد في جزء من الثانية. الطريقة الأحدث منها (nftables و eBPF) جاية بمزايا أمنية أكتر وسرعة أعلى.

الشرح العلمي: IPVS كان وسيلة لتوزيع الـ traffic داخل الكلاستر بكفاءة أعلى من iptables الكلاسيكي، خصوصًا في الكلاسترات الكبيرة (5000+ service). اتقاعد في 1.35 وراح في 1.36. البدائل الرسمية:

• nftables backend داخل kube-proxy: شغّاله من 1.31 stable، أداء قريب من IPVS مع syntax أحدث.
• Cilium / eBPF: بيشيل kube-proxy خالص ويقدّم observability أعمق، الثمن: تعقيد إضافي وتعلّم XDP/eBPF.

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "nftables"

4) Mutating Admission Policies بقت GA: قلّل الـ webhooks اللي بتفتح يومك

قبل ما نتعمّق، خد مثال للمبتدئين: تخيّل إن كل ما حد يدخل المبنى لازم يمرّ على موظف أمن خارجي يكتب اسمه ويوقّعه. الموظف لو غاب أو قطع نفسه، المبنى بيقفل. الـ mutating webhook التقليدي شغّال نفس الكلام: كل API request بيمر على HTTP service خارجي تعدّل عليه. لو السيرفس ده وقع، نص حركة الكلاستر بتتعطّل.

الشرح العلمي: الـ Mutating Admission Policies (KEP-3962) بتنقل المنطق ده من webhook خارجي لتعبير CEL (Common Expression Language) بيتنفّذ داخل الـ API server. ده بيقلّل latency متوسطة من ~30-80ms لكل request لـ ~1-3ms، وبيشيل نقطة فشل كاملة من البنية.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: inject-team-label
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        resources: ["deployments"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{
            metadata: Object.metadata{
              labels: {"team": "platform"}
            }
          }

الـ trade-off هنا: بتربح ثبات وسرعة، بتخسر مرونة المنطق المعقّد. CEL مش لغة كاملة، فلو محتاج تروح تنادي خدمة خارجية أو تعمل lookup من DB، لازم تفضل على webhooks.

5) Ingress NGINX اتقاعد رسميًا: مش بيتشال من 1.36، بس بقى بدون patches

دي الجزئية اللي ناس كتير بتفهمها غلط. Ingress NGINX ما اتشالش من Kubernetes 1.36، الـ controller لسه بيتنزّل وشغّال. اللي حصل: في 24 مارس 2026 الـ Kubernetes SIG Network والـ Security Response Committee أعلنوا التقاعد الرسمي، يعني مفيش CVE patches بعد كده.

الافتراض إن: لو عندك ingress-nginx production، عندك نافذة ~6 شهور قبل ما أول CVE خطيرة تخليك في موقف صعب. البدائل المقترحة من المجتمع:

• Gateway API + Envoy Gateway / Contour: المعيار الجديد، API أنظف وأقوى لـ traffic splitting.
• InGate: مشروع جديد من نفس فريق ingress-nginx، مبني على Gateway API.
• Traefik / HAProxy Ingress / NGINX Inc commercial: لو بدك تفضل قريب من نفس النموذج.

أرقام الهجرة الواقعية: فريق صغير (3-5 ingress rules بسيطة) بيكمّل الترحيل في يوم. فريق متوسط (50+ rules مع cert-manager وWAF rules مخصّصة) بياخد 2-3 أسابيع. ابدأ في staging دلوقتي مش الشهر الجاي.

متى لا تستخدم هذه الترقية فورًا

لو الكلاستر بتاعك في إنتاج حرج (مالي، صحي، بنية تحتية)، استنى 4-6 أسابيع على الأقل قبل ترقية الإنتاج. الـ minor releases الأولى (1.36.0، 1.36.1) بتطلع فيها bugs دايمًا. اشتغل على staging دلوقتي، أجّل الإنتاج لـ 1.36.3+. وكمان لو لسه على 1.33 أو أقدم، ما تقفزش لـ 1.36 مباشرة - الترقية المدعومة هي step-by-step (n+1 minor) عبر 1.34 ثم 1.35 ثم 1.36.

الخطوة التالية

افتح كلاسترك دلوقتي وشغّل أمرين فقط:

kubectl get pods -A -o json \
  | jq '.items[] | select(.spec.volumes[]?.gitRepo) | .metadata.name' \
  | wc -l

kubectl get cm -n kube-system kube-proxy -o yaml \
  | grep -E 'mode:'

الأول بيقولك كم Pod مرتبط بـ gitRepo، التاني بيقولك إنت على IPVS ولا غيره. لو الناتج صفر و"nftables" أو "iptables"، إنت آمن لتخطّط الترقية. لو غير كده، عندك شغل نقي قبل ما تعمل أي حاجة تانية.

المصادر

• Kubernetes v1.36 Sneak Peek - Kubernetes Blog
• Kubernetes v1.36 Release Highlights - sig-release
• Kubernetes 1.36 Release: New Features, Beta & Stable Changes - PerfectScale
• Kubernetes 1.36 - What you need to know - Cloudsmith
• KEP-2021: Support scaling to/from zero pods
• Kubernetes 1.36: The Release That Said Goodbye to Ingress NGINX