مسئله و محدودیتها
بریف پروژه از ناوگانی با بیش از ۲۰۰ نود در مراکز تفکیک مرسولات صحبت میکند. مسئلهٔ معماری، یکسان نگه داشتن نسخهها بدون وابسته کردن عملیات محلی به ارتباط دائمی با مرکز است.
این سند طراحی پیشنهادی و فرضهای عملیاتی آن را توضیح میدهد. نتیجهٔ استقرار یا عملکرد در محیط واقعی، بدون شواهد و تلهمتری ادعا نمیشود.
تصمیمهای استقرار
هر مرکز یک دامنهٔ خرابی مستقل است. کلاستر سبک k3s سرویسهای محلی و صف پایدار رویدادها را اجرا میکند. مخزن وضعیت مطلوب، تاریخچهٔ نسخهها را قابل ممیزی نگه میدارد و ایمیجها با digest ثابت انتخاب میشوند.
انتشار از یک مرکز آزمایشی شروع میشود. بررسی آمادگی، ورود ترافیک را کنترل میکند. بودجهٔ اختلال و ظرفیت آزاد کافی امکان جایگزینی تدریجی را فراهم میکنند. شکست بررسی آمادگی باید ارتقای نسخه در بقیهٔ ناوگان را متوقف کند.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
استقرار بدون وقفه یک هدف است؛ تحقق آن به ظرفیت آزاد سالم، بررسی آمادگی صحیح و تغییرات سازگار دیتابیس وابسته است.
رفتار هنگام قطع شبکه
هر رویداد شناسهٔ ثابت و شناسهٔ مرکز دارد. لبه پیش از تأیید دریافت، رویداد را روی دیسک ثبت میکند. همگامسازی با تأخیر افزایشی تلاش میکند و مرکز رویدادهای تکراری را حذف میکند. تضمین ارسال، حداقل یک بار است و پردازش باید idempotent باشد.
تحلیل خرابی و راهنمای عملیات
- رجیستری در دسترس نیست: نسخهٔ سالم قبلی حفظ و انتشار متوقف شود.
- ارتباط ابری قطع شده: رویدادها محلی بمانند؛ سن صف و ظرفیت دیسک پایش شود.
- بررسی آمادگی شکست خورده: وضعیت مطلوب قبلی بازگردانده شود.
- مهاجرت ناسازگار: از الگوی گسترش و سپس حذف تدریجی فیلدهای قدیمی استفاده شود.
برنامهٔ اعتبارسنجی
سن صف، همگرایی نسخهها، نرخ خطا و زمان بازیابی را با قطع عمدی ارتباط اندازه بگیرید. برای انتشار گزارش حادثهٔ واقعی، خط زمانی، دامنهٔ اثر و شواهد هر بهبود باید اضافه شود.