به گزارش از وبسایت cncf 😊
نگه داشتن کنترلکنندهای که اکنون در چرخه بازنشستگی قرار دارد، ریسکهای عملیاتی جدی ایجاد میکند؛ از جمله CVEهای اصلاحنشده و توقف دریافت بهروزرسانیهای ویژگی و پشتیبانی جامعه. یک برداشت نادرست رایج این است که خود Ingress API در حال بازنشستگی است — در حقیقت این API همچنان پشتیبانی و بهطور گسترده استفاده میشود. آنچه پایان عمر را تجربه میکند، کنترلکننده معروف ingress-nginx است که توسط جامعه نگهداری میشده و بنابراین سازمانها باید تصمیم بگیرند که کنترلکنندهای جایگزین کنند یا از این فرصت برای مدرنسازی معماری شبکه استفاده نمایند.
تیمهای زیرساختی با یک انتخاب معماری مهم مواجهاند: یا یک انتقال سریع «lift-and-shift» به کنترلکنندهای دیگر مانند Contour انجام دهند، یا از این موقعیت برای مهاجرت به Gateway API و بازنگری ساختار شبکه بهره ببرند. هر مسیر مزایا و هزینههای خودش را دارد و بسته به محدودیتهای زمانی و بدهی فنی سازمان، یکی مناسبتر خواهد بود.
مسیر A: “lift and shift” — ماندن روی Ingress API با Contour
نحوه کار: اپراتورها میتوانند منابع YAML موجود از نوع Ingress را حفظ کنند و تنها کلاس ورودی را به یک کنترلکننده مبتنی بر Envoy مانند Contour تغییر دهند. این کار اختلال فوری در تعاریف مسیریابی استاندارد را به حداقل میرساند و زمانبندی مهاجرت را سادهتر میکند. نکته مهم این است که همه حاشیهنویسیهای ویژه nginx.ingress.kubernetes.io/* کار نخواهند کرد؛ این موارد یا باید به معادلهای Contour ترجمه شوند یا با استفاده از CRD متناظر بازنویسی شوند. ⚠️
مسیر B: تکامل معماری — مهاجرت به Gateway API
Gateway API جانشین مدنظر با پشتیبانی بالادستی است و الگوی نقشمحور (role-based) را معرفی میکند که بهویژه نگرانیهای زیرساختی را از مسیریابی برنامهها جدا میسازد. این رویکرد بسیاری از محدودیتهای ساختاری را که نگهداری Ingress-NGINX را پیچیده کرده بود، رفع میکند و قابلیتهایی مانند تقسیم ترافیک، تطبیق هدر پیشرفته و مسیریابی امن بین namespaceها را بهصورت استاندارد فراهم میکند.
تجزیه و تحلیل مقایسهای — مزایا و معایب
برای انتخاب راستین باید محدودیتهای سازمانی، جدول زمانی و تحمل بدهی فنی را مد نظر قرار دهید. خلاصه تفاوتها بهصورت کلی:
Path A: Contour (Ingress API) — تلاش مهاجرت: کم تا متوسط (نیاز به ترجمه حاشیهنویسیها). پارادایم عملیاتی: تکمالک، Ops تعاریف یکپارچه را مدیریت میکند. آیندهپذیری: پایینتر، چون Ingress API ویژگیهایش ثابت شدهاند و بسیاری از قابلیتهای پیشرفته به حاشیهنویسیهای اختصاصی تکیه دارند.
Path B: Gateway API — تلاش مهاجرت: بالا (بازنویسی کامل مانیفستهای مسیریابی). پارادایم عملیاتی: مبتنی بر نقش؛ Ops مدیریت Gateway را بر عهده دارد و توسعهدهندگان مسیرهای HTTP مانند HTTPRoutes را تعریف میکنند. آیندهپذیری: بالاتر، زیرا بسیاری از قابلیتهای پیشرفته در مشخصه اصلی تعبیه شدهاند و توسعه فعال بالادستی وجود دارد.
استراتژی مهاجرت و ابزارها
1. حسابرسی: بدهیهای فنی فعلی را فهرست کنید، بهویژه حاشیهنویسیهای nginx.ingress.kubernetes.io/*.
2. ابزارها: از ابزارهایی مانند ingress2gateway برای خودکارسازی ترجمه استفاده کنید.
3. انتشار افزایشی: مهاجرت را بهصورت موازی و مرحلهای انجام دهید—ابتدا بارهای کاری غیر بحرانی را منتقل کنید و سپس به سرویسهای حیاتی بپردازید. 🚀
نتیجهگیری
اگر تیم شما محدودیت زمانی شدید دارد و امکان یک Refactor بزرگ وجود ندارد، حرکت جانبی به Contour یا کنترلکننده دیگری میتواند زمان لازم برای برنامهریزی و نوسازی را فراهم کند؛ این گزینه معمولاً کمترین اختلال کوتاهمدت را دارد اما راهحلی موقت است. سازمانهایی که در پی یک بازطراحی بلندمدت و ارتقاء قابلیتها هستند، احتمالاً از انعطافپذیری و ویژگیهای بیشتر Gateway API بهرهمند خواهند شد. انتخاب نهایی باید با توجه به محدودیتهای عملیاتی، جدول زمانی مهاجرت و اهداف معماری آتی گرفته شود. 🔍
اگر مایل به سرعتبخشیدن به نوسازی هستید، بررسی خدمات مهاجرت دارای گواهی KCSP میتواند مفید باشد.
