چرا اکنون باید به Cilium مهاجرت کرد

به گزارش از وبسایت cncf 🙂

اگر Kubernetes را اجرا می‌کنید، احتمال زیادی وجود دارد که از ingress-nginx برای مسیر‌دهی ترافیک خارجی به بارکاری‌های خود استفاده کنید. برای سال‌ها ingress-nginx کنترلر پیش‌فرض و محبوب متن‌باز بوده است و به‌خاطر پایداری و حمایت گستردهٔ جامعه مورد اعتماد قرار گرفته است. مطابق داده‌های گزارش اخیر State of Kubernetes Networking، هم‌اکنون 50٪ پاسخ‌دهندگان از Ingress-nginx استفاده می‌کنند. اما به‌زودی این وضعیت تغییر خواهد کرد. ⚠️

پایان نگهداری Ingress-nginx: این چه معنایی برای شما دارد؟

تیم نگهداری ingress-nginx اعلام کرده است که این پروژه در ابتدای سال 2026 آرشیو خواهد شد. یعنی دیگر به‌صورت فعال نگهداری، انتشار وصله‌های امنیتی یا رفع باگ برای آن انجام نخواهد شد. این خبر که در کنفرانس KubeCon مطرح شد، نقطهٔ عطف مهمی برای هزاران کاربر و سازمانی است که استراتژی ingress خود را بر مبنای آن ساخته‌اند.

راه‌های پیش روی شما چیست؟

با بازنشستگی ingress-nginx، تیم‌های پلتفرم باید بین دو گزینه یکی را انتخاب کنند: نگه داشتن یک مؤلفهٔ حیاتی کنترلی بدون نگهداری از upstream یا مهاجرت به جایگزین‌هایی که فعالانه پشتیبانی می‌شوند.

جامعه Kubernetes روی Gateway API به‌عنوان استاندارد بلندمدت مدیریت ترافیک توافق کرده است. این جهت‌گیری دو مسیر اصلی مهاجرت را تعیین می‌کند:

حرکت به سمت یک ingress controller دیگر (مانند Cilium Ingress، Traefik یا HAProxy Ingress). 🚀

پذیرش Kubernetes Gateway API، استاندارد نسل بعدی برای ingress و مدیریت ترافیک، با استفاده از یک controller مانند Cilium Gateway API. 🔁

Cilium هر دو مسیر را میسر می‌کند: می‌توانید ابتدا از Cilium Ingress به‌عنوان جایگزین همسان استفاده کنید و سپس بدون تغییر فروشنده، controller یا datapath به Gateway API مهاجرت کنید.

گزینهٔ 1 — سریع‌ترین: مهاجرت به Cilium Ingress

Cilium Ingress یک ingress controller هم‌جایگزین است که از منابع استاندارد Kubernetes Ingress پشتیبانی می‌کند. این کنترلر روی datapath مبتنی بر eBPF Cilium اجرا می‌شود و عملکرد بالا، دید عمیق و یکپارچگی ساده با Cilium Network Policies را ارائه می‌دهد.

چرا تیم‌ها این مسیر را انتخاب می‌کنند؟

تغییرات حداقلی در manifestهای برنامه و خطوط CI/CD.

ادامهٔ استفاده از یک محصول فعال که مسیر روشنی از وابستگی‌های خاص NGINX فراهم می‌کند.

قابلیت مشاهدهٔ درون‌ساخته و امنیت قوی‌تر از طریق ابزارهای Cilium. 🔒

نکاتی که باید مراقب باشید

Annotations و directiveهای مخصوص NGINX به صورت مستقیم قابل تبدیل نیستند.

اگر به بازنویسی‌های پیچیده یا رفتارهای پیشرفتهٔ NGINX وابسته‌اید، یک فاز اعتبارسنجی برنامه‌ریزی کنید تا این قابلیت‌ها را به معادل‌های Cilium نگاشت کنید؛ یا در صورت نیاز، Gateway API را برای امکانات مسیریابی پیشرفته‌تر در نظر بگیرید.

چگونه از ingress-nginx به Cilium Ingress مهاجرت کنیم:

