مستوى المقال: للمحترف
لو بتـ deploy نسخة جديدة على 100% من المستخدمين دفعة واحدة، أول bug في query بيكلّفك 100% من الترافيك. الطريقة الصح: تبدأ بـ 5% فقط، تراقب P95 ومعدل الأخطاء، وتتقدّم لو الأرقام نضيفة. Istio VirtualService بـ 14 سطر YAML بيعمل ده بدون كود إضافي وبدون تعديل في CI/CD.
Istio Canary Deployment: تقسيم الترافيك بدون مغامرة الإصدار الكامل
المشكلة باختصار
في الفِرق اللي مفيش عندها traffic splitting حقيقي، أي release بتاعت backend بيمر بسيناريو واحد: إما الإصدار v2 شغّال على كل الطلبات، أو نـ rollback كله بعد ما المستخدمين بلّغوا. ده بيخلّي وقت اكتشاف المشكلة 7 إلى 14 دقيقة في المتوسط، وفي خلال الفترة دي بيتسجّل آلاف الـ 5xx على Sentry. الافتراض إن "الـ tests كافية" بيسقط أول مرة query بيخرج بأرقام مختلفة على بيانات الإنتاج اللي ما كانتش في الـ staging.
قبل ما ندخل في YAML — مثال للمبتدئ علشان توضّح الفكرة
تخيّل إنك فاتح مطعم برجر شعبي و عملت وصفة جديدة للصوص. عندك خياران:
- الخيار السيئ: تستبدل الصوص القديم بالكامل في كل الفروع يوم الجمعة الساعة 8 مساءً. لو الزبائن ما عجبهمش، فقدت ليلة الجمعة كلها.
- الخيار الصح: تقدّم الصوص الجديد لـ 5 زبائن من كل 100 لمدة ساعة. تشوف ردود الفعل، تقيس عدد الشكاوى، وبعدين تطلع لـ 25%، وبعدين 50%، وبعدين 100%.
Istio بيلعب دور النادل اللي بيقرّر بدقة مين ياخد الصوص الجديد. مفيش حد بيغيّر الكود في المطبخ ولا في القائمة، بس النادل عنده تعليمات: "5% من الطاولات ياخدوا الوصفة v2". ده weighted traffic routing، وهو نفس الفكرة بالظبط لكن على HTTP requests بدل صحون البرجر.
التعريف العلمي الدقيق
Istio service mesh بيعتمد على Envoy proxy موجود كـ sidecar جنب كل pod (في sidecar mode) أو كـ ztunnel على مستوى الـ node (في ambient mode). الـ proxy ده هو اللي بيشوف كل الترافيك الداخل والخارج من الـ pod. لمّا تعرّف VirtualService فيها weight: 95 و weight: 5، الـ proxy بيستخدم weighted random algorithm بيوزّع الطلبات احصائياً بالنسبة دي. التوزيع بيكون stateless لكل request افتراضياً، وعشان كده محتاج ConsistentHash لو عايز نفس المستخدم يفضل على نفس النسخة (مهم لو في session state على مستوى الذاكرة).
الـ DestinationRule بيعرّف الـ subsets الفعلية اللي الـ VirtualService بيشاور عليها. الـ subset مش deployment، هو label selector على pods موجودة في نفس الـ Service. ده معناه ممكن يكون عندك Deployment واحد فيه pods بـ version=v1 و pods بـ version=v2، ومفيش Service ثاني محتاج تعمله. ده الفرق الجوهري بين Istio و حل Ingress عادي.
