VPN للـ Pod في Kubernetes مقابل بوابة الخروج: من يملك النفق؟
الـ Pod مساحة شبكة خاصة به، لذا الاختيار الحقيقي هو أي طبقة تملك النفق: هوية لكل حمل عمل، أو خروج موجّه عبر CNI بمصدر واحد مشترك.
تنشر Pod باسم vpn-gateway، وتوجّه عميل اختبار إلى عنوانه، فترى الحزم تختفي. لا شيء في المانيفست خطأ، وليس لدى kubelet أي اعتراض. السبب بنيوي لا إعدادي: Kubernetes يمنح كل Pod مساحة أسماء شبكة خاصة به، لذا لا يغيّر اسم ولا تسمية ولا مساحة أسماء API مشتركة شيئًا في وجهة الحزم. لذلك يبدأ قرار كيفية خروج حركة VPN من العنقود بسؤال عن الملكية، لا عن صور الحاويات.
تغطي آليتان معظم عمليات النشر الحقيقية، وهما غير قابلتين للتبادل. إحداهما تضع النفق داخل مساحة أسماء الشبكة الخاصة بحمل العمل. والأخرى تطلب من CNI توجيه حركة مختارة عبر عقدة بوابة محددة. إنهما تفشلان بطرق مختلفة وتتوسعان بطرق مختلفة وتتبعان فرقًا مختلفة، ولهذا ينتج سؤال الحاويات عادة جدالًا لا ينتهي.
حدّ الـ Pod هو مساحة أسماء، لا مضيف قفز
تملك مساحة أسماء الشبكة في Linux واجهاتها وعناوينها ومساراتها وقواعد جدار الحماية، وكل Pod يحصل على واحدة. تنضم الحاويات داخل ذلك الـ Pod إليها، ولهذا بالضبط تستطيع حاوية مساعدة إعادة كتابة مسارات يتبعها التطبيق بعد ذلك. وللـ Pod المجاور حزمة تبدو مطابقة لكنها منفصلة تمامًا. لا يوجد جدول مشترك يرثه Pod البوابة، ولا تسليم ضمني للحركة من مساحة أسماء إلى أخرى.
ولهذا أيضًا لا يعمل نمط Pod البوابة إلا عندما يرسل شيء في المنبع الحزم إليه فعلًا: خدمة أو مسار ثابت على العقدة أو سياسة توجيه في CNI. العنوان وحده لا يجذب شيئًا.
ماذا يشتري نفق لكل Pod، وماذا يكلّف
النفق الذي يعمل في مساحة أسماء حمل العمل يمنح ذلك الحمل هوية عميل خاصة به، وهو ما تطلبه كثير من خدمات الوصول البعيد قبل أن تصرّح بجلسة أو تحاسب عليها. يبقى نطاق التأثير محليًا أيضًا: نفق معطّل يعطّل عملية نشر واحدة بدل المسار المشترك الذي يستخدمه كل شيء. أما كيفية عمله فتتبع التنفيذ، وهنا يخطئ الناس في التقدير.
الإعداد الذي يحتاج حالة النواة فقط يمكن أن ينتهي في حاوية تهيئة ثم يخرج. أما البرنامج الخفي في مساحة المستخدم الذي يجب أن يبقى حيًّا طوال عمر الـ Pod فيحتاج صيغة حاوية التهيئة القابلة لإعادة التشغيل التي أُدخلت كحاوية جانبية أصلية في Kubernetes 1.29، وهذا الفرق يأتي من تنفيذ النفق لا من الذوق. كلفة هذا النموذج هي الازدواجية: كل نسخة تصادق وتحصل على عنوان نفق خاص بها وتستهلك فتحة جلسة بعيدة، فتصبح حادثة التوسع التلقائي حادثة سعة على الطرف الآخر من الوصلة. نسخ بيانات اعتماد واحدة إلى كل النسخ لا يزيل تلك الكلفة، بل يزيل أثر التدقيق. والصلاحيات تستحق التدقيق نفسه، لأن نفقًا يريد NET_ADMIN في مساحة أسمائه ليس لديه سبب ليرث السلطة على مستوى المضيف في مثال privileged: true.
حين يملك CNI الخروج بدلًا من ذلك
إذا كان CNI يدعم ذلك، فإن بوابة خروج تختار الحركة حسب حمل العمل ونطاق الوجهة، ثم ترسلها عبر عقد مختارة تحت عنوان مصدر واحد يمكن التنبؤ به. نسخة Cilium هي المرجع الشائع، ووثائقه صريحة في أن الميزة تحتاج إعداد Cilium محددًا بالإضافة إلى عقد بوابة مزوّدة بالواجهات والعناوين الصحيحة. وتشير أيضًا إلى فترة أولية بعد إنشاء الـ Pod لا يكون فيها التوجيه مفروضًا بعد، وهذا مدخل تصميم لا حاشية.
اقرأ هذا التأخير في ضوء وعدك أنت. إذا كانت القاعدة أن لا حركة تخرج عبر مسار آخر، فإن Pod جديدًا يرسل خلال الفجوة قد خرقها بالفعل، لذا يحتاج تسلسل البدء إلى جواب خاص به: أوقف التطبيق حتى تُطبّق السياسة، أو اقبل النافذة ووثّقها.
أبقِ الادعاء ضيقًا أيضًا. بوابة الخروج تختار مسارًا وتترجمه. إنها لا تنهي VPN، ولا تحوّل العنقود إلى عميل لشبكتك البعيدة دون اتصال مدعوم خلفها.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
الترجمة تغيّر بهدوء ما يراه الطرف البعيد
حين تعيد البوابة كتابة المصدر، تختفي عناوين كل Pod، فتصبح قائمة السماح المبنية على الهوية قائمة سماح مبنية على عنوان واحد مشترك. هذه مقايضة لا عيب: قواعد أقل للصيانة، وإسناد أخشن عندما يسيء شيء التصرف.
على المصادقة على مستوى التطبيق وتسجيل الطلبات أن يحملا ما لم تعد الشبكة تبلغ به. تعامل مع سعة البوابة واستبدالها كبنية تحتية مشتركة، لأن إعادة تشغيل عقدة واحدة تقطع الآن كل حمل عمل خلفها، وافحص مسار العودة مبكرًا: يجب أن يعرف الطرف البعيد كيف يصل إلى العنوان المترجم، عادة عبر مسار أو NAT يجب أن يملكه إنسان لا مانيفست. تخطيط العناوين ينتمي إلى هنا أيضًا، لأن تداخل نطاقات العنقود والنطاقات البعيدة يكسر أي نموذج، وتبنّي IPv6 لا يعفي من خطة متعارضة.
قرّر بالملكية، ثم اختبر الفشل الذي وعدت به
اختر النفق لكل Pod عندما تصادق الخدمة البعيدة أحمال عمل فردية، وعندما تحتاج الوصلة بضع عمليات نشر فقط، وعندما يجب أن يبقى الفشل محليًا. واختر البوابة عندما يملك فريق شبكة المسار بالفعل، وعندما تتشارك أحمال عمل كثيرة وجهة واحدة، وعندما يكون عنوان المصدر المستقر هو غاية التمرين كله.
في كلتا الحالتين، تحقّق من الخاصية التي بعتها لا من الحالة المستقرة. أنشئ Podًا واتركه يرسل فورًا وراقب الثواني الأولى إذا كان الوعد أن لا شيء يفلت من النفق. وسّع إلى خمس نسخ وعُدّ الجلسات التي يبلّغ عنها الطرف البعيد إذا كان الوعد هوية لكل حمل عمل. هذان الفحصان يكشفان حدود الآلية أسرع بكثير من مراجعة المانيفست، ويخبرانك أي فريق يملك الحادثة التالية.