Kubernetes Probes بالعربي: امنع restart loop قبل الإنتاج
مستوى القارئ: متوسط
هتخرج من المقال بإعداد واضح يخلي Kubernetes يستنى التطبيق وهو بيبدأ، يفتح الترافيك في الوقت الصح، ويعمل restart بس لما العملية تبقى فعلًا ميتة.
المشكلة باختصار
الطريقة الشائعة الغلط هي إنك تحط livenessProbe بسرعة وتفتكر إنك كده زودت الاعتمادية. اللي بيحصل فعلاً: التطبيق يبدأ ببطء، الـ probe يفشل أول 10 أو 15 ثانية، Kubernetes يقتله، وبعدها يبدأ من الصفر. النتيجة restart loop من غير bug حقيقي في الكود.
الافتراض إن عندك خدمة Web داخل Kubernetes، زمن الإقلاع الطبيعي بين 20 و35 ثانية، والـ endpoint الصحي اسمه /healthz. لو عندك موقع عليه 50K زيارة يوميًا، غلط صغير هنا ممكن يخلي rollout جديد يعمل downtime واضح لمدة 3 إلى 5 دقائق بدل ما يمر بسلاسة.
افهم الفرق بمثال بسيط
ركز في المثال ده: مطعم لسه بيفتح الصبح. startupProbe هو سؤال: هل المطبخ خلص تجهيز؟ readinessProbe هو سؤال: هل نستقبل طلبات العملاء دلوقتي؟ livenessProbe هو سؤال أخطر: هل المطعم قفل ومحتاج نعيد تشغيله؟ لو سألت السؤال التالت بدري، هتقفل المطعم وهو لسه بيرتب الترابيزات.
علميًا، Kubernetes يستخدم probes من kubelet عشان يعرف حالة الـ container. حسب توثيق Kubernetes الرسمي، startupProbe يعطل فحوصات liveness وreadiness إلى أن ينجح. دي نقطة مهمة لأنها تمنع قتل التطبيق أثناء الإقلاع البطيء. مصدر: Kubernetes: Configure Liveness, Readiness and Startup Probes.
الإعداد العملي
أفضل طريقة هنا: قيس زمن الإقلاع، ثم ادي startupProbe نافذة أكبر من الزمن الطبيعي بنسبة أمان 30% تقريبًا. لو التطبيق يبدأ في 25 ثانية، خلي نافذة startup حوالي 40 إلى 60 ثانية. بعد النجاح، readiness يفتح الترافيك، وliveness يحمي التشغيل الطويل.
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-api
spec:
replicas: 3
selector:
matchLabels:
app: checkout-api
template:
metadata:
labels:
app: checkout-api
spec:
containers:
- name: app
image: ghcr.io/example/checkout-api:1.8.0
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 5
failureThreshold: 12
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
