پادهای GKE پس از 1.14 دسترسی VPN را از دست دادند: دو راه برای اصلاح منبع
پس از 1.14 پادها با نشانیهای خودشان به VPN میرسند، بنابراین همتایان پاسخها را دور میریزند. قرارداد منبع را انتخاب کنید و سپس nonMasqueradeCIDRs را مطابق آن تنظیم کنید.
بهروزرسانی میرسد و سامانههای آن سوی تونل شروع به رد کردن ترافیک پادها میکنند که هفته پیش کار میکرد. تونل بالاست، قواعد دیوار آتش دستنخوردهاند و هیچکس خطمشی همتا را ویرایش نکرده است. آنچه تغییر کرده در گزارشهای خوشه نامرئی است: نشانی مبدأیی که آن سامانهها اکنون میبینند. همین شکاف خرابیای را توضیح میدهد که شبیه قطع شبکه به نظر میرسد و مانند مشکل مجوز رفتار میکند.
دو پاسخ معتبر وجود دارد و شما را به جاهای متفاوتی میفرستند. پیش از ویرایش ConfigMap قرارداد منبع را انتخاب کنید.
قاعده پیشفرضی که دیگر نصب نمیشود
نسخههای پیشین GKE قاعدهای برای masquerade نصب میکردند که هرگاه مقصد بیرون از 10.0.0.0/8 بود، مبدأ پادها را با نشانی گره جایگزین میکرد. دروازه VPN درون آن محدوده نشانی پاد را میدید، در حالی که هر چیز دورتر به نظر میرسید از گره میآید. همتایان سیاهههای مجاز و مسیرهای بازگشت را حول نشانیهای گره ساختند، چون همین را مشاهده میکردند.
نسخههای بعدی نصب آن قاعده پیشفرض را متوقف کردند. ترافیک پادها اکنون با نشانیهای پاد به دروازه میرسد، هر چه مقصد باشد. همتایی که فقط نشانیهای گره را مسیریابی میکند پاسخها را دور میریزد و هیچکدام از دو طرف ورودی سودمندی در گزارش نمینویسند. درخواست حتی ممکن است در انتهای دور موفق شود و همین یافتن خرابی را گیجکننده میکند.
هیچ چیز به معنای یک جزء مرده خراب نیست. دو طرف فقط بر سر اینکه کدام مبدأ مشروع است توافق ندارند.
مبدأیی را انتخاب کنید که همتا باید ببیند
نگه داشتن نشانیهای پاد قرارداد دقیقتری است. طرف دور بار کاریای را میبیند که ترافیک را تولید کرده، گزارشها صادق میمانند و خطمشی برای هر پاد ممکن میشود. بهای آن این است که همتا باید پیشوند پادها را حمل کند.
نگه داشتن نشانیهای گره قرارداد ارزانتری است. masquerade را برای آن مقصد دوباره روشن کنید و همتا همچنان نشانیای را میبیند که از پیش به آن اعتماد دارد.
یک پرسش میان این دو تصمیم میگیرد: همتا با مبدأ چه میکند؟ اگر گزارش مینویسد، خطمشی بر پایه مبدأ اعمال میکند یا مسیریابی بازگشت تنگ را الزام میکند، نشانیهای پاد پیکربندی اضافی را توجیه میکنند. اگر فقط باید پاسخ بفرستد، masquerade کمهزینهتر است و چیزی از طرف دیگر نمیخواهد. هر دو گزینه دفاعپذیرند، به شرطی که هر دو تیم آن را بنویسند.
گزینه سوم معمولاً اشتباه است: همه چیز را masquerade کردن و از دست دادن توان نسبت دادن ترافیک. از آن بپرهیزید مگر اینکه همتا واقعاً نتواند چیزی جز نشانیهای گره را مسیریابی کند.
nonMasqueradeCIDRs را به محدودههای واقعی نشانه بگیرید
GKE عامل ip-masq-agent را در kube-system اجرا میکند و ConfigMap آن مقصدهایی را فهرست میکند که از masquerade میگذرند. برای حفظ مبدأ پادها به سمت تونل، محدوده پادها، زیرشبکه گره و پیشوند محلی همگی به آن فهرست تعلق دارند.
مقدارهای نمونه را با محدودههایی از خوشه خودتان جایگزین کنید. فهرست را پهنتر از آنچه الزام میگوید نکنید، چون هر ورودی اضافی تغییر میدهد که مقصدی دیگر چه میبیند. سه ورودی زیر نماینده شبکه پادها، زیرشبکه گره و پیشوند پشت تونل هستند:
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 masquerade را برای همه مقصدها غیرفعال میکند، که نحوه ظاهر شدن بارهای کاری نامرتبط در برابر سرویسهای بیرونی را تغییر میدهد و بهندرت عمدی است. عامل پیکربندی خود را در resyncInterval دوباره میخواند، پس راهاندازی دوباره معمولاً لازم نیست. بررسی کنید که پاد عامل در حال اجراست، سپس پرونده سوارشده درون آن را باز کنید. خواندن همان پرونده چیزی است که اثبات میکند تغییر رسیده است.
مسیر پاسخ نیمه دیگر است
masquerade فقط مبدأ درخواست را تغییر میدهد و نه چیز دیگری. هر مبدأیی که همتا دریافت کند، همچنان مسیری برای بازگشت به آن لازم دارد و خوشه نیز همچنان مسیری به سوی همتا لازم دارد.
یک ضبط در دروازه VPN دو خرابی را سریع از هم جدا میکند. بستههایی که با نشانیهای پاد میرسند و هرگز پاسخ نمیگیرند یعنی همتا مسیری برای پیشوند پادها ندارد. پاسخی که در دروازه پدیدار میشود اما هرگز به خوشه نمیرسد یعنی مسیر محلی گم شده است. در هر حال قرارداد را در تیکت بنویسید: همتا کدام مبدأ را میبیند و پاسخ را به کدام پیشوند مسیریابی میکند.
پس از هر بهروزرسانی دوباره بررسی کنید
رفتار پیشفرض masquerade یک بار تغییر کرده است و جایگزینی استخر گره میتواند شبکه خوشه را بازنشانی کند. با قرارداد منبع مانند چیزی که باید بررسی شود برخورد کنید، نه چیزی که فرض شود.
پس از بهروزرسانی، یک درخواست از یک پاد به سرویسی محلی بفرستید و مبدأیی را که همتا ثبت میکند بخوانید. همان یک مشاهده پسرفتی را میگیرد که صفحه وضعیت تونل با خوشحالی سالم گزارش میکند. تکرارش یک دقیقه هزینه دارد و برای نفر بعدی یک شب را ذخیره میکند.