APISIX روی Kubernetes؛ راهنمای مدیریت ترافیک و API

با افزایش تعداد سرویس‌ها در Kubernetes، مدیریت ترافیک ورودی به مسیریابی ساده محدود نمی‌ماند. تیم‌ها به کنترل دسترسی، محدودسازی نرخ درخواست، مدیریت TLS و مشاهده خطاهای ارتباطی نیاز پیدا می‌کنند. Apache APISIX یک API Gateway متن‌باز است که می‌تواند در این لایه قرار بگیرد و سیاست‌های مشترک ترافیک را اعمال کند.

استقرار APISIX روی Kubernetes به سازمان کمک می‌کند بخشی از تنظیمات ارتباطی سرویس‌ها را به‌صورت متمرکز و اعلانی مدیریت کند. برای استفاده درست، باید تفاوت خود Gateway با Ingress Controller، روش نگهداری پیکربندی و نیازهای بهره‌برداری آن روشن باشد.

APISIX در Kubernetes چه نقشی دارد؟

در یک معماری متداول، درخواست کاربر ابتدا به Load Balancer می‌رسد، سپس وارد APISIX می‌شود و پس از تطبیق مسیر و اعمال سیاست‌ها، به سرویس مقصد هدایت می‌شود.

برای مثال، درخواست‌های مسیر /api/orders می‌توانند به سرویس سفارش‌ها و درخواست‌های /api/users به سرویس کاربران برسند. در همین مسیر، Gateway می‌تواند سیاست‌های احراز هویت، محدودیت نرخ یا ثبت اطلاعات درخواست را اعمال کند؛ البته هر قابلیت به افزونه و پیکربندی مناسب نیاز دارد.

متمرکزشدن این سیاست‌ها، نیاز برنامه به کنترل دسترسی و اعتبارسنجی داخلی را حذف نمی‌کند. Gateway و برنامه مسئولیت‌های مکمل دارند.

تفاوت APISIX با APISIX Ingress Controller چیست؟

APISIX Gateway درخواست‌های واقعی کاربران را پردازش می‌کند. APISIX Ingress Controller منابع Kubernetes را مشاهده و آن‌ها را به پیکربندی قابل استفاده برای Gateway تبدیل می‌کند.

در نتیجه، مسیر پردازش ترافیک از مسیر مدیریت پیکربندی جداست. این تفاوت هنگام عیب‌یابی اهمیت دارد: اختلال در اعمال یک Route جدید لزوماً همان مسئله‌ای نیست که باعث خطای درخواست‌های کاربران می‌شود.

کنترلر APISIX از منابع Ingress، منابع پشتیبانی‌شده Gateway API و منابع سفارشی APISIX برای تعریف تنظیمات استفاده می‌کند. قابلیت‌های دقیق هر مسیر باید با نسخه نصب‌شده بررسی شوند. معرفی رسمی APISIX Ingress Controller.

Ingress، Gateway API یا منابع اختصاصی APISIX؟

انتخاب روش تعریف مسیرها، روی قابلیت حمل تنظیمات و نحوه همکاری تیم‌ها اثر دارد.

Ingress برای تعریف مسیرهای متداول HTTP و HTTPS مناسب است. قابلیت‌های فراتر از مدل استاندارد آن ممکن است به تنظیمات وابسته به کنترلر نیاز داشته باشند.

Gateway API منابعی با مسئولیت‌های تفکیک‌شده ارائه می‌کند. برای نمونه، تیم زیرساخت می‌تواند Gateway را مدیریت کند و تیم برنامه مسیرهای HTTP را تعریف کند. این مدل برای سازمان‌هایی که چند تیم از زیرساخت مشترک استفاده می‌کنند، قابل بررسی است.

منابع سفارشی APISIX نیز برای تنظیم قابلیت‌های اختصاصی این محصول کاربرد دارند. استفاده از آن‌ها باید همراه با آگاهی از وابستگی پیکربندی به APISIX باشد.

پیش از انتخاب، منابع، فیلدها و نسخه‌های پشتیبانی‌شده را بررسی کنید؛ پشتیبانی از Gateway API به معنی پیاده‌سازی تمام قابلیت‌های آن نیست. راهنمای رسمی Gateway API در APISIX.

قابلیت‌های کاربردی APISIX برای سرویس‌های سازمانی

مسیریابی و توزیع درخواست

می‌توان ترافیک را بر اساس قواعد تعریف‌شده به Backend مناسب هدایت کرد. در طراحی مسیرها باید تطبیق Host و Path، رفتار بازنویسی مسیر و تنظیمات ارتباط با سرویس مقصد مشخص باشند.

