بازنشستگی ingress-nginx یکی از مهمترین تغییرات اخیر در اکوسیستم کوبرنتیز به شمار میآید. این پروژه که سالها یکی از رایجترین Ingress Controllerهای کوبرنتیز بود، دیگر در مسیر توسعه عادی قرار ندارد و پس از پایان دوره پشتیبانی، بهروزرسانی امنیتی و اصلاح باگ جدیدی برای آن منتشر نمیشود. این اتفاق باعث شده است که مهاجرت از ingress nginx و بررسی جایگزین به یکی از دغدغههای اصلی تیمهای زیرساخت و DevOps تبدیل شود.
در این مقاله بررسی میکنیم که ingress-nginx چیست، دقیقاً چه بخشی از این پروژه بازنشسته شده، چرا کوبرنتیز این تصمیم را گرفته است و ادامه استفاده از آن چه ریسکهایی دارد. همچنین گزینههای موجود برای جایگزین ingress-nginx، نقش Gateway API و مراحل مهاجرت از اینگرس nginx با استفاده از ابزار Ingress2Gateway را بهصورت عملی آموزش میدهیم.
اهمیت بازنشستگی ingress-nginx؛ چرا کوبرنتیز درباره آن هشدار میدهد؟
بازنشستگی ingress-nginx صرفا پایان عمر یک پروژه متنباز نیست، بلکه به پایان چرخه نگهداری یکی از پرکاربردترین Ingress Controllerهای کوبرنتیز اشاره دارد. بر اساس بیانیه رسمی کوبرنتیز، ادامه استفاده از این پروژه پس از پایان دوره پشتیبانی، میتواند ریسکهای امنیتی و عملیاتی جدیدی برای محیطهای Production ایجاد کند.
اهمیت این موضوع زمانی بیشتر مشخص میشود که بخش قابل توجهی از کلاسترهای کوبرنتیز همچنان از ingress-nginx برای مدیریت ترافیک HTTP و HTTPS استفاده میکنند. هرچند استقرارهای فعلی به کار خود ادامه میدهند، اما پس از بازنشستگی، هیچ وصله امنیتی، اصلاح باگ یا نسخه جدیدی برای پروژه منتشر نمیشود و آسیبپذیریهای آینده ممکن است بدون راهکار رسمی باقی بمانند.
تیم کوبرنتیز اعلام کرده است که این تصمیم نتیجه چالشهای طولانیمدت در نگهداری پروژه، محدود بودن افراد مسئول نگهداری و افزایش پیچیدگی فنی آن بوده است، به همین دلیل، تیم کوبرنتیز به کاربران توصیه میکند که از همین حالا برای مهاجرت از ingress-nginx یا انتخاب جایگزین مناسب برنامهریزی کنند.
ingress-nginx چیست؟
ingress-nginx یک Ingress Controller مبتنی بر NGINX برای کوبرنتیز است که منابع Ingress را پایش کرده و بر اساس قوانین تعریفشده، پیکربندی NGINX را بهصورت خودکار ایجاد و بهروزرسانی میکند تا ترافیک HTTP و HTTPS به سرویسهای مناسب هدایت شود.
در کوبرنتیز، منبع Ingress فقط شامل قوانین مسیریابی است و بهتنهایی درخواستها را پردازش نمیکند. برای اعمال این قوانین به یک Ingress Controller نیاز است و ingress-nginx یکی از شناختهشدهترین پیادهسازیهای این مدل به شمار میآید.
یکی از دلایل محبوبیت ingress-nginx، متنباز بودن و امکان استفاده از آن در انواع محیطهای کوبرنتیز، چه در سرویسهای ابری و چه در زیرساختهای On-Premise، بود و به همین دلیل در میان تیمهای DevOps و SRE جایگاه ویژهای پیدا کرد.
دقیقاً چه چیزی بازنشسته شده است؟
نکته مهمی که باید بدانید این است که قابلیت Ingress همچنان بخشی از کوبرنتیز باقی میماند، اما پروژه ingress-nginx پس از پایان دوره پشتیبانی دیگر بهروزرسانی نمیشود. بر اساس اعلام رسمی کوبرنتیز ، پس از پایان نگهداری پروژه:
- نسخه جدیدی از ingress-nginx منتشر نمیشود
- باگهای جدید برطرف نخواهند شد
- برای آسیبپذیریهای آینده وصله امنیتی ارائه نمیشود
- مخازن GitHub پروژه در حالت فقطخواندنی (Read-only) قرار میگیرند.
در عین حال، استقرارهای فعلی همچنان به کار خود ادامه میدهند و آرتیفکتهایی مانند Helm Chartها و Container Imageهای موجود در دسترس هستند. البته با این حال استفاده از نرمافزاری که دیگر بهروزرسانی امنیتی دریافت نمیکند، میتواند به مرور زمان ریسکهای عملیاتی و امنیتی را افزایش دهد. اگر میخواهید بررسی کنید که آیا کلاستر شما از ingress-nginx استفاده میکند یا خیر، میتوانید دستور زیر را اجرا کنید:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxاگر این دستور خروجی داشته باشد، کلاستر شما از ingress-nginx استفاده میکند و بهتر است وضعیت زیرساخت خود را ارزیابی و برای مهاجرت از ingress nginx یا انتخاب یک جایگزین ingress-nginx مناسب برنامهریزی کنید.
چرا ingress-nginx بازنشسته شد؟
بازنشستگی ingress-nginx نتیجه مجموعهای از چالشهای فنی و مدیریتی است که طی سالهای گذشته شکل گرفتهاند. تیم کوبرنتیز اعلام کرده است که نگهداری این پروژه برای مدت طولانی بر عهده تعداد محدودی افراد مسئول نگهداری بوده و این مدل برای یکی از پرکاربردترین اجزای اکوسیستم Cloud Native پایداری لازم را نداشته است.
عامل مهم دیگر، انباشت بدهی فنی (Technical Debt) است. ingress-nginx در ابتدا بهعنوان یکی از پیادهسازیهای Ingress API توسعه یافت، اما به مرور زمان قابلیتها و Annotationهای متعددی به آن اضافه شد. این انعطافپذیری برای کاربران مفید بود، اما پیچیدگی نگهداری و مدیریت امنیت پروژه را افزایش داد.
از سوی دیگر، جامعه کوبرنتیز در سالهای اخیر به سمت معماریها و استانداردهای جدیدتر مدیریت ترافیک حرکت کرده است؛ به همین دلیل، به جای توسعه بیشتر ingress-nginx، تمرکز اکوسیستم به سمت راهکارهایی مانند Gateway API و نسل جدید Ingress Controllerها معطوف شده است.
در مجموع، بازنشستگی ingress-nginx را میتوان حاصل سه عامل اصلی محدودیت در نگهداری پروژه، افزایش بدهی فنی و حرکت اکوسیستم کوبرنتیز به سمت مدلهای جدیدتر مدیریت ترافیک دانست.
اگر مهاجرت نکنیم چه اتفاقی میافتد؟
بازنشستگی ingress-nginx باعث توقف ناگهانی سرویسهای فعلی نمیشود و استقرارهای موجود همچنان به کار خود ادامه میدهند. با این حال، ادامه استفاده از این پروژه بهمعنای استفاده از نرمافزاری است که دیگر توسعه فعال و پشتیبانی امنیتی دریافت نمیکند.
یکی از مهمترین پیامدهای این وضعیت، افزایش ریسک امنیتی در طول زمان است. هر آسیبپذیری جدیدی که پس از پایان دوره پشتیبانی کشف شود، ممکن است بدون وصله امنیتی باقی بماند و سازمانها ناچار باشند ریسک آن را بپذیرند یا راهکارهای موقت خود را پیادهسازی کنند.
موضوع دیگر، افزایش بدهی فنی است. هرچه وابستگی سرویسها به قابلیتهای اختصاصی ingress-nginx، تنظیمات ویژه و Annotationها بیشتر شود، فرایند مهاجرت در آینده پیچیدهتر و پرهزینهتر میشود.
همچنین ممکن است به دلیل عدم بهروزرسانی پروژه ingress-nginx برای سازگاری با تغییرات، در نسخههای آینده کوبرنتیز یا سایر اجزای اکوسیستم، ناسازگاریهای جدیدی ایجاد شود. توصیه جامعه کوبرنتیز این است که سازمانها پیش از تبدیل شدن این وابستگی به یک چالش عملیاتی، وضعیت کلاسترهای خود را بررسی و برای مهاجرت از ingress nginx یا انتخاب یک جایگزین ingress-nginx مناسب برنامهریزی کنند.
جایگزینهای ingress-nginx چیست؟
بازنشستگی ingress-nginx به این معنا نیست که کوبرنتیز دیگر از مدیریت ترافیک ورودی پشتیبانی نمیکند. این اکوسیستم از مدتها قبل گزینههای مختلفی برای این منظور در اختیار کاربران قرار داده است و در اطلاعیههای رسمی هم به مهاجرت از ingress nginx یا انتخاب یک جایگزین مناسب توصیه شده است.
انتخاب بهترین گزینه به عواملی مانند معماری کلاستر، نیازهای عملیاتی و برنامه بلندمدت سازمان بستگی دارد. برخی تیمها فقط به دنبال جایگزینی Ingress Controller فعلی هستند و برخی دیگر ترجیح میدهند همزمان به سمت فناوریهای جدیدتر حرکت کنند. در ادامه برخی از مهمترین جایگزینهای ingress-nginx را معرفی میکنیم.
Traefik
Traefik یکی از شناختهشدهترین Ingress Controllerهای کوبرنتیز است که علاوه بر Ingress API، از Gateway API هم پشتیبانی میکند. این ویژگی امکان مهاجرت تدریجی را برای بسیاری از تیمها فراهم میکند. همچنین راهاندازی ساده، یکپارچگی مناسب با کوبرنتیز و پشتیبانی همزمان از مدلهای مختلف مدیریت ترافیک، از مهمترین دلایل محبوبیت این پروژه است.
Traefik معمولاً برای تیمهایی مناسب است که به دنبال مهاجرت کمدردسر از ingress-nginx هستند و میخواهند علاوه بر Ingress API، بهتدریج از Gateway API نیز استفاده کنند. سادگی راهاندازی و مدیریت، این گزینه را برای کلاسترهای کوچک و متوسط جذاب کرده است.
Kong Gateway
Kong Gateway یکی دیگر از گزینههای شناختهشده برای مدیریت ترافیک در Kubernetes است که علاوه بر قابلیتهای Ingress Controller، امکانات گستردهای در حوزه API Gateway نیز ارائه میدهد. این پروژه از Gateway API پشتیبانی میکند و برای سازمانهایی که علاوه بر مسیریابی ترافیک، به قابلیتهایی مانند احراز هویت، Rate Limiting، مدیریت API و سیاستهای امنیتی پیشرفته نیاز دارند، گزینه مناسبی محسوب میشود.
Envoy Gateway
Envoy Gateway با تمرکز بر Gateway API توسعه یافته است و بیشتر برای سازمانهایی مناسب است که قصد دارند معماری مدیریت ترافیک خود را بر پایه استانداردهای جدید کوبرنتیز طراحی کنند. این پروژه یکی از گزینههایی است که در سالهای اخیر توانسته توجه بسیاری از تیمهای Cloud Native را به خود جلب کند.
Envoy Gateway بیشتر برای سازمانهایی مناسب است که قصد دارند از ابتدا بر پایه Gateway API حرکت کنند یا به قابلیتهای پیشرفته مدیریت ترافیک در معماریهای Cloud Native و Microservices نیاز دارند.
NGINX Gateway Fabric
NGINX Gateway Fabric راهکار دیگری است که بر پایه Gateway API توسعه یافته است و توسط اکوسیستم NGINX ارائه میشود. این گزینه میتواند برای تیمهایی که تجربه کار با محصولات NGINX را دارند، مسیر مهاجرت آشناتری ایجاد کند.
NGINX Gateway Fabric گزینه مناسبی برای تیمهایی است که تجربه کار با NGINX را دارند و میخواهند ضمن استفاده از Gateway API، همچنان در اکوسیستم محصولات NGINX باقی بمانند.
نکته مهم: در اطلاعیه رسمی بازنشستگی ingress-nginx، تیم کوبرنتیز استفاده از Gateway API را بهعنوان یکی از مسیرهای آینده مدیریت ترافیک معرفی کرده است. البته Gateway API جایگزین مستقیم و یکبهیک Ingress نیست و معمولا مهاجرت به آن به بررسی دقیق معماری فعلی نیاز دارد.
💡 راهاندازی سریع سرور NGINX در بازارچه همروش
✅ پرداخت به میزان استفاده (PAYG)
✅ بدون دغدغه نگهداری زیرساخت
✅ بکاپ خودکار روزانه
Gateway API؛ چرا در آینده کوبرنتیز اهمیت بیشتری پیدا میکند؟
Gateway API در کوبرنتیز مجموعهای از APIهای جدید برای مدیریت ترافیک در کوبرنتیز است که با هدف ایجاد انعطافپذیری بیشتر و پوشش سناریوهای پیچیدهتر طراحی شده است. بسیاری از پروژههای جدید اکوسیستم کوبرنتیز هم توسعه خود را بر اساس این استاندارد انجام میدهند.
یکی از دلایل توجه گسترده به Gateway API، رفع برخی محدودیتهای مدل سنتی Ingress است. در این استاندارد، قابلیتهایی که پیشتر معمولاً از طریق Annotationهای اختصاصی هر Ingress Controller پیادهسازی میشدند، بهصورت استاندارد و قابل حمل تعریف میشوند. همچنین تفکیک مسئولیتها بین تیمهای زیرساخت و توسعه سادهتر شده و امکان مدیریت سناریوهای پیچیدهتر ترافیک فراهم میشود.
البته این موضوع به معنای حذف Ingress API نیست. در واقع Ingress همچنان بخشی از کوبرنتیز محسوب میشود و بسیاری از کلاسترها به استفاده از آن ادامه میدهند. با این حال، جهتگیری کلی اکوسیستم به سمت استفاده گستردهتر از Gateway API است و به همین دلیل بسیاری از سازمانها هنگام برنامهریزی برای مهاجرت از ingress nginx، این استاندارد را هم در ارزیابیهای خود در نظر میگیرند.
چرا مهاجرت از ingress-nginx همیشه ساده نیست؟
مهاجرت از ingress-nginx به یک کنترلر دیگر یا Gateway API، پیچیدگیهای خاص خود را دارد و فراتر از تبدیل چند فایل YAML است. طی سالهای گذشته، ingress-nginx رفتارها و قابلیتهای خاصی را از طریق Annotationها و تنظیمات اختصاصی ارائه کرده که بخشی از استاندارد کوبرنتیز نیستند و احتمالا در راهکارهای دیگر باید به شکل متفاوت یا بدون معادل مستقیم پیادهسازی شوند. حتی اگر تبدیلات ظاهرا درست انجام شوند، ممکن است رفتار سرویسها تغییر کند یا اختلالی ایجاد شود. بر اساس مستندات رسمی کوبرنتیز، هنگام مهاجرت باید به موارد زیر توجه ویژه داشت:
- پردازش مسیرهای مبتنی بر Regular Expression
- تاثیر Annotationهای اختصاصی مانند use-regex
- رفتار وابسته به rewrite-target
- مدیریت مسیرهای دارای یا فاقد / انتهایی
- تفاوت در URL Normalization
این موارد ممکن است در کنترلر جدید یا پیادهسازیهای Gateway API به شکل متفاوتی عمل کنند، بنابراین قبل از انتقال کامل ترافیک، تنظیمات جدید باید بهدقت بررسی و آزمایش شوند. جامعه کوبرنتیز ابزارهایی برای سادهتر کردن این فرایند توسعه داده است که در بخش بعدی به مهمترین آنها، یعنی Ingress2Gateway، میپردازیم.
مهاجرت واقعی و ابزارها؛ آموزش عملی با Ingress2Gateway
تا اینجا دیدیم که مهاجرت از ingress-nginx همیشه یک تبدیل ساده و یکبهیک نیست. در واقع تفاوت در Annotationها، رفتارهای خاص این کنترلر و تفاوت معماری Gateway API باعث میشود که انتقال بدون برنامهریزی، ریسک ایجاد اختلال در سرویس را به همراه داشته باشد.
تیم SIG Network ابزار رسمی Ingress2Gateway را معرفی کرده است. در مستندات رسمی، این ابزار بهعنوان یک Migration Assistant یا دستیار مهاجرت معرفی میشود که میتواند بررسی Ingressهای فعلی را انجام دهد و آنها را تا حد امکان به Gateway API تبدیل کند. همچنین میتواند در عین حال، در مورد بخشهایی که نیاز به بازبینی دستی دارند به شما هشدار دهد. به طور کلی، Ingress2Gateway سه هدف اصلی زیر را دنبال میکند:
- تبدیل پیکربندی: ترجمه Ingressها و Annotationهای پشتیبانیشده به Gateway API
- شناسایی مشکلات: تشخیص تنظیماتی که معادل مستقیمی ندارند
- ارائه پیشنهاد: اعلام هشدارها و پیشنهاد برای اصلاح دستی
نسخه ۱.۰ چه قابلیتهایی دارد؟
نسخه ۱.۰ که در مارس ۲۰۲۶ منتشر شد، نسبت به نسخههای قبلی پیشرفت قابل توجهی داشته است. مهمترین تغییرات این نسخه عبارتاند از:
- پشتیبانی از بیش از ۳۰ Annotation رایج ingress-nginx
- پشتیبانی از قابلیتهایی مانند CORS ،Backend TLS ،Regex Matching و Path Rewrite
- تستهای یکپارچگی برای اطمینان از یکسان بودن رفتار Ingress-NGINX و Gateway API
- سیستم هشدار و گزارشدهی برای بخشهایی که قابل ترجمه نیستند
مرحله اول: نصب Ingress2Gateway
برای استفاده از این ابزار، ابتدا باید آن را نصب کنید. اگر روی سیستم خود محیط Go را دارید، میتوانید با دستور زیر آخرین نسخه پایدار را نصب کنید:
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0اگر از macOS و Homebrew استفاده میکنید، دستور نصب آن سادهتر است:
brew install ingress2gatewayهمچنین امکان دانلود فایل باینری از GitHub یا کامپایل ابزار از سورس هم وجود دارد.
مرحله دوم: اجرای Ingress2Gateway
پس از نصب میتوانید مانیفستهای Ingress را به Ingress2Gateway ارسال کنید، یا ابزار را مستقیما از کلاستر خود بخوانید.
# ارسال به فایل
ingress2gateway print --input-file my-manifest.yaml,my-other-manifest.yaml --providers=ingress-nginx > gwapi.yaml
# استفاده از فضای نام در کلاستر خودتان
ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml
# یا برای کل کلاستر
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yamlنکته: همچنین میتوانید --emitter <agentgateway|envoy-gateway|kgateway> را برای خروجی پسوندهای خاص پیادهسازی ارسال کنید.
مرحله سوم: بررسی خروجی
این مهمترین مرحله است. دستورات بخش قبلی یک مانیفست Gateway API را در gwapi.yaml خروجی میدهند. همچنین هشدارهایی منتشر میکنند که توضیح میدهند چه چیزی دقیقا ترجمه نشده است و چه چیزی را باید به صورت دستی مرور کنید.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-dev
name: nginx
namespace: my-ns
spec:
gatewayClassName: nginx
listeners:
- hostname: my-host.example.com
name: my-host-example-com-http
port: 80
protocol: HTTP
- hostname: my-host.example.com
name: my-host-example-com-https
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: ""
kind: Secret
name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-dev
name: my-ingress-my-host-example-com
namespace: my-ns
spec:
hostnames:
- my-host.example.com
parentRefs:
- name: nginx
port: 443
rules:
- backendRefs:
- name: website-service
port: 80
filters:
- cors:
allowCredentials: true
allowHeaders:
- DNT
- Keep-Alive
- User-Agent
- X-Requested-With
- If-Modified-Since
- Cache-Control
- Content-Type
- Range
- Authorization
allowMethods:
- GET
- PUT
- POST
- DELETE
- PATCH
- OPTIONS
allowOrigins:
- '*'
maxAge: 1728000
type: CORS
matches:
- path:
type: RegularExpression
value: (?i)/users/(\d+).*
name: rule-0
timeouts:
request: 10s
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-dev
name: my-ingress-my-host-example-com-ssl-redirect
namespace: my-ns
spec:
hostnames:
- my-host.example.com
parentRefs:
- name: nginx
port: 80
rules:
- filters:
- requestRedirect:
scheme: https
statusCode: 308
type: RequestRedirectهمانطور که در بالا مشاهده کردید، Ingress2Gateway با موفقیت برخی annotationها را به معادلهای Gateway API خود ترجمه کرد. به عنوان مثال، nginx.ingress.kubernetes.io/enable-cors به یک فیلتر CORS ترجمه شد، اما با بررسی دقیقتر، annotationهای nginx.ingress.kubernetes.io/proxy-{read,send}-timeout و nginx.ingress.kubernetes.io/proxy-body-size کاملا نگاشت نمیشوند. لاگها دلیل این حذفیات و همچنین استدلال پشت ترجمه را نشان میدهند.
┌─ WARN ────────────────────────────────────────
│ Unsupported annotation nginx.ingress.kubernetes.io/configuration-snippet
│ source: INGRESS-NGINX
│ object: Ingress: my-ns/my-ingress
└─
┌─ INFO ────────────────────────────────────────
│ Using case-insensitive regex path matches. You may want to change this.
│ source: INGRESS-NGINX
│ object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN ────────────────────────────────────────
│ ingress-nginx only supports TCP-level timeouts; i2gw has made a best-effort translation to Gateway API timeouts.request. Please verify that this meets your needs. See documentation: https://gateway-api.sigs.k8s.io/guides/http-timeouts/
│ source: INGRESS-NGINX
│ object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN ────────────────────────────────────────
│ Failed to apply my-ns.my-ingress.metadata.annotations."nginx.ingress.kubernetes.io/proxy-body-size" from my-ns/my-ingress: Most Gateway API implementations have reasonable body size and buffering defaults
│ source: STANDARD_EMITTER
│ object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN ────────────────────────────────────────
│ Gateway API does not support configuring URL normalization (RFC 3986, Section 6). Please check if this matters for your use case and consult implementation-specific details.
│ source: STANDARD_EMITTER
└─یک هشدار وجود دارد که Ingress2Gateway از annotation نوع nginx.ingress.kubernetes.io/configuration-snippet پشتیبانی نمیکند. برای دیدن اینکه آیا راهی برای دستیابی به رفتار معادل وجود دارد، باید مستندات پیادهسازی Gateway API خود را بررسی کنید.
این ابزار همچنین به ما اطلاع داد که تطابقهای ریجکس Ingress-NGINX تطابقهای پیشوندی غیر حساس به حروف کوچک و بزرگ هستند. به همین دلیل یک الگوی تطابق (?i)/users/(\d+).* وجود دارد. بیشتر سازمانها میخواهند این رفتار را با حذف (?i) ابتدایی و .* انتهایی از الگوی مسیر به یک تطابق دقیق و حساس به حروف کوچک و بزرگ تغییر دهند.
Ingress2Gateway ترجمهای با بهترین تلاش از annotationهای nginx.ingress.kubernetes.io/proxy-{send,read}-timeout به یک زمان انتظار درخواست ۱۰ ثانیه در مسیر HTTP ما انجام داد. اگر درخواستهای این سرویس باید بسیار کوتاهتر باشد (مثلا ۳ ثانیه)، میتوانید تغییرات مربوطه را در مانیفستهای Gateway API خود اعمال کنید.
همچنین، nginx.ingress.kubernetes.io/proxy-body-size معادل Gateway API ندارد، بنابراین ترجمه نشده است. البته با این حال، بیشتر پیادهسازیهای Gateway API، پیشفرضهای معقولی برای حداکثر اندازه بدنه و بافرینگ دارند، بنابراین این موضوع، ممکن است در عمل مشکلی ایجاد نکند.
علاوه بر این، برخی emitterها ممکن است پشتیبانی از این annotation را از طریق پسوندهای خاص پیادهسازی ارائه دهند. به عنوان مثال، افزودن فلگ --emitter agentgateway یا --emitter envoy-gateway یا --emitter kgateway به دستور ingress2gateway print قبلی منجر به پیکربندی خاص پیادهسازی اضافی در مانیفستهای Gateway API تولید شده میشد که سعی در ثبت پیکربندی اندازه بدنه (body size) داشت.
همچنین یک هشدار در مورد نرمالایز کردن URL میبینیم. پیادهسازیهای Gateway API مانند Agentgateway ،Envoy Gateway ،Kgateway و Istio دارای سطحی از عادیسازی URL هستند؛ اما رفتار در پیادهسازیها متفاوت است و از طریق Gateway API استاندارد قابل تنظیم نیست. شما باید رفتار عادیسازی URL پیادهسازی Gateway API خود را بررسی و آزمایش کنید تا مطمئن شوید با مورد استفاده شما سازگار است.
همچنین برای مطابقت با رفتار پیشفرض Ingress-NGINX، ابزار Ingress2Gateway یک شنونده در پورت ۸۰ و یک فیلتر تغییر مسیر درخواست HTTP برای هدایت ترافیک HTTP به HTTPS اضافه کرد. ممکن است اصلا نخواهید به ترافیک HTTP سرویس بدهید و شنونده پورت ۸۰ و HTTPRoute مربوطه را حذف کنید.
هشدار: همیشه خروجی و لاگهای تولید شده را به طور کامل مرور کنید.
پس از اعمال دستی این تغییرات، مانیفستهای Gateway API ممکن است به شکل زیر باشد:
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-dev
name: nginx
namespace: my-ns
spec:
gatewayClassName: nginx
listeners:
- hostname: my-host.example.com
name: my-host-example-com-https
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: ""
kind: Secret
name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-dev
name: my-ingress-my-host-example-com
namespace: my-ns
spec:
hostnames:
- my-host.example.com
parentRefs:
- name: nginx
port: 443
rules:
- backendRefs:
- name: website-service
port: 80
filters:
- cors:
allowCredentials: true
allowHeaders:
- DNT
...
allowMethods:
- GET
...
allowOrigins:
- '*'
maxAge: 1728000
type: CORS
matches:
- path:
type: RegularExpression
value: /users/(\d+)
name: rule-0
timeouts:
request: 3sمرحله چهارم: بازبینی (Verify)
اکنون که مانیفستهای Gateway API را دارید، باید آنها را به طور کامل در یک کلاستر توسعه آزمایش کنید. در این مورد، حداقل باید بررسی کنید که پیشفرضهای حداکثر اندازه بدنه پیادهسازی Gateway API برای شما مناسب است و تأیید کنید که زمان انتظار ۳ ثانیه کافی است.
پس از تایید رفتار در یک کلاستر توسعه، پیکربندی Gateway API خود را در کنار Ingress موجود خود مستقر کنید. پیشنهاد میکنیم که ترافیک را با استفاده از DNS وزندار، لود بالانسر ابری خود یا ویژگیهای تقسیم ترافیک پلتفرم خود به تدریج تغییر دهید. به این ترتیب، میتوانید به سرعت، هرگونه پیکربندی اشتباهی را که از تستهای شما عبور کرده است، بازیابی کنید.
در نهایت، پس از انتقال کامل ترافیک به کنترلر Gateway API، ابتدا منابع Ingress را حذف و سپس کنترلر Ingress قدیمی را uninstall کنید.
جمعبندی
مهمترین نکته این است که مهاجرت از ingress-nginx را نباید به زمانی موکول کرد که یک آسیبپذیری یا ناسازگاری عملیاتی شما را مجبور به تغییر کند. هرچه وابستگی به ingress-nginx بیشتر شود، هزینه و پیچیدگی مهاجرت نیز افزایش خواهد یافت.
گزینههای جایگزین شامل Traefik ،Envoy Gateway ،Kong Gateway و NGINX Gateway Fabric هستند و مسیر آینده اکوسیستم، Gateway API است. با برنامهریزی درست، بررسی زیرساخت، اصلاح مانیفستها و تست در محیط توسعه، میتوانید مهاجرت تدریجی و امن را انجام دهید و بدون اختلال سرویسها، به معماری مدرن کوبرنتیز برسید.