این صفحه اجرای کوبرنتیز را در چندین منطقه توضیح میدهد..
کوبرنتیز به گونهای طراحی شده است که یک کلاستر کوبرنتیز میتواند در چندین منطقه خرابی اجرا شود، که معمولاً این مناطق در یک گروهبندی منطقی به نام region قرار میگیرند. ارائه دهندگان اصلی ابر، یک منطقه را به عنوان مجموعهای از مناطق خرابی (که به آن availability zones نیز میگویند) تعریف میکنند که مجموعهای از ویژگیها را ارائه میدهند: در یک منطقه، هر منطقه APIها و خدمات یکسانی را ارائه میدهد.
معماریهای ابری معمول با هدف به حداقل رساندن احتمال اینکه خرابی در یک منطقه، خدمات در منطقه دیگر را نیز مختل کند، طراحی شدهاند.
همه اجزای control plane از اجرا به عنوان مجموعهای از منابع قابل تعویض، که برای هر جزء تکرار میشوند، پشتیبانی میکنند.
هنگامی که یک control plane کلاستری را مستقر میکنید، کپیهایی از اجزای control plane را در چندین منطقه خرابی قرار دهید. اگر در دسترس بودن یک نگرانی مهم است، حداقل سه منطقه خرابی را انتخاب کنید و هر جزء control plane (API server, scheduler, etcd, cluster controller manager) را در حداقل سه منطقه خرابی تکرار کنید.
اگر یک مدیر کنترلکننده ابری را اجرا میکنید، باید این را در تمام مناطق خرابی که انتخاب کردهاید نیز تکرار کنید.
کوبرنتیز بهطور خودکار پادهای منابع بارکاری (مانند Deployment یا StatefulSet) را روی گرههای مختلف یک کلاستر توزیع میکند. این توزیع، اثر خرابیها را کاهش میدهد.
وقتی گرهها راهاندازی میشوند، kubelet روی هر گره بهطور خودکار labels را به شیء Node که نماینده همان kubelet در API کوبرنتیز است، اضافه میکند. این برچسبها میتوانند شامل اطلاعات ناحیه باشند.
اگر کلاستر شما چندین ناحیه یا منطقه را پوشش میدهد، میتوانید برچسبهای گره را بههمراه محدودیتهای گسترش توپولوژی پاد بهکار بگیرید تا کنترل کنید پادها در میان دامنههای خطا—ناحیهها، مناطق و حتی گرههای خاص— چطور در کلاستر پخش شوند. این راهنماها به scheduler کمک میکنند تا پادها را طوری جای دهد که دسترسی مورد انتظار بهبود یابد و خطر تأثیر یک خرابی همبسته بر کل بارکاری کاهش پیدا کند.
برای نمونه، میتوانید محدودیتی تعیین کنید تا اطمینان حاصل شود سه تکرار یک StatefulSet، هر یک در ناحیهای متفاوت اجرا شوند، هر زمان که امکانپذیر باشد. شما میتوانید این را بهصورت اعلامی تعریف کنید بیآنکه صراحتاً مشخص کنید کدام ناحیههای در دسترس برای هر بارکاری استفاده میشوند.
هسته کوبرنتیز خودش برای شما گره ایجاد نمیکند؛ باید این کار را خودتان انجام دهید یا از ابزاری مانند Cluster API برای مدیریت گرهها به نمایندگی از شما استفاده کنید.
با بهرهگیری از ابزارهایی مثل Cluster API میتوانید مجموعهای از ماشینها را تعریف کنید تا بهعنوان گرههای worker کلاستر در چندین دامنه خطا اجرا شوند، و همچنین قوانینی برای ترمیم خودکار کلاستر در صورت اختلال کامل یک ناحیه وضع کنید.
میتوانید محدودیتهای انتخابگر گره را به پادهایی که ایجاد میکنید، و نیز به قالبهای پاد در منابع بارکاری مانند Deployment، StatefulSet یا Job اعمال کنید.
هنگامی که حجمهای پایدار ایجاد میشوند، کوبرنتیز بهطور خودکار برچسبهای ناحیه را
به هر PersistentVolume که به یک ناحیه خاص متصل است اضافه میکند.
scheduler سپس از طریق
گزاره NoVolumeZoneConflict اطمینان حاصل میکند که پادهایی که یک PersistentVolume
مشخص را درخواست میکنند، تنها در همان ناحیه آن حجم قرار گیرند.
توجه داشته باشید که روش افزودن برچسبهای ناحیه میتواند به ارائهدهنده
ابر شما و فراهمکننده ذخیرهسازیای که استفاده میکنید وابسته باشد.
همیشه به مستندات اختصاصی محیط خود مراجعه کنید تا پیکربندی صحیح را تضمین کنید.
میتوانید یک StorageClass
را برای PersistentVolumeClaimها مشخص کنید که دامنههای خطا (ناحیهها) را که
ذخیرهسازی در آن کلاس میتواند از آنها استفاده کند تعریف میکند.
برای یادگیری پیکربندی یک StorageClass که از دامنههای خطا یا ناحیهها آگاه است،
به توپولوژیهای مجاز مراجعه کنید.
بهخودیِخود، کوبرنتیز شبکه آگاه از ناحیه در اختیار ندارد. میتوانید با استفاده از
افزونه شبکه
شبکه کلاستر را پیکربندی کنید؛ این راهکار شبکه ممکن است اجزای مخصوص به ناحیه داشته باشد.
برای نمونه، اگر ارائهدهنده ابر شما از Serviceهایی با
type=LoadBalancer پشتیبانی کند، توازنبار احتمالاً ترافیک را تنها به پادهایی میفرستد
که در همان ناحیهای اجرا میشوند که مؤلفه توازنبار در آن اتصال را پردازش میکند.
برای جزئیات بیشتر، به مستندات ارائهدهنده ابری خود مراجعه کنید.
برای استقرارهای سفارشی یا درونسازمانی نیز ملاحظات مشابهی وجود دارد. رفتار Service و Ingress—از جمله نحوه رسیدگی به نواحی خطای مختلف—بسته به چگونگی پیکربندی کلاستر شما متفاوت است.
هنگامی که کلاستر خود را راهاندازی میکنید، ممکن است لازم باشد بررسی کنید
که آیا و چگونه پیادهسازی شما میتواند سرویس را بازیابی کند اگر همه نواحی خطا
در یک منطقه بهطور همزمان از دسترس خارج شوند. برای نمونه، آیا
به این وابسته هستید که دستکم یک گره در یک ناحیه بتواند پادها را اجرا کند؟
اطمینان حاصل کنید که هر کار تعمیر حیاتی کلاستر به وجود دستکم یک گره سالم
وابسته نباشد. برای مثال، اگر تمام گرهها ناسالم شوند، شاید لازم باشد یک Job
تعمیر با toleration ویژه اجرا کنید
تا تعمیر بهاندازهای پیش برود که دستکم یک گره دوباره به سرویس بازگردد.
کوبرنتیز پاسخی از پیش آماده برای این چالش ارائه نمیدهد؛ بااینحال، موضوعی است که باید در نظر داشته باشید.
برای آشنایی با نحوه قرار دادن پادها در کلاستر توسط scheduler با رعایت محدودیتهای پیکربندیشده، به صفحه زمانبندی(Scheduling) و تخلیه(Eviction) مراجعه کنید.