تیم پلتفرم دامنه فروشگاه را اداره می‌کند. تیم سفارش مالک مسیر سفارش‌هاست و تیم محتوا بخش راهنما را تغییر می‌دهد. اگر همه مسیرها در یک فایل مرکزی نگه‌داری شوند، هر انتشار کوچک به تغییر همان فایل و هماهنگی چند تیم نیاز دارد. اگر هر تیم بتواند برای کل دامنه تعریف مستقل بسازد، تعارض مالکیت و مسیرهای مبهم به وجود می‌آید. Contour با منبع HTTPProxy اجازه می‌دهد مالک دامنه بخشی از مسیر را به تعریف دیگری واگذار کند. برای طراحی درست این الگو باید رابطه میان root، منبع فرزند، شرایط مسیر و سرویس پشت آن روشن باشد.
Contour تنظیمات را می‌خواند، Envoy درخواست را عبور می‌دهد
Contour منابع مرتبط در Kubernetes را مشاهده می‌کند و تنظیمات مسیریابی را برای Envoy آماده می‌سازد. Envoy در مسیر ترافیک قرار دارد و درخواست واقعی کاربر را دریافت می‌کند. در نتیجه موضوعی مانند خطا در تعریف HTTPProxy ابتدا در وضعیت منبع و تصمیم Contour دیده می‌شود، در حالی که تأخیر به دلیل کندی برنامه ممکن است پس از پذیرش مسیر توسط Envoy رخ دهد. برای هر رخداد باید معلوم شود درخواست به کدام Envoy رسیده، کدام virtual host و route انتخاب شده و آیا مقصد آماده‌ای برای ارسال وجود داشته است. بررسی صرف سلامت پردازش کنترل‌گر پاسخ این پرسش‌ها را نمی‌دهد.
یک نمونه ممکن است از بیرون با نام دامنه و TLS وارد شود و از درون به Kubernetes Service برسد. DNS، دسترسی شبکه تا Envoy، انتخاب گواهی، تطبیق نام میزبان، شرایط مسیر، سرویس و endpointها حلقه‌های این زنجیره‌اند. اگر مرورگر حتی گواهی درست را نمی‌بیند، بررسی readiness برنامه سفارش معمولاً نخستین اقدام مفید نیست. اگر TLS برقرار است و مسیر مشخص به خطای مقصد می‌رسد، بررسی تعریف سرویس و Podهای آماده اهمیت بیشتری دارد. ثبت نام میزبان و مسیر کامل درخواست برای تمایز این مراحل ضروری است، زیرا دو URL روی یک IP ممکن است به virtual hostهای متفاوت برسند.
Root HTTPProxy مالک نام دامنه است
منبع ریشه virtualhost تعریف می‌کند و نام دامنه را در اختیار دارد. همان منبع می‌تواند مسیرهای مستقیمی به سرویس‌ها بسازد و بخش‌هایی را با includes به HTTPProxyهای دیگر بسپارد. در طراحی چندتیمی، تیم پلتفرم می‌تواند مالک تعریف ریشه و شرایط کلی دامنه بماند و هر تیم فرزند خود را در namespace مربوط ویرایش کند. این تقسیم مالکیت باید با RBAC واقعی هماهنگ باشد. صرف نوشتن نام تیم در مستندات از ویرایش ریشه توسط حسابی با مجوز گسترده جلوگیری نمی‌کند. اختیارات نوشتن و اختیار انتشار دامنه باید با همان مرز سازمانی تطبیق پیدا کنند.
تنظیمات Contour می‌تواند محل مجاز ایجاد rootها را محدود کند. این موضوع برای خوشه‌ای که namespaceهای بسیاری دارد اهمیت دارد. اگر هر namespace امکان ساخت ریشه برای دامنه عمومی را داشته باشد، تیم پلتفرم باید درباره تعارض دامنه‌ها و مالکیت گواهی تصمیم بگیرد. محدود بودن محل root و واگذاری مسیرهای لازم دامنه می‌تواند کنترل مشخص‌تری ایجاد کند. با این حال فرزند نیز همچنان قابلیت تغییر رفتار بخشی از ترافیک را دارد. دسترسی تیم به آن باید متناسب با همان بخش باشد و تغییرها تاریخچه و مسیر بازبینی داشته باشند.
Include شرایط والد و فرزند را ترکیب می‌کند
فرض کنید ریشه شرط مسیر سفارش‌ها را برای یک include تعریف کرده است. فرزند می‌تواند در محدوده حاصل، مسیرهای دقیق‌تری برای فهرست و جزئیات سفارش بسازد. شرایط والد بخشی از قرارداد نهایی هستند و باید هنگام بررسی مسیر فرزند حفظ شوند. مستندات Contour برای prefix نمونه‌هایی ارائه می‌کنند که در آن بخش‌های مسیر میان والد و فرزند ترکیب می‌شوند. بررسی فقط YAML فرزند ممکن است خواننده را به URL نهایی اشتباه برساند. در پرونده تغییر باید هم مسیر واگذارشده والد و هم شرط محلی فرزند نوشته شود تا تیم تست بداند کدام URL واقعاً باید پاسخ دهد.
نام فرزند و namespace آن در include اهمیت دارد. اگر مقصد در namespace دیگری باشد، باید همان namespace در ارجاع مشخص شود و کنترل‌گر نیز منابع آن را مشاهده کند. هنگام محدودکردن حوزه watch کنترل‌گر، فراموش کردن namespace فرزند می‌تواند زنجیره‌ای را که روی کاغذ درست است در اجرا ناقص کند. آزمون پذیرش باید از دامنه واقعی و مسیر نهایی انجام شود. اتصال مستقیم به سرویس فرزند فقط سلامت برنامه را نشان می‌دهد و ترکیب شرایط مسیر یا واگذاری بین namespaceها را آزمایش نمی‌کند. این تفاوت در زمان مهاجرت از تعریف مرکزی به ساختار واگذارشده اهمیت ویژه دارد.
فرزند یتیم و چرخه در ارجاع‌ها
یک HTTPProxy فرزند که هیچ ریشه یا والد معتبری به آن نرسد، در ساخت مسیر مؤثر ورودی نقش ندارد. چنین منبعی ممکن است در API Kubernetes وجود داشته باشد، اما کاربر از بیرون راهی به آن پیدا نکند. این وضعیت هنگام انتشار دومرحله‌ای طبیعی است، مثلاً تیم ابتدا فرزند را می‌سازد و سپس مالک دامنه include را اضافه می‌کند. با این حال اگر واگذاری فراموش شود، انتشار برنامه از دید تیم محلی موفق و از دید مشتری نامرئی خواهد بود. وضعیت منابع و مسیر ارجاع از ریشه باید بخشی از معیار پایان انتشار باشند.
ارجاع حلقوی میان والد و فرزند یا شرایط ناسازگار می‌تواند تعریف را نامعتبر کند. Contour وضعیت HTTPProxy را با اطلاعاتی درباره اعتبار و علت مشکل گزارش می‌دهد. خواندن شرح وضعیت معمولاً سریع‌تر از جست‌وجوی خطا در همه Podهای برنامه است. اگر ریشه به فرزندی اشاره کند که وجود ندارد، رفتار درخواست می‌تواند با ارجاع به سرویسی که وجود ندارد فرق داشته باشد. کد پاسخ به تنهایی برای ریشه‌یابی کافی نیست. نام منبع، شرح وضعیت و ساختار include را کنار پاسخ واقعی Envoy ثبت کنید. پس از اصلاح، هم معتبر شدن وضعیت و هم موفقیت درخواست واقعی را بررسی کنید.
مسیر، پورت سرویس و مقصد آماده
در تعریف route، نام سرویس و پورت باید با Service واقعی سازگار باشد. شماره پورت برنامه داخل کانتینر، targetPort سرویس و port سرویس نقش‌های جداگانه دارند. Contour باید به پورتی ارجاع دهد که سرویس معرفی می‌کند و خود سرویس باید به endpoint درست برسد. اگر سرویس وجود دارد ولی selector هیچ Pod آماده‌ای پیدا نمی‌کند، مسیر از نظر نام و پورت ممکن است منطقی باشد اما درخواست همچنان مقصد قابل استفاده ندارد. برای تشخیص، Service و EndpointSliceهای مربوط و وضعیت readiness برنامه را با هم بررسی کنید. وجود شیء سرویس در فهرست Kubernetes برای اثبات آمادگی کافی نیست.
در مهاجرت تدریجی، route می‌تواند برای مقصدها وزن تعیین کند. وزن نشان‌دهنده سهم نسبی مسیریابی است و نتیجه نمونه کوچک درخواست‌ها الزاماً دقیقاً برابر نسبت تنظیم‌شده نخواهد بود. برای ارزیابی باید تعداد کافی درخواست، رفتار اتصال‌های ماندگار و ویژگی‌های پروتکل را لحاظ کرد. همچنین هر دو نسخه باید روی مسیر و قرارداد پاسخ سازگار باشند. اگر نسخه تازه روی یک زیرمسیر خاص شکست بخورد، میانگین موفقیت کل دامنه ممکن است مسئله را پنهان کند. اندازه‌گیری به تفکیک route و نسخه مقصد، تصمیم درباره ادامه انتشار را دقیق‌تر می‌کند.
TLS و واگذاری مسیر دو اختیار متفاوت‌اند
مالک دامنه مسئول گواهی و سیاست TLS آن است. فرزندی که فقط بخشی از مسیر را اداره می‌کند لزوماً نباید کلید خصوصی دامنه را بخواند. این تفکیک به تیم محتوا اجازه می‌دهد مسیر وبلاگ را تغییر دهد، در حالی که عملیات گواهی در اختیار تیم پلتفرم می‌ماند. اگر گواهی در namespace دیگری نگه‌داری شود، قواعد مربوط به ارجاع و واگذاری TLS باید جداگانه طبق مستندات بررسی شوند. واگذاری مسیر HTTPProxy به خودی خود همه مجوزهای استفاده از Secret را ایجاد نمی‌کند. محل Secret، مجوز کنترل‌گر و سیاست مالک دامنه هر سه در طراحی اثر دارند.
برای آزمون TLS، نام میزبان واقعی و SNI مورد انتظار را به کار ببرید. درخواست به IP خام ممکن است virtual host یا گواهی پیش‌فرض متفاوتی انتخاب کند و نتیجه‌ای گمراه‌کننده بسازد. پس از تأیید گواهی، مسیر واگذارشده و یک مسیر بیرون از محدوده فرزند را امتحان کنید. آزمون دوم مشخص می‌کند تغییر تیم فرزند مسیر دیگری از دامنه را ناخواسته تصاحب نکرده است. هنگام تمدید گواهی نیز باید از سمت کاربر اعتبار گواهی ارائه‌شده بررسی شود. به‌روزرسانی موفق Secret به تنهایی نشان نمی‌دهد همه نمونه‌های Envoy نسخه مورد انتظار را ارائه می‌کنند.
پرونده انتشار تیم محتوا
تیم محتوا می‌خواهد قسمت راهنما را به سرویس تازه منتقل کند. ابتدا فرزند و سرویس در namespace مربوط ساخته می‌شوند و وضعیت سرویس و endpointها بررسی می‌شود. سپس ریشه include را در محدوده مشخص اضافه می‌کند. درخواست‌های آزمون باید صفحه اصلی راهنما، یک زیرمسیر، یک مسیر خارج از واگذاری و رفتار نام میزبان اشتباه را پوشش دهند. نتیجه برای هر مسیر با مقصد مورد انتظار مقایسه می‌شود. اگر فقط مسیر اصلی بررسی شود، ترکیب prefix در زیرمسیرها یا تقدم شرایط ممکن است تا زمان مراجعه کاربر واقعی آشکار نشود.
برای بازگشت، مشخص کنید تغییر در فرزند کافی است یا ریشه باید به مسیر قبلی برگردد. حذف فرزند پیش از حذف ارجاع ریشه می‌تواند مشتری را به مسیر ناقص هدایت کند. ترتیب تغییرها باید با وضعیت سرویس قبلی و زمان مشاهده پیکربندی در Envoy هماهنگ باشد. پس از پایان انتشار، شناسه نسخه ریشه و فرزند، نتیجه اعتبارسنجی و چند نمونه درخواست را کنار هم نگه دارید. این ثبت به دو تیم اجازه می‌دهد وقتی فقط یک زیرمسیر خطا می‌دهد، مالک تغییر و لایه درگیر را با شواهد مشخص پیدا کنند و کاربر را دوباره به مسیر سالم برگردانند.
برای بازبینی پرونده، یک درخواست نمونه را از بیرون و سپس از داخل خوشه پیگیری کنید. در یک محیط آزمایشی، نام میزبان فروشگاه را با نشانی Envoy تطبیق دهید و مسیر راهنما را فراخوانی کنید. زمان و شناسه درخواست را ثبت کنید تا همان نمونه در گزارش پراکسی و برنامه پیدا شود. سپس از داخل namespace، سرویس محتوا را با مسیر مورد انتظار برنامه بخوانید. ممکن است در تعریف route بازنویسی مسیر انجام شده باشد و برنامه مسیری متفاوت از آنچه مشتری فرستاده ببیند. مقایسه این دو درخواست نشان می‌دهد خطا در تطبیق مسیر عمومی رخ داده یا در تفسیر مسیر توسط برنامه. پس از اصلاح، یک درخواست با نام میزبان دیگر نیز اجرا کنید تا معلوم شود تغییر فقط بر دامنه صاحب ریشه اثر گذاشته است.
