یک سرویس پردازش تصویر را در نظر بگیرید که صبح‌ها ناگهان پرکار می‌شود و شب‌ها گاهی ساعت‌ها درخواستی ندارد. اجرای چند نمونه دائمی می‌تواند هزینه منابع را بالا ببرد، اما صفر کردن نمونه‌ها نیز زمان انتظار اولین مشتری را تغییر می‌دهد. Knative Serving میان درخواست ورودی، وضعیت یک نسخه از برنامه و تعداد نمونه‌های قابل خدمت ارتباط برقرار می‌کند. برای فهم این رفتار باید مسیر درخواست را همراه با تصمیم‌های کنترلر و مقیاس‌دهنده دنبال کرد. تعداد پادها به تنهایی توضیح نمی‌دهد چرا مشتری پاسخ گرفت، به صف رفت یا با پایان مهلت مواجه شد.
تعریف برنامه و وضعیت مشاهده‌شده
کار تیم با توصیف وضعیت دلخواه آغاز می‌شود. یک Knative Service تعریف سطح بالایی برای انتشار برنامه است و در جریان کار با اشیایی مانند Configuration، Revision و Route ارتباط دارد. Revision نماینده یک نسخه معین از پیکربندی اجرایی است و Route مشخص می‌کند ترافیک به کدام نسخه برسد. اگر ارسال بخشی از ترافیک به نسخه قبلی هنوز ادامه داشته باشد، تعداد پادهای نسخه تازه تمام داستان نیست. در بررسی خطا باید ابتدا نام نسخه‌ای را که درخواست مورد بررسی باید دریافت کند مشخص کرد.
کنترلر وضعیت منابع Knative را در خوشه مشاهده می‌کند، منابع وابسته را با وضعیت دلخواه هماهنگ می‌سازد و نتیجه را در وضعیت شیء ثبت می‌کند. این فرایند همگام و آنی نیست. پذیرفته‌شدن تعریف سرویس توسط API به معنی آماده‌شدن برنامه برای پاسخ نیست. فرض کنید رجیستری تصویر در دسترس نباشد. منبع ممکن است وجود داشته باشد و کنترلر نیز کار کند، اما نمونه‌ای که تصویر را دریافت نکرده قادر به خدمت نیست. برای تشخیص، رویدادها و شرایط آمادگی را کنار وضعیت پاد قرار دهید و از خروجی موفق ثبت پیکربندی به تنهایی نتیجه نگیرید.
ورودی شبکه و تشخیص مقصد
در مستند معماری Serving، واژه ingress مفهوم ورود ترافیک را بیان می‌کند. آن را با شیء Kubernetes Ingress یکسان نگیرید. Knative یک منبع داخلی به نام KIngress دارد که میان Serving و پیاده‌سازی شبکه واسطه است. کنترلر لایه شبکه این منبع را مشاهده می‌کند و دروازه را مطابق آن تنظیم می‌کند. برحسب انتخاب نصب، جزئیات لایه شبکه متفاوت است. هنگام عیب‌یابی باید نام پیاده‌سازی واقعی، وضعیت دروازه و نحوه انتشار آن در همین خوشه ثبت شود، زیرا دو محیط با برنامه یکسان می‌توانند مسیر شبکه متفاوتی داشته باشند.
برای رسیدن درخواست بیرونی، مشتری باید نام دامنه درست را به مقصد درست تبدیل کند و دروازه بتواند میزبان درخواست را به مسیر تعریف‌شده نگاشت کند. اگر نشانی دروازه تغییر کرده اما DNS هنوز به مقدار قدیمی اشاره دارد، مشاهده پاد سالم مسئله را حل نمی‌کند. همچنین یک آزمون مستقیم با نشانی دروازه که نام میزبان درست را ارسال نکرده، آزمون کامل مسیر عادی نیست. پاسخ پیش‌فرض دروازه ممکن است دقیقاً به خاطر نبودن تطابق نام ایجاد شده باشد. آزمایش باید تا حد ممکن مسیر و مشخصات درخواست مشتری واقعی را بازسازی کند.
اولین درخواست در حالت صفر
وقتی یک نسخه به صفر نمونه رسیده، پادی برای دریافت مستقیم درخواست وجود ندارد. Activator می‌تواند درخواست را موقتاً نگه دارد و با Autoscaler در ارتباط باشد تا ظرفیت مورد نیاز ایجاد شود. پس از آنکه یک پاد آماده شد، درخواست به آن فرستاده می‌شود. Activator بخشی از مسیر داده است. Controller مسئول مدیریت وضعیت منابع است و Autoscaler تصمیم درباره ظرفیت را بر اساس پیکربندی و اندازه‌گیری‌ها می‌گیرد. یکی دانستن این سه نقش معمولاً به جست‌وجوی گزارش خطا در محل اشتباه منجر می‌شود.
تأخیر اولین پاسخ فقط زمان آغاز فرایند داخل کانتینر نیست. امکان دارد زمان‌بند منتظر ظرفیت گره بماند، دریافت تصویر طول بکشد، برنامه در زمان شروع اتصال‌های لازم را برقرار کند یا بررسی آمادگی دیر موفق شود. برای مشتری مجموع این زمان‌ها اهمیت دارد. اگر مهلت درخواست از این مجموع کمتر باشد، مشتری ممکن است خطا ببیند و کمی بعد همان نسخه آماده شود. مشاهده پاد سالم چند دقیقه پس از رخداد با گزارش خطای مشتری تناقضی ندارد. زمان ورود، زمان ایجاد پاد، زمان آماده‌شدن و زمان پاسخ را در یک خط زمانی کنار هم بگذارید.
مسیر گرم و نقش Queue-Proxy
وقتی ظرفیت آماده است، لایه شبکه بنا بر وضعیت و پیکربندی می‌تواند ترافیک را مستقیم به پاد یا از مسیر Activator عبور دهد. بنابراین وجود یا نبود یک جزء در مسیر یک درخواست مشخص باید از داده همان محیط استنباط شود. در کنار کانتینر برنامه، Queue-Proxy قرار دارد. این جزء سنجه‌ها را گردآوری می‌کند، درخواست را به برنامه می‌رساند و در اجرای محدودیت هم‌زمانی نقش دارد. اگر درخواستی در این مرحله منتظر بماند، فقط بررسی زمان اجرای تابع در برنامه بخشی از تأخیر را پنهان می‌کند.
فرض کنید یک پاد به دلیل محدودیت اتصال پایگاه داده عملاً فقط چند عملیات سنگین را هم‌زمان به پایان می‌رساند. بالا بردن عدد هم‌زمانی ظاهراً ظرفیت بیشتری اعلام می‌کند، اما ممکن است فقط انتظار را از صف جلوی کانتینر به صف اتصال داخل برنامه منتقل کند. برای انتخاب تنظیم، زمان انتظار، مصرف پردازنده، تعداد عملیات فعال و ظرفیت وابستگی را هم‌زمان بسنجید. اگر گلوگاه در سرویس بیرونی است، افزودن پاد ممکن است درخواست بیشتری به همان وابستگی محدود بفرستد و وضعیت بدتر شود.
مقیاس‌دهی و مرز ظرفیت
Knative Pod Autoscaler سازوکار پیش‌فرض Serving برای تطبیق تعداد نمونه‌ها با تقاضاست. اگر قابلیت رسیدن به صفر فعال باشد، نبود ترافیک می‌تواند در نهایت به صفر نمونه منتهی شود. این رفتار را برای همه نصب‌ها فرض نکنید. تنظیمات خوشه، کلاس مقیاس‌دهنده و حداقل و حداکثر تعیین‌شده برای نسخه باید با مستندات و وضعیت واقعی مقایسه شوند. HPA نیز با نصب و تنظیم مناسب گزینه دیگری است، اما قابلیت‌ها و معیارهای آن را نباید از روی رفتار KPA حدس زد.
هدف هم‌زمانی در تصمیم مقیاس‌دهی و سقف اجرایی درخواست‌ها دو سؤال جدا هستند. هدف می‌گوید چه بار متوسطی برای هر نمونه مناسب تلقی می‌شود. سقف مشخص می‌کند چند درخواست می‌توانند هم‌زمان وارد کانتینر شوند. برای مثال، اگر برنامه هنگام پردازش تصویر بزرگ حافظه زیادی مصرف می‌کند، پذیرش تعداد بالای عملیات هم‌زمان می‌تواند پاد را دچار فشار حافظه کند. پایین بردن سقف هم اگر با ظرفیت کافی و زمان آغاز مناسب همراه نباشد، انتظار بیشتری تولید می‌کند. تنظیم موفق باید با داده واقعی همان نوع درخواست سنجیده شود.
حداقل نمونه برای مسیرهایی مفید است که هزینه انتظار اولین مشتری از هزینه ظرفیت بیکار بیشتر است. حداکثر نمونه نیز می‌تواند از مصرف بی‌حد منبع یا فشار ناگهانی بر سامانه پایین‌دست جلوگیری کند. با این حال رسیدن به سقف به معنای تضمین پاسخ موفق نیست. اگر ورودی از ظرفیت پردازش بیشتر باشد، درخواست‌ها صف می‌شوند یا به مهلت می‌رسند. در طراحی باید مشخص شود در حالت اشباع، مشتری چه پاسخی می‌گیرد، کدام عملیات قابل تکرار است و چه کسی حق دارد ظرفیت یا سهمیه وابستگی را تغییر دهد.
آزمایش عملی بدون مخلوط کردن علت‌ها
برای ارزیابی، ابتدا یک نسخه و یک مسیر مشخص انتخاب کنید و نمونه درخواست‌ها را بر اساس هزینه پردازش جدا کنید. درخواست کوچک و تصویر بزرگ در یک میانگین واحد می‌توانند اثر یکدیگر را پنهان کنند. آزمایش اول را پس از دوره بیکاری کافی انجام دهید و وضعیت واقعی صفر بودن نمونه‌ها را قبل از ارسال ثبت کنید. مدت پاسخ، زمان آمادگی و خطای احتمالی را ذخیره کنید. سپس همان درخواست را وقتی نمونه آماده است تکرار کنید. اختلاف دو نتیجه سرنخ هزینه آغاز است، اما باید تغییرات شبکه و وابستگی‌ها را نیز کنترل کرد.
در آزمایش دوم بار را مرحله‌به‌مرحله بالا ببرید، نه اینکه از ابتدا بیشترین حجم ممکن را ارسال کنید. در هر مرحله تعداد نمونه آماده، زمان انتظار در پاد، زمان برنامه و نرخ خطا را ثبت کنید. اگر افزایش ظرفیت دیرتر از رشد صف رخ می‌دهد، معلوم کنید آیا تصمیم مقیاس‌دهنده دیر صادر شده یا پاد پس از تصمیم دیر آماده شده است. در حالت اول معیار و پنجره مشاهده اهمیت دارند. در حالت دوم باید زمان‌بندی، منابع گره، تصویر و آغاز برنامه بررسی شوند. تغییر همه تنظیمات به صورت هم‌زمان تشخیص علت را تقریباً ناممکن می‌کند.
انتشار نسخه تازه و اندازه‌گیری اثر آن
در انتشار تدریجی، درصد کوچکی از ترافیک می‌تواند به نسخه جدید برسد. این سهم کوچک لزوماً به معنای بار نماینده نیست. ممکن است درخواست‌های حجیم به طور اتفاقی کمتر به نسخه جدید رسیده باشند یا نخستین نمونه بیشتر زمان خود را در حالت آغاز گذرانده باشد. مقایسه باید با توجه به نوع درخواست، تعداد مشاهده و وضعیت گرم یا سرد انجام شود. افزایش سهم ترافیک زمانی منطقی است که شاخص‌های همان گروه درخواست با نسخه قبلی قابل مقایسه باشد و وابستگی مشترک دچار فشار نشده باشد.
اگر بازگرداندن ترافیک به نسخه قبلی لازم شد، سلامت آن نسخه را دوباره بسنجید. نسخه پیشین ممکن است به صفر رسیده یا به پیکربندی و پایگاه داده‌ای وابسته باشد که در فاصله انتشار تغییر کرده است. تغییر Route فقط مقصد را تغییر می‌دهد و ناسازگاری داده را برطرف نمی‌کند. تیمی که از مهاجرت طرح پایگاه داده استفاده می‌کند باید سازگاری هر دو نسخه در بازه بازگشت را پیش از انتشار بررسی کند. اجرای موفق یک درخواست ساده نیز برای اثبات سلامت همه عملیات کافی نیست.
تشخیص خطا از بیرون به داخل
در خطای نام دامنه ابتدا پاسخ DNS و نشانی واقعی دروازه بررسی می‌شود. اگر دروازه پاسخ می‌دهد اما مسیر یافت نمی‌شود، نام میزبان، وضعیت Route و گزارش کنترلر شبکه را مقایسه کنید. اگر مسیر پیدا می‌شود اما نخستین درخواست مهلت خود را از دست می‌دهد، وضعیت Activator و رویدادهای ایجاد و آمادگی پاد اهمیت بیشتری دارند. اگر فقط زیر بار سنگین تأخیر بالا می‌رود، صف، محدودیت هم‌زمانی، سقف نمونه‌ها و اتصال به وابستگی‌ها را کنار هم ببینید. این ترتیب از مشاهده نتیجه به لایه محتمل می‌رسد و جای آزمایش کنترل‌شده را نمی‌گیرد.
در یک گزارش خوب، عبارت «Knative کند است» جای خود را به شرح قابل بررسی می‌دهد. برای مثال می‌توان نوشت درخواست به دروازه رسید، نسخه مورد نظر پاد آماده نداشت، پاد بعد از مهلت مشتری آماده شد و درخواست بعدی با همان ورودی سریع پاسخ گرفت. چنین گزارشی به تیم اجازه می‌دهد درباره گرم نگه داشتن نمونه، کوچک کردن تصویر، بهبود آغاز برنامه یا تنظیم مهلت تصمیم بگیرد. انتخاب به هزینه واقعی، حجم بار، اهمیت تأخیر و ظرفیت وابستگی بستگی دارد. معماری Serving زمانی برای عملیات ارزشمند می‌شود که این تصمیم‌ها با شواهد مسیر یک درخواست مشخص ارتباط پیدا کنند.
