جداسازی مسئولیت‌ها
Gateway API مجموعه‌ای از رابط‌ها برای مدیریت شبکه سرویس‌هاست. در مدل اصلی، GatewayClass نوع پیاده‌سازی و کنترل‌گر را مشخص می‌کند؛ Gateway درگاه‌ها و شنونده‌های موردنیاز را توصیف می‌کند؛ و منابعی مانند HTTPRoute قواعد هدایت درخواست به سرویس‌های پشتی را بیان می‌کنند.
نمودار رسمی همین جداسازی را نشان می‌دهد: مسئول زیرساخت، تیم پلتفرم و توسعه‌دهنده برنامه الزاماً یک شخص یا یک حساب نیستند. قرار نیست برای تغییر یک مسیر برنامه، اختیار همه تنظیمات شبکه به همان تیم واگذار شود.
تعریف API با اجرای ترافیک فرق دارد
وجود تعریف منابع در خوشه، به‌تنهایی پراکسی یا توازن‌گر بار ایجاد نمی‌کند؛ یک پیاده‌سازی سازگار باید این منابع را پردازش کند. پشتیبانی از قابلیت‌های توسعه‌یافته نیز می‌تواند بین کنترل‌گرها متفاوت باشد. وضعیت‌های گزارش‌شده توسط کنترل‌گر را بخوانید و صرف پذیرش فایل توسط API Server را موفقیت مسیریابی ندانید.
مثال طراحی پیشنهادی
فرض کنید تیم پلتفرم یک Gateway مشترک برای دو برنامه فراهم می‌کند. هر تیم تنها Route مربوط به سرویس خود را مدیریت می‌کند و اجازه اتصال Route به شنونده، محدود و صریح تعریف می‌شود. قبل از افزودن TLS، مسیریابی یک نام میزبان آزمایشی به یک سرویس ساده را بررسی کنید؛ سپس خطای نام میزبان، سرویس ناموجود و پورت اشتباه را عمداً آزمایش کنید.
یک جدول کوچک از مالکیت بسازید: چه کسی گواهی را عوض می‌کند، چه کسی مقصد مسیر را تغییر می‌دهد و چه کسی می‌تواند Route یک namespace دیگر را متصل کند؟ این جدول برای بازبینی امنیتی از یک نمودار بدون مسئول مشخص مفیدتر است.
خطایی که باید از آن پرهیز کرد
مهاجرت از Ingress را فقط تبدیل شکل YAML نبینید. کنترل مجوز، رفتار timeout، حفظ آدرس کلاینت و تنظیم گواهی را در پیاده‌سازی انتخابی دوباره ارزیابی کنید. پیشنهاد تحریریه این است که در مرحله آزمایشی یک مسیر غیرحساس را منتقل کنید و معیار بازگشت روشن داشته باشید؛ نه اینکه همه ورودی‌های خوشه را هم‌زمان تغییر دهید.
طراحی یک ورودی مشترک برای دو تیم
برای کاربردی شدن مدل، خوشه‌ای با دو تیم سفارش و گزارش را تصور کنید. تیم پلتفرم نشانی بیرونی، شنونده HTTPS و گواهی مشترک را اداره می‌کند. تیم سفارش فقط مسیرهای مربوط به نام میزبان خودش را تعریف می‌کند و تیم گزارش نیز همین اختیار را در محدوده خود دارد. این جداسازی زمانی مفید است که در مجوزهای واقعی API و سیاست اتصال مسیرها منعکس شود. اگر هر توسعه‌دهنده بتواند Gateway یا Secret مشترک را عوض کند، تقسیم مسئولیت روی کاغذ اثری بر دامنه خطا نخواهد داشت.
پیش از ساخت منابع، درباره نام‌گذاری و مالکیت تصمیم بگیرید. نام میزبان هر برنامه، مسیرهای مشترک، درگاه بیرونی و سرویس مقصد باید معلوم باشند. اگر دو تیم هر دو مسیر ریشه یک نام را درخواست کنند، مسئله صرفاً نحوی نیست؛ باید مشخص شود چه کسی مرجع تصمیم است. قواعد تقدم و پشتیبانی پیاده‌سازی را مطالعه کنید، اما از آن‌ها به عنوان جایگزین قرارداد روشن میان تیم‌ها استفاده نکنید. ابهام در مالکیت مسیر ممکن است با یک تغییر کاملاً معتبر به هدایت ترافیک اشتباه منجر شود.
اتصال Route یک توافق دوطرفه است
تعریف ارجاع والد در Route بیان می‌کند برنامه می‌خواهد به کدام Gateway متصل شود. سمت Gateway نیز باید اجازه پذیرش مسیر از آن محدوده را بدهد. این دو جهت را در بررسی خطا جدا کنید. ممکن است Route به والد درست اشاره کند ولی سیاست شنونده اجازه اتصال از namespace آن را ندهد. ممکن است اتصال پذیرفته شود ولی نام میزبان با شنونده سازگار نباشد. نخست وضعیت گزارش‌شده را بخوانید و بعد سراغ آزمایش ترافیک بروید تا تغییرهای تصادفی جای تشخیص را نگیرد.
ارجاع به منبع در namespace دیگر نیز نباید به صورت ضمنی اعتماد ایجاد کند. برای مثال، تیم سفارش نباید صرف دانستن نام سرویس خصوصی تیم گزارش بتواند آن را پشت ورودی عمومی منتشر کند. سازوکارهای مجوز ارجاع میان محدوده‌ها را مطابق API و پیاده‌سازی نصب‌شده بررسی کنید. در آزمایش منفی، یک ارجاع غیرمجاز بسازید و انتظار رد آن را در وضعیت مشاهده کنید. سپس فقط مجوز محدود مورد نیاز را اضافه کنید و تفاوت رفتار را ببینید. این تمرین مرز اعتماد را از توضیح نظری به نتیجه قابل آزمون تبدیل می‌کند.
از نام دامنه تا پاسخ برنامه
برای بررسی مسیر کامل، درخواست باید با همان نام میزبان مورد انتظار وارد شود. اتصال مستقیم به نشانی IP ممکن است هدر میزبان یا نام TLS متفاوتی بسازد و به مسیر پیش‌فرض برسد. در آزمایش، نام دامنه، نام ارائه‌شده در TLS، شنونده انتخاب‌شده و سرویس مقصد را ثبت کنید. اگر گواهی اشتباه دریافت می‌شود، ممکن است مشکل پیش از رسیدن به قواعد HTTP باشد. اگر TLS درست است ولی پاسخ از برنامه دیگری می‌آید، بررسی تطبیق نام و مسیر اولویت بیشتری دارد.
همچنین شماره پورت سرویس Kubernetes با درگاه داخل کانتینر یک مفهوم نیست. Route معمولاً به پورت سرویس اشاره می‌کند و سرویس نگاشت به مقصد را انجام می‌دهد. در یک سناریوی آموزشی، برنامه روی یک درگاه داخلی گوش می‌دهد اما سرویس درگاه متفاوتی ارائه می‌کند. اشتباه گرفتن این دو می‌تواند با وجود Pod سالم به شکست ارتباط منجر شود. از داخل خوشه سرویس را مستقل آزمایش کنید؛ اگر آن مسیر خراب است، تغییر Gateway مشکل برنامه یا Service را برطرف نخواهد کرد.
وضعیت منابع را چگونه تفسیر کنیم؟
شرط‌های وضعیت به ما می‌گویند کنترل‌گر چه چیزی را دیده و درباره آن چه تصمیمی گرفته است. صرف وجود شیء یا قبول شدن فایل کافی نیست. شماره نسل مشاهده‌شده و زمان آخرین تغییر نیز ارزش دارند؛ یک وضعیت قدیمی ممکن است درباره پیکربندی قبلی باشد. در گزارش حادثه، متن دلیل و پیام را همراه با نام کنترل‌گر ثبت کنید. این اطلاعات بهتر از عبارت کلی «Gateway بالا است» مشخص می‌کند کدام بخش پذیرفته شده و کدام ارجاع یا قابلیت مشکل دارد.
از طرف دیگر، وضعیت مطلوب کنترل‌گر جای آزمون کاربر را نمی‌گیرد. مسیر می‌تواند از نظر پیکربندی معتبر باشد ولی شبکه بیرونی، DNS یا خود برنامه مشکل داشته باشد. یک درخواست خواندنی با پاسخ مشخص از بیرون و یک درخواست به سرویس از داخل خوشه دو مشاهده مکمل‌اند. اختلاف این دو دامنه بررسی را کوچک می‌کند. در صورت امکان پاسخ برنامه آزمایشی نام نسخه یا شناسه نمونه را برگرداند تا بدانید ترافیک واقعاً به مقصد مورد انتظار رسیده است، نه اینکه فقط یک پاسخ موفق از پراکسی دریافت کرده‌اید.
قابلیت‌های پیشرفته را با قرارداد پشتیبانی انتخاب کنیم
تقسیم وزن میان مقصدها، تغییر هدر یا بازنویسی مسیر برای مهاجرت مفید است، اما همه پیاده‌سازی‌ها و نسخه‌ها لزوماً مجموعه یکسانی از قابلیت‌ها را ارائه نمی‌کنند. پیش از استفاده، سطح پشتیبانی اعلام‌شده و آزمون‌های سازگاری کنترل‌گر را بررسی کنید. سپس همان قابلیت را در محیط خود آزمایش کنید. معتبر بودن ساختار YAML به معنای اعمال کامل رفتار نیست. اگر قابلیتی ضروری پشتیبانی نمی‌شود، راه‌حل باید انتخاب آگاهانه پیاده‌سازی یا طراحی جایگزین باشد، نه اتکا به رفتار اتفاقی.
برای تقسیم ترافیک، یک درخواست منفرد نمی‌تواند نسبت آماری را اثبات کند. تعداد کافی درخواست مستقل با شناسه مقصد ثبت کنید و اثر اتصال پایدار، نشست و حافظه نهان را در نظر بگیرید. همچنین بررسی کنید مقصد جدید در صورت خطا چگونه از مسیر خارج می‌شود و آیا بازگشت وزن‌ها بدون تغییر نام دامنه ممکن است. این آزمایش با آزمون عملکرد متفاوت است؛ نخست باید درستی هدایت مشخص شود، سپس ظرفیت و تأخیر سنجیده شود. مخلوط کردن این دو هدف تفسیر نتیجه را سخت می‌کند.
مهاجرت از Ingress با حفظ رفتار قابل مشاهده
برای مهاجرت، فهرست مسیرهای موجود و رفتارهای وابسته به annotation را استخراج کنید. بعضی annotationها معادل استاندارد دارند و بعضی وابسته به کنترل‌گر هستند. به ویژه اندازه درخواست، زمان انتظار، انتقال هدرها، تغییر مسیر و ارائه گواهی را جدا بررسی کنید. برنامه‌ای که پشت ورودی قبلی نشانی اصلی کاربر را دریافت می‌کرد ممکن است پس از مهاجرت مقدار متفاوتی ببیند. اگر آن مقدار در ثبت رخداد یا تصمیم امنیتی استفاده می‌شود، تغییر صرفاً ظاهری نیست و باید با مالک برنامه هماهنگ شود.
یک نام آزمایشی یا گروه کوچک درخواست را به مسیر جدید هدایت کنید و هر دو مسیر را با ورودی‌های یکسان مقایسه کنید. فایل بزرگ، مسیر ناموجود، درخواست با هدر خاص و اتصال طولانی نمونه‌های مفیدی هستند. برگشت باید به تغییر مشخص در هدایت ترافیک متکی باشد و تنظیمات قدیمی تا پایان تأیید نگه داشته شوند. پس از موفقیت، مالک هر Route و Gateway را در مستند عملیاتی ثبت کنید. هنگام حادثه، یافتن فردی که اختیار تغییر درست را دارد به اندازه شناخت ساختار API اهمیت دارد.
یک گزارش عیب‌یابی که تیم‌ها بتوانند تحویل بگیرند
گزارش یک خطای مسیر باید دست‌کم نام دامنه، زمان، روش درخواست، مسیر URL، کد پاسخ و مقصد مورد انتظار را داشته باشد. سپس نام Gateway، شنونده و Route مرتبط به آن اضافه شود. بدون این اطلاعات، تیم پلتفرم ممکن است درگاه درست را بررسی کند اما درخواست مورد بحث به نام دیگری رفته باشد. اگر خطا متناوب است، تعداد موفق و ناموفق و تفاوت نمونه‌ها را ثبت کنید. متن کامل داده حساس کاربر برای این کار لازم نیست؛ یک درخواست آزمایشی با همان شکل معمولاً شاهد امن‌تر و قابل تکرارتری می‌سازد.
در تحویل میان تیم‌ها، نتیجه هر مرحله را روشن بنویسید. مثلاً «نام دامنه به نشانی مورد انتظار حل می‌شود، TLS معتبر است، Route پذیرفته شده اما سرویس از داخل خوشه هم پاسخ نمی‌دهد» دامنه مسئولیت را بسیار بهتر از «Gateway خراب است» تعیین می‌کند. اگر سرویس داخلی سالم و مسیر بیرونی خراب است، تمرکز به ورودی و شبکه منتقل می‌شود. این شیوه گزارش باعث می‌شود هر تیم مجبور نباشد بررسی را از صفر تکرار کند و تغییرهای هم‌زمان نیز کمتر شوند.
برای نگه‌داری بلندمدت، آزمون مسیرهای مهم را به تغییر کنترل‌گر گره بزنید. یک ارتقا ممکن است رفتار قابلیت توسعه‌یافته یا تفسیر تنظیمات قدیمی را تغییر دهد. مجموعه کوچکی از درخواست‌های نماینده که خروجی مورد انتظار دارند، از مرور دستی ده‌ها فایل مؤثرتر است. این مجموعه باید شامل مسیر سالم، نام میزبان نامعتبر و مقصد غیرمجاز باشد تا هم عملکرد و هم مرز دسترسی بررسی شوند. هدف، ثبت قرارداد قابل مشاهده میان تیم برنامه و تیم پلتفرم است.
