⚠️ تیمهای SIG Network و Security Response Committee اعلام کردهاند که پروژه Ingress NGINX بازنشسته خواهد شد. نگهداری «best-effort» تا مارس 2026 ادامه دارد و برای کاهش ریسک، لازم است با توجه به migration plan اقدام کنید. پس از این تاریخ، هیچ انتشار جدید، رفع باگ یا بروزرسانی امنیتی منتشر نخواهد شد و مخازن به حالت read-only گذاشته میشوند. اجرای فعلی Ingress NGINX در خوشهها کار خواهد کرد و فایلهای نصبی مثل Helm chartها و ایمیجها همچنان در دسترس خواهند ماند.
migration plan: گامهای کلیدی برای مهاجرت از Ingress NGINX به Gateway API
این مطلب به ویژه به migration plan برای مهاجرت از Ingress NGINX به Gateway API میپردازد تا همزمان با کاهش ریسک، فرایند مهاجرت روشنتر شود.
⚠️ تیمهای SIG Network و Security Response Committee اعلام کردهاند که پروژه Ingress NGINX بازنشسته خواهد شد. نگهداری «best-effort» تا مارس 2026 ادامه دارد، اما پس از آن هیچ انتشار جدید، رفع باگ یا بروزرسانی امنیتی منتشر نخواهد شد و مخازن به حالت read-only گذاشته میشوند. اجرای فعلی Ingress NGINX در خوشهها کار خواهد کرد و فایلهای نصبی مثل Helm chartها و ایمیجها همچنان در دسترس خواهند ماند.
🔁 پیشنهاد میشود هر چه زودتر مهاجرت به یکی از جایگزینها را شروع کنید. بهترین گزینهی مدرن جایگزین Ingress، Gateway API است. در صورتی که نمیتوانید فعلاً Gateway API را پیادهسازی کنید، کنترلرهای دیگری برای Ingress وجود دارند که در مستندات Kubernetes فهرست شدهاند و ممکن است متناسب با نیاز شما باشند.
ℹ️ کمی دربارهٔ Ingress NGINX: Ingress روش قدیمی و سادهای بود برای هدایت ترافیک به سرویسهای داخل Kubernetes و برای کار کردن آن نیاز به یک Ingress controller دارید. Ingress NGINX از روزهای اولیه Kubernetes روی کار آمد و بهخاطر انعطافپذیری بالا و مستقل بودن از ارائهدهندهٔ زیرساخت، محبوب شد. اما با گذشت زمان کنترلرهای متنوع دیگری توسط جامعه و فروشندگان ایجاد شدند و Ingress NGINX همچنان یکی از پر استفادهها بود.
🛠️ مشکل اصلی چه بود؟ انعطاف زیاد و گزینههای گسترده باعث شد نگهداری سخت و مخاطرهپذیر شود. قابلیتهایی که زمانی مفید بودند، مثل افزودن مستقیم دستورات NGINX از طریق annotationهای “snippets”، امروز ممکن است تبدیل به حفرهٔ امنیتی یا فنی شوند. علاوه بر این، پروژه مدتها از نظر نگهداری با کمبود همتایان فعال مواجه بود؛ چند نفر بهصورت داوطلبانه و فراتر از ساعات کاری روی آن کار میکردند و تلاشها برای جذب نیروی بیشتر یا جایگزینسازی (مثل پروژهٔ InGate) به بلوغ کافی نرسید.
📌 وضعیت فعلی و گامهای بعدی: از مارس 2026 نگهداری Ingress NGINX قطع میشود و بعد از آن هیچ پشتیبانی رسمی، رفع آسیبپذیری یا انتشار جدیدی وجود نخواهد داشت. مخازن برای مرجع نگه داشته میشوند اما read-only خواهند شد. مواردی که باید همین حالا انجام دهید برای کاهش ریسک و برنامهریزی مهاجرت:
– ابتدا فهرست دقیق استفادهها را جمعآوری کنید: کجاها از Ingress NGINX استفاده شده، چه annotationهایی به کار رفته و چه ویژگیهایی حیاتی هستند. 🔎
– بررسی قابلیتها: ببینید کدام ویژگیها را باید در Gateway API یا یک کنترلر جایگزین بازتولید کنید (مثل rewriteها، rate limiting، auth، etc.).
– حذف یا امنسازی annotationهای خطرناک مثل snippets قبل از مهاجرت.🧰
– محیط آزمایشی بسازید و مهاجرت را مرحلهای تست کنید: ابتدا در staging سپس در production با rollout کنترلشده.✅
– در نظر داشته باشید images و chartها را ورژنگذاری و پین کنید تا در آینده دچار ریسک supply-chain نشوید.
– اگر نیاز به قابلیتهای خاص شبکهای یا ادغام با محصولات عرضهکننده دارید، گزینههای ارائهدهندهها را نیز بررسی کنید (مثلاً Traefik, Contour, HAProxy یا کنترلرهای اختصاصی cloud providers). مستندات Kubernetes فهرست جامعی ارائه میدهد.
برای چک کردن اینکه آیا Ingress NGINX در خوشه شما نصب است، از فرمان زیر استفاده کنید:
<br>kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx<br>
🙏 از زحمتهای تیم نگهداری Ingress NGINX تشکر میکنیم؛ این کنترلر سالها ترافیکهای عظیم را مدیریت کرد و نقش مهمی در تکامل اکوسیستم Kubernetes داشت. اگر در نقش DevOps/SRE هستید، بهتر است همین حالا شروع به برنامهریزی و اجرای مهاجرت کنید تا ریسکهای امنیتی و عملیاتی کاهش یابد — در صورت نیاز میتوانم قدمهای دقیقتری برای migration plan یا mapping از annotationها به Gateway API پیشنهاد بدهم. 💡