1. فهرست‌برداری استفادهٔ فعلی از Ingress: میزبان‌ها، مسیرها، تنظیمات TLS، annotations، قوانین بازنویسی و محدودیت‌های نرخ را ثبت کنید.

2. نصب یا بررسی Cilium: دستورالعمل‌های Cilium Getting Started را دنبال کنید.

3. فعال‌سازی Cilium Ingress: مستندات Cilium Ingress را ملاحظه کنید.

4. به‌روزرسانی manifestها برای هدف‌گیری ingress class مربوط به Cilium: ingressClassName را به cilium تغییر دهید و در صورت لزوم annotationهای مخصوص NGINX را حذف کنید.

[pyaml]
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
namespace: apps
spec:
ingressClassName: cilium
rules:
– host: my-app.example.com
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: my-app-svc
port:
number: 80
[/yaml]

5. اعتبارسنجی و برش: TLS، مسیر‌دهی مسیرها و سیاست‌های شبکه را در محیط staging آزمایش کنید قبل از اینکه ترافیک تولید را منتقل کنید. ✅

گزینهٔ 2 — پیشنهادی: ارتقاء به پیاده‌سازی Gateway API از سوی Cilium

در حالی که مهاجرت به Cilium Ingress سریع‌ترین راه برای دور شدن از ingress-nginx است، اکوسیستم Kubernetes به‌سمت Gateway API حرکت می‌کند.

Gateway API یک زیرپروژه از SIG-Network است و به‌عنوان جانشین Ingress تعریف شده است؛ این مدل نه تنها ترافیک north-south را پوشش می‌دهد، بلکه ورودی‌های east-west و نقاط ورود سرویس‌مش را نیز از طریق یک مدل قابل توسعه و یکپارچه مدیریت می‌کند.

پیاده‌سازی Cilium از تمام منابع Core Gateway API و اکثر ویژگی‌های Extended (اختیاری) پشتیبانی می‌کند و آن‌ها را با عملکرد مبتنی بر eBPF، مشاهده‌پذیری و یکپارچگی سیاست‌ها تقویت می‌کند.

چرا پیاده‌سازی Gateway API از Cilium را انتخاب کنید؟

پیاده‌سازی Gateway API در Cilium تنها یک جایگزین نیست؛ بلکه ارتقایی است که مزایای متعددی از جمله کنترل ترافیک پیشرفته و ساده‌سازی عملیات را به همراه دارد. 🚀

مدیریت ترافیک پیشرفته: پشتیبانی بومی از مسیریابی مبتنی بر header، تقسیم ترافیک و مسیرهای cross-namespace.

مدیریت ترافیک یکپارچه (GAMMA): استفاده از یک API واحد و سازگار (Gateway API) برای مدیریت ترافیک خارجی و داخلی، که عملیات و اعمال سیاست را ساده‌تر می‌کند.

تفکیک نقش‌ها: جداسازی زیرساخت از مسیریابی برنامه برای امنیت بهتر و پشتیبانی از multi-tenancy.

یکپارچگی غنی با سیاست‌ها: ترکیب مسیریابی L7 با Cilium Network Policies و قابلیت‌های مشاهده‌پذیری Hubble.

همسویی با آینده: Gateway API به‌عنوان استاندارد مورد تأیید SIG-Network و تعدادی از ارائه‌دهندگان بزرگ ابری پذیرفته شده است.

ویژگی‌های کلیدی نسبت به Ingress چه هستند؟

در حالی که Ingress برای نیازهای اساسی مناسب بوده است، طراحی آن محدودیت‌هایی در مدیریت ترافیک پیشرفته دارد. Gateway API، به‌خصوص با پیاده‌سازی Cilium، کنترل و انعطاف‌پذیری بیشتری را فراهم می‌آورد: از مسیریابی مبتنی بر header و تقسیم ترافیک تا پشتیبانی cross-namespace، مدیریت east-west و جداسازی نقش‌ها؛ همچنین مشاهده‌پذیری و سیاست‌های امنیتی پیشرفته‌تر ارائه می‌شود.