احراز هویت و کنترل مصرف API

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

برای نمونه، محدودیت نرخ یکسان برای تمام APIها ممکن است عملیات حساس و درخواست‌های عادی را به‌شکل نامناسبی محدود کند.

ثبت و پایش ترافیک

اطلاعات Gateway می‌تواند در بررسی زمان پاسخ، خطاهای Backend و رفتار درخواست‌ها کمک کند. داده‌های ثبت‌شده باید با نیاز عیب‌یابی و سیاست حفاظت از اطلاعات هماهنگ باشند؛ ثبت بی‌ضابطه Headerها یا محتوای درخواست، انتخاب مناسبی برای همه سرویس‌ها نیست.

آیا APISIX همیشه به etcd نیاز دارد؟

خیر. پاسخ به حالت استقرار و روش تأمین پیکربندی بستگی دارد.

در حالت‌های Traditional و Decoupled، معماری مستندشده APISIX از etcd برای نگهداری پیکربندی استفاده می‌کند. در حالت Standalone، امکان دریافت پیکربندی کامل از فایل وجود دارد و مسیر API-driven نیز برای یکپارچه‌سازی‌های مشخص مستند شده است.

بنابراین نباید معماری یک مثال نصب را برای تمام محیط‌ها مناسب دانست. روش انتخابی باید با نسخه Gateway، کنترلر و سازوکار تحویل پیکربندی سازگار باشد. مستندات رسمی حالت‌های استقرار APISIX.

مسیر پیشنهادی راه‌اندازی APISIX روی Kubernetes

نیازهای ترافیکی را مشخص کنید. پروتکل‌ها، دامنه‌ها، سیاست TLS، احراز هویت و حجم مورد انتظار درخواست‌ها را فهرست کنید.
نسخه‌ها و معماری را انتخاب کنید. سازگاری Kubernetes، APISIX، کنترلر و Chart نصب را بررسی و حالت استقرار را تعیین کنید.
ورودی کلاستر را طراحی کنید. مشخص کنید Gateway چگونه در دسترس قرار می‌گیرد و درخواست‌ها از چه مسیر شبکه‌ای عبور می‌کنند.
یک سرویس آزمایشی منتشر کنید. ابتدا یک مسیر ساده بسازید و پاسخ Backend، TLS و خطاهای احتمالی را بررسی کنید.
سیاست‌ها را مرحله‌ای اضافه کنید. هر سیاست احراز هویت، محدودیت نرخ یا بازنویسی را جداگانه آزمایش کنید.
رفتار خرابی و ارتقا را بسنجید. از دسترس خارج‌شدن یک نمونه Gateway، اختلال کنترلر و بازگرداندن پیکربندی قبلی را در محیط آزمایشی بررسی کنید.

نکات مهم بهره‌برداری در محیط عملیاتی

تعداد Replicaها به‌تنهایی تضمین‌کننده دسترس‌پذیری نیست. توزیع Podها میان گره‌ها، سلامت Backendها، رفتار Load Balancer و وابستگی‌های پیکربندی نیز باید بررسی شوند.

همچنین دسترسی به رابط‌های مدیریتی باید محدود و متناسب با معماری باشد. ترافیک کاربران، مسیر مدیریت و مجوزهای کنترلر را آگاهانه طراحی کنید.

شاخص‌های پایش نیز باید دو بخش را پوشش دهند: سلامت پردازش درخواست‌ها و موفقیت اعمال پیکربندی. افزایش خطاهای کاربران با اعمال‌نشدن یک تغییر جدید، مسیر بررسی یکسانی ندارد.

APISIX چه زمانی انتخاب قابل بررسی است؟

وقتی سرویس‌های متعدد به سیاست‌های مشترک API، تنظیمات اعلانی و مدیریت متمرکز ترافیک نیاز دارند، APISIX می‌تواند یکی از گزینه‌های ارزیابی باشد. انتخاب نهایی باید بر اساس نیاز واقعی، سازگاری قابلیت‌ها و توان تیم بهره‌برداری انجام شود.

برای بررسی طراحی، استقرار و پشتیبانی این لایه در زیرساخت سازمان، صفحهٔ خدمات تخصصی دواپس ایران را ببینید.

مدیریت ترافیک Kubernetes را اصولی طراحی کنیدبرای بررسی نیازهای استقرار، پایش و پشتیبانی زیرساخت، با خدمات دواپس ایران آشنا شوید.مشاهده خدمات دواپس ←