شبکه OpenShift Red Hat در حال تحول است تا با نسل بعدی الگوهای شبکه در دیتاسنتر هماهنگ شود. با حرکت پارچه‌های دیتاسنتر به سمت معماری‌های شفاف و استانداردمحور مانند BGP EVPN، OpenShift فراتر از مدل‌های قدیمی جداسازی عمل می‌کند و ادغام مستقیم‌تری با شبکه فیزیکی فراهم می‌آورد. 🚀

این پیشرفت‌ها امکان می‌دهد ترافیک دیگر پشت آدرس‌های IP گره پنهان نباشد و به سمت «مسیریابی واقعی» برود؛ بدین ترتیب هویت بار کاری حفظ شده و فایروال‌ها و ابزارهای نظارتی می‌توانند با دید کامل و دقیق کار کنند. 😊

این مطلب نشان می‌دهد چگونه می‌توان به موارد زیر دست یافت: مسیریابی واقعی با اختصاص IPهای قابل مسیریابی به پادها از طریق شبکه‌های تعریف‌شده توسط کاربر خوشه‌ای (CUDN) و حذف کامل NAT در سطح گره؛ یکپارچه‌سازی استانداردمحور با استفاده از FRR برای ادغام دینامیک BGP و تبلیغات جهانی CUDN؛ و همچنین بررسی دسترسی شرکتی در مقابل UDN برای جداسازی قوی مستاجر و پیاده‌سازی‌های VRF-lite.

جامعه Kubernetes سال‌ها به دنبال راه‌هایی برای عبور از الگوهای مبتنی بر NAT بوده است. جایگزین‌هایی مانند CNIهای با BGP، planes مبتنی بر eBPF، و افزودنی‌های مسیریابی توسعه یافتند تا محدودیت‌های مدل‌های NAT اولیه را برطرف کنند. هرچند این تلاش‌ها نشان دادند که شبکه‌سازی بهتر ممکن است، اغلب نیازمند به هم‌دوختن اجزای جداگانه و خارج از پشتیبانی اصلی پلتفرم بود.

با معرفی شبکه‌های تعریف‌شده توسط کاربر (UDN) و BGP، حالا مسیریابی استاندارد یک قابلیت بومی در OpenShift است. شرکت‌ها می‌توانند لایه 3 شبکه را به‌صورت مستقیم داخل خوشه و در مقیاس اجرا کنند، به‌عنوان یک ویژگی کاملاً پشتیبانی‌شده.

برای پیاده‌سازی این معماری مبتنی بر استانداردها، انتخاب ابزار مناسب اهمیت زیادی دارد. OpenShift 4.18+ از دو CRD قدرتمند شبکه با حوزه‌ها و اهداف متفاوت پشتیبانی می‌کند. شکل 1 تفاوت CUDN و UDN را نشان می‌دهد.

شکل 1: این تفاوت بین CUDN و UDN را نشان می‌دهد.

CUDN: سازندگان پارچه از CUDN به‌عنوان ابزار اصلی برای ایجاد پارچه مسیریابی شده با BGP استفاده می‌کنند. چون این تعریف در سطح خوشه است، کافی است یک‌بار محدوده شبکه (مثلاً یک بلوک شرکتی /16) را تعریف کنید و خوشه آن را خودکار در تمام پروژه‌ها منتشر می‌کند. خوشه این محدوده را به زیرشبکه‌های کوچکتر (مثلاً /24) تقسیم کرده و هر گره یک بلوک یکتا دریافت می‌کند. سپس پادها از این بلوک‌های محلی گره، IPهای واقعی و مسیریابی‌شدنی می‌گیرند و پوشش پیش‌فرض NAT را با مسیریابی لایه 3 مستقیم جایگزین می‌کنند.

