دو بخش متفاوت در یک مش
در معماری Sidecar، مسیر داده از پراکسی‌هایی تشکیل می‌شود که همراه بارهای کاری قرار می‌گیرند. این پراکسی‌ها ترافیک را طبق تنظیمات دریافتی پردازش می‌کنند. istiod در بخش کنترلی، مسئولیت‌هایی مانند کشف سرویس، توزیع تنظیمات و پشتیبانی از هویت را بر عهده دارد.
پس هر درخواست کاربردی قرار نیست برای عبور خود از istiod پاسخ بگیرد. در مقابل، تغییر سیاست و دریافت تنظیمات تازه به سلامت مسیر کنترلی وابسته است. این تمایز هنگام تحلیل رخداد اهمیت زیادی دارد: خطای کنترل‌پلین و قطع کامل ترافیک همیشه یک رویداد واحد نیستند.
این مقاله درباره کدام حالت است؟
نمودار منبع، معماری مبتنی بر پراکسی‌های Envoy و کنترل‌پلین را توضیح می‌دهد. این مرور روی حالت Sidecar تمرکز دارد؛ اجزای حالت Ambient و مرز نقش ztunnel یا waypoint را نباید بدون بررسی مستندات به همین تصویر تحمیل کرد.
تمرین پیشنهادی برای تشخیص خطا
برای دو سرویس آزمایشی، ابتدا ارتباط ساده را بدون سیاست پیچیده برقرار کنید. سپس صحت عضویت بار کاری در مش، وضعیت پراکسی و نسخه تنظیمات دریافت‌شده را ثبت کنید. یک اشتباه در انتخاب مقصد مسیر را از خطای گواهی یا ردشدن مجوز جدا آزمایش کنید؛ هرکدام باید نشانه قابل‌تشخیصی در گزارش شما داشته باشد.
قبل از فعال‌کردن retry، درباره اثر تکرار درخواست سؤال کنید. در یک مثال فرضی سفارش‌گذاری، تکرار بی‌حساب درخواست غیرقابل‌تکرار می‌تواند از یک خطای موقتی، عملیات تکراری بسازد. بودجه زمان پاسخ، تعداد تلاش‌ها و قرارداد idempotency را با تیم برنامه هماهنگ کنید.
هزینه عملیاتی را حساب کنید
پیشنهاد تحریریه این است که پیچیدگی مش را با مسئله واقعی توجیه کنید: هویت مشترک سرویس‌ها، کنترل ترافیک یا مشاهده‌پذیری منسجم. برای استقرار آزمایشی، مصرف منابع پراکسی، زمان انتشار تنظیمات و رفتار هنگام ارتقا را اندازه بگیرید. نصب موفق کنترل‌پلین فقط شروع بهره‌برداری است.
مسیر یک درخواست میان دو خدمت
دو خدمت سفارش و موجودی را در یک محیط آزمایشی در نظر بگیرید. برنامه سفارش یک درخواست شبکه به نام خدمت موجودی می‌فرستد. در مدل Sidecar، ترافیک مطابق تنظیمات محیط از پراکسی محلی عبور می‌کند. پراکسی با اطلاعاتی که از مسیر کنترل گرفته، مقصد مناسب، سیاست اتصال و قواعد مسیریابی را تعیین می‌کند. در سمت مقصد نیز پراکسی می‌تواند اتصال را دریافت و سپس درخواست را به برنامه تحویل دهد. برنامه الزاماً از همه این جزئیات آگاه نیست، اما همچنان مسئول منطق تجاری، اعتبارسنجی ورودی و مدیریت خطای کاربردی خود است.
این مسیر چند محل متفاوت برای شکست ایجاد می‌کند. نام خدمت ممکن است درست حل نشود؛ مقصدی برای خدمت وجود نداشته باشد؛ سیاست امنیتی ارتباط را رد کند؛ پراکسی نتواند اتصال برقرار کند؛ یا خود برنامه پاسخ خطا بدهد. مشاهده یک کد خطا بدون تعیین تولیدکننده آن کافی نیست. گزارش دسترسی پراکسی، وضعیت نقاط پایانی و گزارش برنامه را با شناسه درخواست کنار هم بگذارید. اگر درخواست اصلاً به برنامه نرسیده، بررسی منطق تجاری اولویت نخست نیست. اگر برنامه درخواست را دریافت و خطا تولید کرده، تغییر تنظیم مسیریابی احتمالاً علت را برطرف نمی‌کند.
چرا مسیر کنترل در هر درخواست حضور ندارد؟
وظیفه مسیر کنترل، تبدیل قصد و وضعیت کشف‌شده به تنظیم قابل استفاده پراکسی‌هاست. این مؤلفه قرار نیست محتوای همه درخواست‌های کاربردی را از خودش عبور دهد. به همین دلیل اختلال در مسیر کنترل و اختلال در مسیر داده اثر یکسانی ندارند. پراکسی موجود ممکن است با آخرین تنظیم دریافتی به کار ادامه دهد، در حالی که تغییر تازه یا راه‌اندازی نمونه جدید مشکل پیدا کند. نتیجه دقیق به نوع اختلال و وضعیت مؤلفه‌ها وابسته است؛ از این ویژگی تضمین دسترس‌پذیری نامحدود نسازید.
در یک تمرین غیرتولیدی، ابتدا ارتباط سالم را ثبت کنید. سپس تغییر کوچکی در سیاست ایجاد کنید و زمان دیده شدن آن در پراکسی را اندازه بگیرید. بعد مسیر دریافت تنظیم را به صورت کنترل‌شده مختل کنید و تفاوت ارتباط موجود با نمونه تازه راه‌اندازی‌شده را مشاهده کنید. این آزمایش نشان می‌دهد چرا پایش فقط موفقیت درخواست‌های فعلی کافی نیست. سلامت انتشار تنظیم، تازگی پیکربندی و آمادگی نمونه‌های تازه نیز باید دیده شوند. تیم باید بداند کدام هشدار از خطر آینده خبر می‌دهد حتی اگر کاربران فعلاً پاسخ می‌گیرند.
تزریق پراکسی را قابل مشاهده کنید
وجود برچسب مناسب روی فضای نام به تنهایی اثبات نمی‌کند همه پادهای موجود پراکسی دارند. تزریق معمولاً هنگام ایجاد پاد انجام می‌شود و تغییر سیاست فضای نام الزاماً پادهای قبلی را بازسازی نمی‌کند. فهرست ظرف‌های پاد و زمان ایجاد آن را بررسی کنید. در یک خدمت با چند نمونه، وجود ترکیبی از نمونه‌های دارای پراکسی و فاقد پراکسی می‌تواند نتیجه آزمون را متغیر کند. قبل از تحلیل پیچیده، یکسان بودن وضعیت استقرار نمونه‌ها را مشخص کنید.
ترتیب آماده شدن برنامه و پراکسی نیز اهمیت دارد. اگر برنامه بلافاصله پس از شروع به یک وابستگی وصل می‌شود، رفتار آن پیش از آماده شدن مسیر شبکه باید آزموده شود. هنگام خاتمه نیز ممکن است برنامه هنوز درخواست جاری داشته باشد ولی پراکسی یا مسیر مقصد در حال بسته شدن باشد. آزمایش راه‌اندازی و توقف را در کنار حالت پایدار انجام دهید. بیشتر سامانه‌ها در ساعت‌های عادی سالم‌اند؛ اختلال‌های کوتاه هنگام انتشار نسخه همان جایی هستند که طراحی چرخه عمر خود را نشان می‌دهد.
هویت ارتباط با مجوز درخواست فرق دارد
رمزنگاری متقابل می‌تواند هویت طرفین و حفاظت ارتباط را فراهم کند، اما به تنهایی نمی‌گوید یک خدمت اجازه انجام هر عملی را دارد. خدمت سفارش ممکن است مجاز به خواندن موجودی باشد ولی نباید عملیات مدیریتی انبار را انجام دهد. سیاست مجوز باید این تفاوت را بیان کند و در صورت نیاز، کنترل کاربردی نیز آن را تکمیل کند. هویت سرویس را با هویت کاربر نهایی یکسان نگیرید؛ یک درخواست ممکن است از خدمت معتبر برسد اما نماینده کاربری فاقد مجوز باشد.
برای آزمون، یک مسیر مجاز و یک مسیر غیرمجاز تعریف کنید. از همان مبدأ معتبر هر دو را درخواست کنید و انتظار متفاوت داشته باشید. سپس از مبدأ دیگر مسیر مجاز قبلی را امتحان کنید تا محدودیت هویت نیز دیده شود. خطاهای مجوز باید در گزارش قابل تشخیص باشند، اما داده حساس درخواست نباید بی‌دلیل ثبت شود. اگر سیاست از اطلاعاتی مانند سربرگ استفاده می‌کند، روشن کنید آن سربرگ را چه کسی می‌سازد و آیا فرستنده می‌تواند مقدار آن را جعل کند. اعتماد به داده ورودی بدون مرز روشن، سیاست ظاهراً دقیق را بی‌اثر می‌کند.
تکرار درخواست می‌تواند خرابی را تشدید کند
تنظیم تلاش مجدد برای خطای گذرا مفید است، ولی هر درخواست قابل تکرار نیست. اگر عملیات پرداخت انجام شده اما پاسخ گم شده باشد، تکرار بی‌قید می‌تواند اثر دوم ایجاد کند. علاوه بر آن، وقتی خدمت مقصد تحت فشار است، تلاش مجدد همزمان از چند لایه بار را بیشتر می‌کند. برنامه، کتابخانه مشتری و پراکسی ممکن است هرکدام جداگانه تکرار کنند. بودجه زمانی کلی و تعداد تلاش‌ها را برای کل مسیر تعیین کنید، نه فقط یک مؤلفه.
برای عملیات حساس، شناسه یکتای درخواست و رفتار بدون اثر تکراری باید در لایه کاربرد طراحی شود. پراکسی نمی‌تواند از روی کد وضعیت همه معنای تجاری عملیات را بفهمد. در آزمایش، تأخیر مقصد را افزایش دهید و تعداد واقعی درخواست‌های رسیده را بشمارید. بررسی کنید آیا زمان انتظار کاربر با مجموع زمان‌های تنظیم‌شده سازگار است. کوتاه کردن مهلت در یک لایه بدون هماهنگی با لایه دیگر ممکن است فقط کار بیهوده‌ای ایجاد کند که پس از قطع انتظار کاربر همچنان در مقصد ادامه دارد.
مشاهده‌پذیری بدون برداشت نادرست
معیارهای پراکسی نمایی از ارتباط شبکه می‌دهند، اما لزوماً موفقیت تجاری را نشان نمی‌دهند. پاسخ موفق HTTP ممکن است حاوی نتیجه ناموفق کسب‌وکار باشد. از سوی دیگر، خطای شبکه ممکن است پس از انجام عملیات رخ دهد. برای فهم کامل، معیار خدمت، گزارش ساختاریافته و ردیابی توزیع‌شده باید مکمل هم باشند. انتشار شناسه ردیابی در زنجیره درخواست به همکاری برنامه‌ها نیاز دارد؛ نصب مش به تنهایی همه پیوندهای معنایی را ایجاد نمی‌کند.
برچسب‌ها و مسیرهای ثبت‌شده نیز باید از نظر حجم داده بررسی شوند. ثبت مسیر شامل شناسه کاربر یا شیء می‌تواند تعداد ترکیب‌ها را بالا ببرد. برای تحلیل روند، مسیر قالب‌بندی‌شده معمولاً از نشانی کاملاً متغیر مناسب‌تر است. نمونه‌برداری از ردیابی نیز بر احتمال دیدن رخداد نادر اثر می‌گذارد. وقتی یک درخواست در سامانه ردیابی پیدا نمی‌شود، پیش از نتیجه‌گیری درباره نرسیدن آن، سیاست نمونه‌برداری و زنجیره انتقال را بررسی کنید.
هزینه و مرز مناسب استفاده
پراکسی اضافی مصرف پردازنده، حافظه و زمان پردازش دارد. اندازه این هزینه به بار، نوع پروتکل، رمزنگاری و تنظیمات وابسته است؛ عدد ثابت و عمومی برای همه محیط‌ها قابل دفاع نیست. بار واقعی یا نمونه نزدیک به آن را با تعداد اتصال و اندازه پیام مشابه آزمایش کنید. مصرف هر پاد را همراه اثر روی ظرفیت گره بسنجید، زیرا هزینه کوچک در تعداد زیاد نمونه جمع می‌شود. همچنین توان تیم برای نگهداری سیاست‌ها و عیب‌یابی باید بخشی از تصمیم باشد.
این مقاله درباره مدل Sidecar است و نباید جزئیات آن را به همه حالت‌های استقرار Istio تعمیم داد. پیش از اجرای دستور یا طراحی سیاست، حالت نصب و نسخه محیط خود را مشخص کنید. انتخاب مش زمانی ارزش دارد که قابلیت‌هایی مانند هویت خدمت، سیاست ارتباط و مدیریت ترافیک نیاز واقعی باشند و تیم بتواند مسئولیت عملیاتی آن‌ها را بپذیرد. نتیجه مطلوب، مسیر ارتباطی قابل توضیح است: بتوان از یک درخواست ناموفق به تنظیم، هویت، مقصد و علت مشخص رسید.
یک برگه تشخیص برای خطای متناوب
در خطای متناوب، نام پاد مبدأ و مقصد هر درخواست را ثبت کنید. ممکن است فقط یک نمونه تنظیم قدیمی داشته باشد یا روی گره‌ای با مشکل شبکه قرار گرفته باشد. اگر همه درخواست‌ها را تنها با نام خدمت جمع کنید، این تفاوت پنهان می‌شود. ابتدا نسبت شکست هر نمونه را مقایسه کنید، سپس نسخه تنظیم و زمان ایجاد آن نمونه را بررسی کنید. حذف فوری پاد ممکن است علامت را برطرف کند، اما شواهد لازم برای علت ریشه‌ای را نیز از بین می‌برد؛ پیش از بازسازی، وضعیت و گزارش مرتبط را نگه دارید.
در ادامه، یک درخواست با شناسه مشخص را از مبدأ ثابت تکرار کنید و همزمان مقصد انتخاب‌شده را ببینید. اگر شکست همیشه با یک مقصد همراه است، بررسی همان مقصد اولویت دارد. اگر شکست به مبدأ وابسته است، پراکسی محلی، گره و مسیر خروج آن را بررسی کنید. اگر هیچ الگوی مکانی وجود ندارد، زمان‌بندی، انقضای اتصال و فشار بار را وارد تحلیل کنید. این روش تغییرات پراکنده در کل مش را به چند فرضیه قابل آزمون تبدیل می‌کند و خطر ایجاد خطای تازه حین عیب‌یابی را کاهش می‌دهد.
