حاوية VPN جانبية تحتاج إلى قاعدة بدء وقاعدة فشل

يبدأ الـ pod حاوية النفق قبل التطبيق وتنجح الطلبات الأولى، وهذه بالضبط الحالة التي تخفي المشكلة. الترتيب يعالج سباقًا واحدًا ولا يقول شيئًا عن الحركة التي يبدأها التطبيق بعد أربع ساعات، بعد أن يفشل النفق. هذان قراران منفصلان. وعادة لا يُصمَّم إلا واحد منهما.

الترتيب لا يحكم إلا الطلب الأول

يدعم Kubernetes دورة حياة حاوية جانبية مبنية من حاويات init قابلة لإعادة التشغيل. داخل هذا النموذج يمكن لمسبار بدء أن يمنع خطوة التهيئة التالية حتى يبلغ النفق عن جاهزيته. هذا تحسن حقيقي، ويستحق استخدامه عن قصد بدلًا من إضافة sleep إلى سكربت نقطة الدخول. البوابة ليست أفضل من الشرط الذي تختبره.

خارج هذا النموذج، تنتمي دلالات الترتيب إلى أي نظام تشغيل أو نظام تبعيات تستخدمه، وليس من الضروري أن تتطابق. قد يبدو نشر منسوخ من منصة أخرى وكأنه ينتظر النفق لأن التطبيق يبدأ ببطء بالمصادفة. هذا ليس الضمان نفسه، ويفشل تحت الحمل.

صرّح بما ترصده البوابة: عملية موجودة، واجهة موجودة، مصافحة اكتملت. كل واحد من هذه ادعاء أضعف من “مسار البيانات إلى الوجهات التي يحتاجها هذا الـ pod يعمل”.

افرض مسار البيانات بدلًا من افتراضه

المسبار فحص في لحظة واحدة، والجدار الناري خاصية تسري بين اللحظات. إذا كان الشرط هو ألا تغادر حركة التطبيق خارج النفق أبدًا، فيجب التعبير عنه في مساحة أسماء الشبكة المشتركة كقاعدة قبول أو إسقاط. ترتيب بدء الحاويات لا يمكنه حمل هذا الشرط. القاعدة وحدها تستطيع.

الحاويات في الـ pod الواحد تتشارك مساحة الأسماء هذه، لذا فإن نقطة الإنفاذ هي مساحة الأسماء نفسها. وكل ما تكتبه يجب أن يترك اتصال النفق الخارجي متاحًا، لأن حجبه لحماية التطبيق يقطع المسار الذي يحتاجه التطبيق.

قرر سياسة الفشل صراحة: هل يجب أن تتوقف حركة التطبيق كليًا عندما يكون النفق غير سليم، أم تستمر وتُوسم كغير محمية؟ كلا الخيارين يمكن الدفاع عنه، وأي منهما ليس ما تحصل عليه ببدء الحاويات بترتيب معين.

اختبر الحركة التي لم تذكرها

خذ طلبًا جديدًا أثناء فشل نفق مضبوط وانظر هل يخرج. ثم كرر الفحص على المسارات التي لا يلمسها اختبار عنوان الخروج أبدًا: تحليل DNS داخل العنقود، ووجهات IPv6، والخدمات التي تُبلغ عبر عناوين داخلية للعنقود بدلًا من الإنترنت العام. هذه هي المسارات التي تستمر في العمل بهدوء بعد موت النفق.

صفحة عنوان الخروج تثبت أن طلبًا واحدًا ذهب حيث توقعت في تلك اللحظة. لا يمكنها جرد المسارات الأخرى، والفجوة بين ما اختبرته وما يمكن للـ pod الوصول إليه هي حيث تعيش الأعطال المثيرة.

كرر الاختبار بعد إعادة تشغيل الحاوية الجانبية وليس فقط بعد بدء نظيف. حاوية نفق أعيد تشغيلها قد تترك مساحة الأسماء بمسارات وسياسة في حالة وسيطة.

اكتب سجل النشر

ثلاث حقائق تنتمي إلى ملاحظات النشر: اختبار الجاهزية وما يرصده، وإجراء الاستعادة عندما يفشل ذلك الاختبار، وقاعدة الإنفاذ التي تحكم الخروج. توثيق الحاوية الجانبية يغطي ميكانيكا دورة الحياة ويترك قرار السياسة لك. هذا التقسيم صحيح، وهو أيضًا سبب غياب السياسة عادة.

فحص صحة يُظن أنه حماية هو أغلى نوع من المؤشرات الخضراء، لأنه يمنع الناس من طرح الأسئلة. تسميته بدقة في التوثيق تكلف جملة واحدة وتمنع ذلك.

أخيرًا، اختبر مسار الاستعادة مرة واحدة والتطبيق يعمل. التصميم الذي يتطلب إعادة إنشاء الـ pod لاستعادة الخروج هو قرار، وينبغي أن يكون قرارًا اتخذته بدلًا من قرار اكتشفته.