حفظ قابلیت جابه‌جایی: از آنجایی که CUDN آدرس‌ها را به زیرشبکه‌های خاص گره متصل می‌کند، انتقال یک VM یا pod به گره‌ای دیگر موجب تغییر IP موقعیتی آن می‌شود. برای تضمین در دسترس‌بودن در طی مهاجرت، باید بارهای کاری را از طریق یک سرویس OpenShift یا Load Balancer ارائه دهید تا هویت سرویس ثابت بماند در حالی که آدرس CUDN عملکردی می‌تواند تغییر کند.

در عمل، این بدان معناست که بیش از افزودن یک رابط دوم، شما مسیر شبکه پاد را ارتقا می‌دهید: eth0 از یک اینترفیس پنهان و NAT’d به یک آدرس واقعی و قابل مسیریابی در شبکه شرکتی تبدیل می‌شود. 🔌

UDN: اگرچه UDN نیز از مسیریابی پشتیبانی می‌کند، قدرت اصلی آن در کنترل دقیق توپولوژی لایه 2 است. به‌طور پیش‌فرض، هر UDN به‌عنوان یک جزیره خصوصی عمل می‌کند و پادهای داخل آن با پادهای UDNهای دیگر ارتباط ندارند؛ این موضوع UDN را گزینه‌ای مناسب برای میزبانی چندمستاجری، محیط‌های آزمایشی ایزوله (air-gap) یا محدوده‌های IP همپوشانی می‌سازد.

زمانی از UDN استفاده کنید که یک مستاجر یا تیم به توپولوژی لایه 2 سفارشی نیاز دارد که بقیه خوشه‌ها نباید به آن دسترسی داشته باشند. همچنین UDN پایه‌ای برای معماری‌های VRF-lite است که نیاز به جداول مسیریابی کاملاً مجزا دارند. برخلاف CUDN که معمولاً لایه 3 محور است، یک UDN می‌تواند به صورت Layer2 پیکربندی شود و فضای نام را مستقیماً به یک VLAN فیزیکی در شبکه زیربنایی پل کند؛ با نگاشت UDN به یک VLAN تگ‌شده می‌توانید یک نمونه VRF را از سوییچ ToR به فضای نام گسترش دهید و به این ترتیب از تضاد IP در سناریوهای همپوشان پشتیبانی کنید.

هشدار معماری: هزینه پنهان VRF-lite 🔍 — در حالی که VRF-lite ابزار قدرتمندی برای جداسازی است، باید دقت کنید که مشکل جدیدی ایجاد نکنید. وقتی مستاجران مختلف از آدرس‌های یکسان استفاده کنند، بدون وجود فایروال بالادستی که NAT را روی ترافیک انجام دهد، دسترسی به سرویس‌های مشترک یا اینترنت ممکن نخواهد بود. این مسئله تنها پیچیدگی را از گره OpenShift به لبه شبکه منتقل می‌کند و هویت را دوباره مدیریت می‌نماید.

برای حفظ یک محیط مسیریابی «واقعی»، توصیه می‌شود CUDN را به‌عنوان پیش‌فرض برای حدود 90٪ بارهای کاری خود تنظیم کنید تا آن‌ها بدون NAT و کاملاً قابل مشاهده باشند. مدل UDN و VRF-lite را صرفاً برای مستاجران خاص یا سناریوهای با نیاز جداسازی شدید و تضاد IP به‌کار ببرید. با انتخاب CUDN به‌عنوان استاندارد، میزان پیکربندی سفارشی را کاهش داده و اجازه می‌دهید یک سیاست مسیریابی صدها فضای نام را به‌صورت خودکار پوشش دهد.

موتور: مسیریابی دینامیک با FRR — تعریف شبکه‌ها تنها گام اول است. زیرساخت باید بداند که بارهای کاری دقیقاً در کجا قرار دارند. پیش از این، این امر مستلزم تکیه بر افزونه‌های لایه 2 شکننده یا به‌روزرسانی‌های دستی استاتیک بود. OpenShift 4.18+ این نیاز را با ادغام FRR در پشته شبکه رفع می‌کند تا خوشه به‌عنوان یک نقطه پایانی مسیریابی دینامیک با زبان بومی دیتاسنتر شما (BGP) صحبت کند.

