Pod أو عقدة أو عنقود: ما الذي يعيد الـ VPN الجانبي توجيهه فعليًا

يبدو الـ VPN الجانبي داخل Pod في Kubernetes مثل VPN على مستوى المضيف لكن بأخلاق أفضل، والتشابه يتوقف عند حدود مساحة الأسماء. تتشارك الحاويات داخل Pod واحد مساحة أسماء الشبكة، بما في ذلك فضاء العناوين والمنافذ، لذا فإن sidecar يثبّت المسارات والسياسات يغيّر فعليًا إلى أين تذهب حزم التطبيق. ولا يغيّر شيئًا بالنسبة إلى الـ Pods الأخرى على العقدة، ولا يمسّ حزمة العقدة نفسها ما لم تعدّه لذلك. وإتقان هذا الحدّ يحدّد ما يمكنك نشره وما عليك اختباره. والأقسام التالية تتتبعه من مساحة الأسماء إلى الخارج.

مساحة أسماء مشتركة، ونتائج مشتركة

تتخاطب حاويتان داخل Pod واحد عبر loopback وترى الواجهات نفسها، ولهذا يعمل نمط الـ sidecar أصلاً: لا يحتاج التطبيق إلى معرفة أن نفقًا موجود، لأن المسار الذي يحلّ إليه ثُبّت في مساحة الأسماء التي يستخدمها. وتعني الخاصية نفسها أن أخطاء الـ sidecar هي أخطاء التطبيق. فالمسار الذي يلتقط أكثر من اللازم، أو تغيير DNS الذي يشير إلى مُحلِّل داخل النفق، ينطبق فورًا على كل عملية في ذلك الـ Pod. ولا يوجد توجيه لكل حاوية داخل مساحة أسماء مشتركة، لذا لا يمكن حصر sidecar في عملية واحدة.

هذه هي الآلية التي يجب أن تبقى في الذهن أثناء المراجعة: نطاق الأثر هو الـ Pod، لا العقدة ولا العنقود.

ما لا يصل إليه الـ sidecar

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

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

خطة المسارات: نطاقات الـ Pod والخدمة والعقدة وVPN

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

الـ DNS جزء من الخطة لا همّ منفصل. فالـ sidecar الذي يعيد كتابة إعداد المُحلِّل يمكن أن يكسر اكتشاف الخدمات داخل العنقود بينما يجعل الاستعلامات الخارجية تعمل على أكمل وجه.

البدء والفشل حالتان صريحتان

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

تلك الفجوة قصيرة في عنقود سليم ودائمة في عنقود معطوب، وهذه بالضبط الخاصية التي يفضّلها مهاجم أو تسريب بيانات عرضي.

اقرن الترتيب باختبار فشل. اقتل الـ sidecar وتأكد من أن التطبيق يفقد منفذه المقصود بدلاً من أن يتراجع بصمت.

القدرات والسياسات والاختبار من حاوية التطبيق

منح القدرات اللازمة لإنشاء الواجهات وتغيير المسارات قرار امتياز، والامتياز المناسب لـ Pod معزول ليس مناسبًا تلقائيًا على حزمة العقدة. استخدم آليات سياسة الشبكة والأمن التي يدعمها العنقود، ولا تفترض أن كل تنفيذ لـ CNI أو للسياسات يعامل واجهة VPN بالطريقة نفسها؛ فالاختلافات تظهر في حالات الفشل التي تهمّك بالضبط.

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

وثّق افتراضات شبكة العنقود إلى جانب إعداد الـ VPN. وعندها يصبح نقل عبء العمل إلى عنقود آخر تمرينًا في مراجعة خطة المسارات بدلاً من تغيير صورة يتوقف عن العمل بهدوء.