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 نفسه.
التحقق من إنك مش مستخدمه:
]]>