رفع نیاز به تونل Geneve: برای درک بهتر ارزش این معماری، باید به سطح بسته نگاه کرد. در یک خوشه استاندارد، ترافیک بین گره‌ها در تونل Geneve پنهان می‌شود که هر بسته را در یک سربرگ ~50 بایتی کپسوله می‌کند؛ این موضوع MTU را کاهش می‌دهد و فایروال‌های فیزیکی را از دیدن جریان‌های واقعی برنامه محروم می‌سازد. با گذار به CUDN، این تونل حذف شده و بسته‌ها بدون کپسوله‌سازی از رابط گره خارج می‌شوند؛ این امکان استفاده از فریم‌های 1500 یا جامبو را می‌دهد، توان عملیاتی را فوراً افزایش می‌دهد و دید عملیاتی بهتری فراهم می‌سازد.

حذف هزینه NAT برای بارهای با کارایی بالا: در مدل legacy، هسته لینوکس هدر بسته را بازنویسی می‌کند و برای مدیریت بازگشت ترافیک نیاز به جداول حجیم conntrack دارد. تحت بارهای شدید، این جداول می‌توانند به اشباع برسند که منجر به افت مسیر و از دست رفتن بسته‌ها می‌شود. بوسیله مسیریابی stateless با استفاده از CUDN و BGP، گره‌ها بسته‌ها را صرفاً بر اساس IP مقصد مسیریابی می‌کنند بدون بازنویسی هدر یا ردیابی جریان‌های فردی؛ این کار سربار CPU را به‌طرز چشمگیری کاهش داده و خطر فرسودگی conntrack را حذف می‌کند. در نتیجه خوشه قادر است نرخ بسته در ثانیه (PPS) بسیار بالاتری را پشتیبانی کند.

چرخه عمر مسیریابی: همگام‌سازی پیوسته با پارچه — با حذف تونل و NAT، خوشه از طریق یک حلقه BGP پیوسته وضعیت موقعیت بارهای کاری را مدیریت می‌کند تا شبکه فیزیکی همیشه بداند کجا باید ترافیک را ارسال کند. با جدا کردن IP سرویس (هویت) از IP موقعیتی (CUDN)، نیاز به مهاجرت یکپارچه را با مسیریابی کارآمد تطبیق می‌دهید.

وقتی یک pod در CUDN قابل مسیریابی راه‌اندازی می‌شود، CNI به آن یک IP واقعی از بلوک شرکتی اختصاص می‌دهد و به‌صورت همزمان یک IP سرویس یا Load Balancer به‌عنوان دروازه ثابت تعیین می‌گردد. FRR روی گره میزبان فوراً بار کاری محلی جدید را کشف و جدول مسیریابی را به‌روزرسانی می‌کند؛ سپس گره از طریق BGP با سوییچ ToR صحبت کرده و مسیر گره‌محلی را به بقیه شبکه تبلیغ می‌کند. اگر بار کاری به گره دیگری منتقل شود، IP موقعیتی جدیدی از زیرشبکه آن گره دریافت می‌کند در حالی که IP سرویس ثابت می‌ماند؛ پارچه از طریق BGP مسیر جدید را فورا شناسایی می‌کند تا کاربران بدون قطع ارتباط ادامه دهند.

با خودکارسازی این چرخه عمر، محیطی که قبلاً شکننده و ایستا بود به معماری‌ای انعطاف‌پذیر و مبتنی بر مسیریابی تبدیل می‌شود؛ این مدل یک اعتماد دوطرفه برقرار می‌سازد: تیم شبکه کنترل فیلترهای BGP را در سوئیچ برعهده دارد و خوشه به‌صورت پویا محل اجرای بارهای کاری را مدیریت می‌کند. شکل 2 مرزهای این سیستم خودمختار BGP و نقاط تعامل را نشان می‌دهد.

شکل 2: این مرزهای سیستم خودمختار BGP و نقاط ترجیحی تعامل را نمایش می‌دهد. 🧭

به گزارش از وبسایت redhat