فقدت حاويات GKE الوصول إلى VPN بعد 1.14: طريقتان لإصلاح المصدر
بعد 1.14 تصل الحاويات إلى VPN بعناوينها الخاصة، فترفض الأقران الردود. اختر عقد المصدر ثم اضبط nonMasqueradeCIDRs ليطابقه.
يصل تحديث ما، فتبدأ الأنظمة على طرفي النفق برفض حركة الحاويات التي كانت تعمل في الأسبوع السابق. النفق قائم، وقواعد الجدار الناري لم تُمس، ولم يعدّل أحد سياسة القرين. ما تغيّر غير مرئي في سجلات العنقود: عنوان المصدر الذي تراه تلك الأنظمة الآن. هذه الفجوة تفسّر عطلاً يبدو كانقطاع شبكة ويتصرف كمشكلة صلاحيات.
يوجد جوابان صحيحان، وكلاهما يقودك إلى مكان مختلف. اختر عقد المصدر قبل أن تعدّل ConfigMap.
القاعدة الافتراضية التي لم تعد تُثبَّت
ثبّتت إصدارات GKE الأقدم قاعدة masquerade تستبدل مصادر الحاويات بعنوان العقدة كلما وقع الهدف خارج 10.0.0.0/8. وكانت بوابة VPN داخل هذا النطاق ترى عنوان الحاوية، بينما يبدو أي شيء أبعد كأنه قادم من العقدة. بنى الأقران قوائم سماح ومسارات عودة حول عناوين العقد لأن هذا ما لاحظوه.
توقفت الإصدارات الأحدث عن تثبيت تلك القاعدة الافتراضية. تصل حركة الحاويات الآن إلى البوابة بعناوين الحاويات، أيًّا كان الهدف. والقرين الذي يوجّه عناوين العقد فقط يُسقط الردود، ولا يكتب أي من الطرفين سجلاً مفيداً. قد ينجح الطلب حتى في الطرف البعيد، وهذا ما يجعل العطل محيّراً عند تتبعه.
لا شيء معطوب بمعنى وجود مكوّن ميت. الطرفان يختلفان ببساطة حول أي مصدر يُعدّ مشروعاً.
اختر المصدر الذي ينبغي أن يراه القرين
الإبقاء على عناوين الحاويات هو العقد الأدق. يرى الطرف الآخر حمل العمل الذي أنتج الحركة، وتبقى السجلات صادقة، وتصبح السياسة لكل حاوية ممكنة. الثمن أن على القرين حمل بادئة الحاويات.
الإبقاء على عناوين العقد هو العقد الأرخص. أعد تشغيل الإخفاء لذلك الهدف، وسيظل القرين يرى عنواناً يثق به أصلاً.
سؤال واحد يحسم بينهما: ماذا يفعل القرين بالمصدر؟ إن كان يسجّل أو يطبّق سياسة لكل مصدر أو يفرض توجيهاً ضيقاً للعودة، فعناوين الحاويات تبرّر الإعداد الإضافي. وإن كان يحتاج فقط إلى إرسال الردود، فالإخفاء أقل كلفة ولا يطلب شيئاً من الطرف الآخر. وأي الخيارين يمكن الدفاع عنه ما دام الفريقان كتباه.
الخيار الثالث عادةً خطأ: إخفاء كل شيء وفقدان القدرة على نسب الحركة. تجنّبه إلا إذا كان القرين لا يستطيع فعلاً توجيه أي شيء غير عناوين العقد.
وجّه nonMasqueradeCIDRs إلى النطاقات الحقيقية
يشغّل GKE وكيل ip-masq-agent في kube-system، وتسرد خريطة ConfigMap الخاصة به الأهداف التي تتجاوز الإخفاء. وللحفاظ على مصادر الحاويات نحو النفق، ينتمي نطاق الحاويات وشبكة العقدة الفرعية والبادئة المحلية إلى تلك القائمة.
استبدل القيم النموذجية بنطاقات من عنقودك. لا تجعل القائمة أوسع مما يقتضيه الشرط، لأن كل إدخال إضافي يغيّر ما يراه هدف آخر. الإدخالات الثلاثة أدناه تمثّل شبكة الحاويات وشبكة العقدة الفرعية والبادئة خلف النفق:
nonMasqueradeCIDRs:
- 10.12.0.0/14
- 10.100.0.0/16
- 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60sالإدخال 0.0.0.0/0 يعطّل الإخفاء لكل الأهداف، وهذا يغيّر كيف تظهر أحمال العمل غير ذات الصلة للخدمات الخارجية ونادراً ما يكون مقصوداً. يعيد الوكيل قراءة إعداده عند resyncInterval، لذا لا حاجة عادةً إلى إعادة تشغيل. تحقق من أن حاوية الوكيل تعمل، ثم افتح الملف المثبّت داخلها. قراءة ذلك الملف هي ما يثبت أن التغيير وصل.
مسار الرد هو النصف الآخر
الإخفاء يغيّر مصدر الطلب ولا شيء غير ذلك. وأي مصدر يتلقاه القرين، فإنه ما زال يحتاج مساراً للعودة إليه، وما زال العنقود يحتاج مساراً نحو القرين.
التقاط على بوابة VPN يفصل العطلين بسرعة. الحزم التي تصل بعناوين الحاويات ولا تحصل على جواب تعني أن القرين يفتقر إلى مسار لبادئة الحاويات. والجواب الذي يظهر على البوابة ولا يصل العنقود أبداً يعني أن المسار المحلي مفقود. اكتب العقد في التذكرة في الحالتين: أي مصدر يرى القرين، وأي بادئة يوجّه الرد إليها.
أعد التحقق بعد كل ترقية
تغيّر سلوك الإخفاء الافتراضي مرة واحدة بالفعل، واستبدال مجموعة العقد يمكن أن يعيد ضبط شبكة العنقود. تعامل مع عقد المصدر كشيء يجب التحقق منه لا افتراضه.
بعد الترقية، أرسل طلباً واحداً من حاوية إلى خدمة محلية واقرأ المصدر الذي يسجّله القرين. تلك الملاحظة الواحدة تلتقط انحداراً كانت صفحة حالة النفق ستبلغ عنه بسعادة كسليم. وتكرارها يكلّف دقيقة ويوفّر على الشخص التالي أمسية.