پایان دوره iptables در کلاسترها؛ تثبیت eBPF و Gateway API به عنوان استاندارد شبکه
حذف سربار O(N) زنجیرههای فایروال با تثبیت eBPF و انتشار استانداردهای جدید Gateway API؛ چرا تیمهای زیرساخت باید فیلترینگ ترافیک را از فضای کاربری به کرنل منتقل کنند؟

منبع اصلی: [Kubernetes Official Networking Architecture Reports] · تاریخ بررسی: 2026-11-05
خبر تأییدشده
گزارشهای جدید معماری شبکه در اکوسیستم کلود نیتیو نشان میدهند که استفاده از iptables به عنوان موتور مسیریابی سرویسها رسماً وارد فاز استهلاک شده و استقرار شبکههای مبتنی بر eBPF در کنار استانداردسازی Kubernetes Gateway API به عنوان پیشفرض تولید تثبیت شده است. رانتایمهای شبکه اکنون فیلترینگ و احراز هویت لایه ۴ تا ۷ را مستقیماً در مسیر دادههای کرنل انجام میدهند.
تحلیل تحریریه
برای سالها، بخش شبکه کوبرنتیز با kube-proxy و زنجیرههای متوالی iptables مدیریت میشد. مشکل این رویکرد زمانی آشکار میشد که تعداد سرویسها از چند هزار فراتر میرفت: الگوریتم پیمایش خطی $O(N)$ در iptables باعث میشد به ازای ورود هر پکت، پردازنده صدها رول را پشت سر هم مقایسه کند. این مسئله به افزایش شدید تأخیر (Latency Jitter) و مصرف بالای CPU منجر میشد.
با جایگزینی ساختارهای جدولی eBPF Maps با زمان جستجوی ثابت $O(1)$، تأخیر شبکه حتی در کلاسترهای غولپیکر با دهها هزار پاد ثابت باقی میماند. علاوه بر این، ادغام اخیر با Gateway API امکان هدایت ترافیک هوشمند، تفکیک دسترسی بین تیمها و اعمال سیاستهای امنیتی بدون نیاز به تزریق سایدبارهای سنگین پروکسی (Sidecarless Architecture) را مستقیماً در لایه زیرساخت شبکه فراهم کرده است.
برداشت تحریریه این است که این تغییر، بار کاری تیمهای DevOps را از نگهداری سایدکارهای پیچیده رها میکند و کنترل امنیت را به سطح هسته سیستمعامل ارتقا میدهد.
پیش از تصمیم بررسی کنیم
- سازگاری نسخه هسته لینوکس سرورها (نیازمند حداقل لینوکس 5.10 و بالاتر برای پشتیبانی کامل از امکانات پیشرفته eBPF).
- بررسی مانیتورینگ شبکه؛ ابزارهای سنتی مثل
iptables -Lدیگر ترافیک را نشان نخواهند داد و باید مانیتورینگ به متریکهای مبتنی بر نگاشتهای eBPF منتقل شود. - تست عملکرد و ارزیابی مسیرهای بازگشت اضطراری در هنگام خطاهای لایه داده.
جمعبندی کاربردی
برای تیمهای زیرساخت، ماندن روی پشته قدیمی فایروالینگ صرفاً به معنی هدررفت منابع محاسباتی و تأخیر پنهان در پاسخدهی به کلاینتهاست. بازطراحی مسیر ترافیک به سمت eBPF و Gateway API، سرمایهگذاری ضروری روی ثبات کلاسترهای ابری است.