مهاجرت به پیاده‌سازی Gateway API از Cilium:

1. اطمینان از نصب و پیکربندی Cilium برای Gateway API: مستندات Cilium Gateway API را بررسی کنید.

2. نصب CRDهای Gateway API: اگر توزیع Kubernetes شما Gateway API را همراه ندارد، CRDها را مطابق راهنمای نصب Gateway API اضافه کنید.

3. تعریف GatewayClass و Gateway: در زیر یک نمونه ساده آمده است؛ مثال‌های بیشتر در آموزش‌ها وجود دارد.

[pyaml]
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: cilium
spec:
controllerName: io.cilium/gateway-controller
—
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
namespace: default
spec:
gatewayClassName: cilium
listeners:
– name: http
protocol: HTTP
port: 80
[/yaml]

4. تبدیل قوانین Ingress به HTTPRoute: مدل جدید Gateway API به تیم‌های اپلیکیشن اجازه می‌دهد تا مسیرها و backendها را تعریف کنند، از جمله مراجع cross-namespace؛ این کار مسئولیت را از مالک پلتفرم جدا می‌کند.

[pyaml]
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-app
namespace: apps
spec:
parentRefs:
– name: shared-gw
namespace: infra
rules:
– matches:
– path:
type: PathPrefix
value: /
headers:
– name: X-Canary
value: “true”
backendRefs:
– name: my-app-svc
port: 80
[/yaml]

5. آزمون امکانات پیشرفته: قابلیت‌هایی مانند مسیریابی مبتنی بر header، تقسیم ترافیک و سناریوهای cross-namespace را در staging یا محیط توسعه تست کنید و سپس به تولید منتقل کنید. این امکانات قبلاً در Kubernetes Ingress در دسترس نبودند.

استفاده از ابزار Ingress-to-Gateway برای مهاجرت

برای تیم‌هایی که تعداد زیادی منابع Ingress دارند، ترجمهٔ دستی ممکن است وقت‌گیر و خطاپذیر باشد.

برای ساده‌سازی مهاجرت، راهنمایی وجود دارد با عنوان How to Migrate from Kubernetes Ingress to Gateway API که یک ابزار مهاجرت را معرفی می‌کند تا بخش عمده‌ای از تبدیل را خودکار کند.

برای مجموعه‌های بزرگ، تبدیل دستی هر Ingress کند و پر از خطا است. ابزار ingress2gateway از Kubernetes SIG Network منابع Ingress موجود را به منابع Gateway API تبدیل می‌کند، یا از kubeconfig فعلی می‌خواند یا از فایل‌های ورودی. این نقطهٔ شروعی محکم فراهم می‌کند که می‌توانید آن را بازبینی کرده و با Cilium Gateway API اعمال کنید.

[pyaml]
ingress2gateway print
–providers=cilium
[/yaml]

اعلان‌ها از CILIUM:

[pyaml]
+————–+—————————————————————————————————————-+———————————————————–+
| MESSAGE TYPE | NOTIFICATION | CALLING OBJECT |
+————–+—————————————————————————————————————-+———————————————————–+
| INFO | parsed “ingress.cilium.io/force-https” annotation of ingress and patched httproute.spec.rules[].filters fields | HTTPRoute: default/basic-ingress-https-httpbin-cilium-com |
+————–+—————————————————————————————————————-+———————————————————–+
[/yaml]

[pyaml]
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-0.4.0
creationTimestamp: null
name: cilium
namespace: default
spec:
gatewayClassName: cilium
listeners:
– hostname: httpbin.cilium.com
name: httpbin-cilium-com-http
port: 80
protocol: HTTP
– hostname: httpbin.cilium.com
name: httpbin-cilium-com-https
port: 443
protocol: HTTPS
tls:
certificateRefs:
– group: null
kind: null
name: demo-cert
status: {}
—
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.
[/yaml]

اگر مایل باشید می‌توانم یک چک‌لیست مهاجرت متناسب با وضعیت کلاستر شما تهیه کنم یا در تبدیل منابع Ingress کمک کنم تا مسیر مهاجرت شما هموارتر شود. 🔧