ابدأ بخريطة العُقد
في مثال افتراضي، يعمل تطبيق على ثلاث نسخ ويمكن جدولته في منطقتين. افحص وسوم العُقد المؤهلة، وطابق topologyKey مع وسم المنطقة الفعلي. راجع محدد الوسوم حتى يحسب نسخ التطبيق المعني.
اختبر مع نسخة جديدة
سجّل توزيع النسخ قبل التوسع وبعده. غيّر عدد النسخ تدريجيًا في بيئة اختبار وراقب الفرق بين المناطق. يُفسّر maxSkew مع طريقة التعامل المختارة والحد الأدنى المستخدم في حساب التوزيع.
شخّص Pending
افحص أحداث المجدول. راجع توفر الموارد وشروط التوافق مع العُقد إلى جانب قيد التوزيع. جرّب سيناريو فقدان أهلية إحدى المناطق قبل أن تقرر استخدام DoNotSchedule أو تفضيل الجدولة باستخدام ScheduleAnyway.
اختر معيار قبول واضحًا
حدد أقصى انحراف يقبله الفريق، والسعة المطلوبة أثناء فقدان منطقة، والإنذار المناسب لو تأخرت الجدولة. وثّق النتيجة من التطبيق الفعلي لأن وجود منطقتين وحده لا يثبت توافر الموارد في كل منطقة.
حالة للتحقق قبل التسليم
في تمرين يدوي، قارن توزيع نسختين مقابل ثلاث ثم عطّل الجدولة مؤقتًا في إحدى المناطق التجريبية. سجّل ما إذا كانت النسخة الجديدة تنتظر، وما إذا كانت النسخ الموجودة تستمر في الخدمة.
مراجع وروابط
راجع Kubernetes: Pod Topology Spread Constraints، واطلع على حلول فايندو ذات الصلة.
