یک سرویس جست‌وجو باید در دو مرکز داده اجرا شود. تیم می‌خواهد تعریف برنامه و نسخه تصویر در یک محل مدیریت شود، اما شمار نسخه‌ها و نام کلاس ذخیره‌سازی در دو خوشه یکسان نیستند. کپی دستی فایل‌ها در آغاز ساده به نظر می‌رسد. با نخستین تغییر اضطراری یا افزودن خوشه سوم، تفاوت نسخه‌ها و مالکیت تنظیمات به مسئله عملیاتی تبدیل می‌شود. Karmada برای توزیع منابع Kubernetes به خوشه‌های عضو از الگوی منبع، سیاست انتشار و سیاست تغییر محلی استفاده می‌کند. مسیر یک Deployment نشان می‌دهد کدام تصمیم در صفحه کنترل چندخوشه‌ای گرفته می‌شود و کدام تصمیم همچنان بر عهده Kubernetes محلی است.
الگوی منبع نقطه شروع است
تیم تعریف Deployment را به عنوان resource template در صفحه کنترل Karmada ایجاد می‌کند. این تعریف از API آشنای Kubernetes استفاده می‌کند و ویژگی‌هایی مانند تصویر کانتینر، تنظیمات برنامه و برچسب‌ها را در بر دارد. وجود الگو در صفحه کنترل به تنهایی به معنی اجرای Pod در یک خوشه عضو نیست. باید سیاستی آن را انتخاب کند و مقصدهای قابل استفاده تعیین شوند. این جداسازی اجازه می‌دهد همان الگو بدون تکرار همه فیلدها برای چند مقصد استفاده شود. از دید عیب‌یابی نیز اولین پرسش این است که آیا الگو واقعاً توسط سیاست مورد انتظار انتخاب شده است.
انتخاب منبع باید به اندازه کافی دقیق باشد. سیاستی که فقط بر نوع Deployment تکیه کند شاید برنامه‌هایی را هم شامل شود که برای انتشار چندخوشه‌ای طراحی نشده‌اند. افزودن نام، namespace یا selector برچسب می‌تواند دامنه را کنترل کند. اما برچسب بخشی از قرارداد است. اگر تیم برنامه در انتشار بعدی برچسب را تغییر دهد، رابطه انتخاب ممکن است عوض شود. مستند کردن مالک برچسب و آزمون اثر تغییر آن از انتشار ناخواسته جلوگیری می‌کند. در محیط چندتیمی، مجوز ایجاد سیاست گسترده باید با دامنه منابع و خوشه‌هایی که می‌تواند تحت تأثیر قرار دهد متناسب باشد.
PropagationPolicy مقصد را مشخص می‌کند
PropagationPolicy قواعد انتخاب منابع و خواسته‌های placement را بیان می‌کند. نسخه نام‌فضایی سیاست و ClusterPropagationPolicy با دامنه خوشه کاربرد و سطح اختیار متفاوتی دارند. سیاست می‌تواند خوشه‌ها را بر اساس نام یا ویژگی‌های دیگر انتخاب کند و شرایط توزیع را شرح دهد. در مثال جست‌وجو، تیم ممکن است تنها خوشه‌های یک منطقه یا خوشه‌هایی با ظرفیت خاص را مجاز بداند. فهرست خوشه ثبت‌شده با فهرست مقصد واجد شرایط یکسان نیست. سلامت، برچسب‌ها، محدودیت‌های سیاست و شرایط لازم برای همان بار کاری در تصمیم اثر می‌گذارند.
اگر یک خوشه جدید به سامانه اضافه شد، ابتدا بررسی کنید سیاست آن را با چه معیاری خواهد دید. عضویت خودکار یک خوشه آزمایشی در گروه تولید می‌تواند به انتشار داده یا برنامه در محل نامناسب منجر شود. نام‌گذاری و برچسب‌گذاری باید با مالکیت واقعی محیط همسو باشد. پیش از اعمال سیاست گسترده، مجموعه مقصد مورد انتظار را روی کاغذ مشخص کنید و سپس با وضعیت binding مقایسه کنید. برای سیستم دارای محدودیت جغرافیایی داده، انتخاب منطقه باید یک شرط قابل مشاهده باشد. یک اسم شبیه «اروپا» بدون کنترل مشخصات خوشه تضمینی برای محل حقیقی اجرای بار کاری ایجاد نمی‌کند.
Binding تصمیم توزیع را قابل مشاهده می‌کند
پس از انتخاب الگو، منابع binding رابطه میان الگو و خوشه‌های مقصد را بازتاب می‌دهند. این مرحله برای تشخیص اینکه مشکل در انتخاب سیاست است یا در اجرای محلی اهمیت دارد. اگر binding ساخته نشده، باید الگو و selector را بررسی کرد. اگر binding وجود دارد ولی مقصد مورد انتظار در آن دیده نمی‌شود، شرایط placement و وضعیت همان خوشه موضوع اصلی است. اگر مقصد درست انتخاب شده ولی Deployment در عضو دیده نمی‌شود، مسیر انتقال و وضعیت اجرای کار در آن خوشه بررسی می‌شود. تمرکز مستقیم روی Pod در این مرحله ممکن است زودهنگام باشد، زیرا هنوز منبع به مقصد نرسیده است.
منابع Work حامل اطلاعاتی هستند که باید در خوشه عضو اعمال شوند. خطای مجوز، نبود نوع API مربوط یا خطای اعتبارسنجی محلی می‌تواند مانع اعمال شود. وجود تصمیم توزیع به خودی خود موفقیت اعمال منبع را ثابت نمی‌کند. سپس پس از ایجاد Deployment، کنترل‌گر محلی مسئول ساخت ReplicaSet و Pod است. scheduler محلی نیز تصمیم می‌گیرد Pod روی کدام گره قرار گیرد. این دو سطح زمان‌بندی وظایف متفاوتی دارند. Karmada ممکن است خوشه درست را انتخاب کرده باشد ولی در همان خوشه Pod به دلیل کمبود حافظه یا نبود volume در انتظار بماند.
شمار نسخه‌ها چگونه بین اعضا تقسیم می‌شود؟
در طراحی سیاست باید مشخص شود هر خوشه کل شمار نسخه‌های الگو را دریافت می‌کند یا تعداد کل replicas میان مقصدها تقسیم می‌شود. در روش تکرار، خواسته الگو در هر مقصد پیاده می‌شود و شمار کل نمونه‌ها می‌تواند با تعداد خوشه‌ها افزایش یابد. در روش تقسیم، هدف توزیع مجموع نسخه‌ها بر اساس قواعد سیاست است. این تفاوت مستقیماً روی هزینه و تحمل خرابی اثر دارد. اگر الگو شش نسخه داشته باشد، انتظار شش نسخه در هر یک از دو خوشه با انتظار سه نسخه در هر خوشه دو قرارداد متفاوت درباره ظرفیت و دسترس‌پذیری می‌سازد.
وزن یا قواعد توزیع نسخه‌ها باید با نیاز ترافیک و ظرفیت خوشه‌ها هماهنگ باشد. توزیع تعداد مساوی Pod تضمین نمی‌کند مقدار مساوی درخواست به هر مرکز داده برسد. سامانه DNS، load balancer یا مسیر شبکه مشتری نیز در توزیع ترافیک اثر دارد. اگر بیشتر کاربران به خوشه اول می‌رسند، خوشه دوم ممکن است ظرفیت آزاد داشته باشد در حالی که اولی اشباع شده است. بنابراین تعداد replica را کنار ترافیک واقعی و زمان پاسخ هر منطقه بررسی کنید. همچنین ظرفیت قابل استفاده پس از خرابی یک خوشه باید از قبل برآورد شود. وجود نسخه در منطقه دوم لزوماً برای پذیرش کل بار کافی نیست.
OverridePolicy تفاوت‌های محیطی را ثبت می‌کند
برخی خصوصیات منابع در مقصدها متفاوت‌اند. نام StorageClass، پیشوند رجیستری داخلی یا تنظیم خاص شبکه می‌تواند وابسته به خوشه باشد. OverridePolicy اجازه می‌دهد تغییرهای مربوط به مقصد در سطح سیاست تعریف شوند و الگوی مشترک همچنان قابل نگه‌داری بماند. نمونه‌ای روشن، انتخاب رجیستری نزدیک‌تر برای هر منطقه است. اما مقدار پس از تغییر باید همان محتوای مورد انتظار را ارائه دهد. برابری tag در دو رجیستری لزوماً معنای برابری digest را تضمین نمی‌کند. برای انتشار حساس، محتوای واقعی تصویر و سیاست اعتماد باید در هر دو مقصد بررسی شود.
تعداد زیاد overrideها می‌تواند فهم وضعیت واقعی را دشوار کند. برای هر تغییر، علت، مالک و محدوده خوشه را ثبت کنید. اگر یک ویژگی فقط برای یک برنامه و یک مقصد لازم است، سیاست عمومی نباید روی ده‌ها منبع دیگر اثر بگذارد. همچنین باید پیش از اعمال، نتیجه ترکیب الگو و تغییرهای محلی را مشاهده یا در محیط محدود آزمایش کرد. خطای ظریفی مانند تغییر مسیر نادرست یک فیلد می‌تواند تنها در یکی از خوشه‌ها ظاهر شود. مقایسه مستقیم منبع نهایی دو مقصد معمولاً از نگاه کردن تنها به فایل الگوی مرکزی اطلاعات بیشتری می‌دهد.
وابستگی برنامه و داده در چند خوشه
انتشار Deployment به تنهایی سرویس را در منطقه دوم قابل استفاده نمی‌کند. برنامه شاید به Secret، ConfigMap، ServiceAccount، پایگاه داده یا کلاس ذخیره‌سازی نیاز داشته باشد. بعضی وابستگی‌ها را می‌توان با سیاست جدا منتشر کرد و بعضی عمداً در هر خوشه به شکل محلی مدیریت می‌شوند. کلید دسترسی منطقه اول نباید بدون ارزیابی به منطقه دوم کپی شود. ترتیب ایجاد نیز اهمیت دارد. اگر Deployment زودتر از Secret لازم برسد، Pod ساخته می‌شود ولی آماده نیست. وضعیت آماده برنامه باید پس از بررسی همه وابستگی‌های واقعی سنجیده شود.
برای سرویس دارای داده ماندگار، انتشار تعریف volume به معنی انتقال محتوای داده نیست. هر خوشه می‌تواند ظرفیت ذخیره‌سازی محلی خود را بسازد، اما همسان‌سازی پایگاه داده یا فایل‌ها به فناوری و قرارداد جدا نیاز دارد. اگر مشتری در منطقه اول سفارش ثبت کند و درخواست بعدی او به منطقه دوم برسد، برنامه باید بداند داده چه زمانی آنجا قابل مشاهده است. Karmada تصمیم جایگیری منابع را مدیریت می‌کند، ولی طراحی سازگاری داده و مسیریابی کاربر همچنان بر عهده سامانه است. در آزمون خرابی باید هم ادامه اجرای Pod و هم درستی داده‌ای که کاربر می‌بیند بررسی شود.
تمرین خرابی و بازگشت یک خوشه
فرض کنید ارتباط صفحه کنترل با خوشه دوم قطع شده است. نخست زمان آخرین وضعیت معتبر، شرایط عضو و تصمیم‌های binding را ثبت کنید. قطع مسیر مدیریت لزوماً به معنی توقف فوری برنامه‌های در حال اجرا در عضو نیست. از طرف دیگر، دیدن وضعیت قدیمی آماده نیز حضور فعلی همه Podها را ثابت نمی‌کند. مشاهده مستقل از مسیر کاربر و بررسی داخل منطقه کمک می‌کند میان قطع مدیریت و قطع واقعی سرویس تفاوت گذاشته شود. سیاست جابه‌جایی یا failover باید به گونه‌ای تنظیم شود که رفتار مورد انتظار در برابر این دو حالت روشن باشد.
پس از بازگشت عضو، شمار نسخه‌ها، محل ترافیک و وضعیت داده‌ها را دوباره بررسی کنید. امکان دارد در دوره قطع، ظرفیت اضافی در خوشه دیگری ایجاد شده باشد و بازگشت به تعادل زمان ببرد. اگر بار کاری عملیات زمان‌بندی‌شده یا پردازش صف انجام می‌دهد، اجرای همزمان چند نمونه باید با قرارداد خود برنامه سازگار باشد. یک Job که تصور می‌کند تنها در یک منطقه اجرا می‌شود ممکن است پس از جابه‌جایی دوبار اثر تجاری ایجاد کند. شناسه یکتای کار و کنترل تکرار باید در طراحی برنامه پیش‌بینی شود. این مسائل با شمارش ساده Podهای سالم آشکار نمی‌شوند.
برای گزارش نهایی انتشار، مسیر هر نمونه را از الگوی مرکزی تا نتیجه کاربر ثبت کنید. سیاست منبع را انتخاب کرده، binding مقصد را تعیین کرده، Work اعمال شده، کنترل‌گر محلی Pod را ساخته و مسیر ترافیک درخواست را به آن رسانده است. در هر مرحله نام خوشه و زمان مشاهده را حفظ کنید. چنین پرونده‌ای به تیم اجازه می‌دهد هنگام تغییر یک برچسب یا کلاس ذخیره‌سازی، دقیقاً ببیند کدام قرارداد عوض شده و اثر آن به کدام منطقه محدود است.
در سناریوی دو مرکز داده، یک تغییر کوچک مانند به‌روزرسانی نسخه تصویر را ابتدا برای یکی از مقصدها بسنجید. مقدار digest در الگوی مرکزی، تنظیم نهایی عضو و تصویر واقعی Pod را مقایسه کنید. اگر این سه مقدار با انتظار سازگار نیستند، محل اختلاف به ترتیب در override، اعمال منبع یا دریافت تصویر قرار می‌گیرد. چنین مقایسه‌ای با هزینه کم نشان می‌دهد تصمیم انتشار در کدام لایه از وضعیت واقعی فاصله گرفته است.
