مکعب روی مکعب، متاکلاسترها، لانه زنبوری، توزیع منابع

برنج. 1. اکوسیستم Kubernetes در Alibaba Cloud

از سال 2015، Alibaba Cloud Container Service برای Kubernetes (ACK) یکی از سریع ترین خدمات ابری در حال رشد در Alibaba Cloud بوده است. این سرویس به مشتریان متعددی خدمت می کند و همچنین از زیرساخت داخلی علی بابا و سایر خدمات ابری این شرکت پشتیبانی می کند.

همانند خدمات کانتینری مشابه از ارائه دهندگان ابری در کلاس جهانی، اولویت های اصلی ما قابلیت اطمینان و در دسترس بودن است. بنابراین، یک پلت فرم مقیاس پذیر و در دسترس جهانی برای ده ها هزار خوشه Kubernetes ایجاد شده است.

در این مقاله، ما تجربه خود را از مدیریت تعداد زیادی از خوشه های Kubernetes در زیرساخت ابری و همچنین معماری پلتفرم زیربنایی به اشتراک خواهیم گذاشت.

ورود

Kubernetes به استاندارد واقعی برای انواع بارهای کاری در فضای ابری تبدیل شده است. همانطور که در شکل نشان داده شده است. 1 در بالا، برنامه های بیشتر و بیشتری از Alibaba Cloud اکنون در خوشه های Kubernetes اجرا می شوند: برنامه های دارای حالت و بدون حالت، و همچنین مدیران برنامه. مدیریت Kubernetes همیشه موضوعی جالب و جدی برای مهندسانی بوده است که زیرساخت ایجاد و نگهداری می کنند. وقتی صحبت از ارائه دهندگان ابری مانند Alibaba Cloud به میان می آید، مسئله مقیاس پذیری مطرح می شود. چگونه می توان خوشه های Kubernetes را در این مقیاس مدیریت کرد؟ ما قبلاً بهترین روش‌ها را برای مدیریت خوشه‌های بزرگ 10 گرهی Kubernetes پوشش داده‌ایم. البته این یک مشکل مقیاس بندی جالب است. اما مقیاس دیگری وجود دارد: کمیت خود خوشه ها.

ما این موضوع را با بسیاری از کاربران ACK بحث کرده ایم. اکثر آنها ده ها، اگر نه صدها، خوشه کوچک یا متوسط ​​Kubernetes را انتخاب می کنند. دلایل خوبی برای این وجود دارد: محدود کردن آسیب احتمالی، جداسازی کلاسترها برای تیم های مختلف، ایجاد خوشه های مجازی برای آزمایش. اگر هدف ACK ارائه خدمات به مخاطبان جهانی با این مدل استفاده است، باید به طور قابل اعتماد و کارآمد تعداد زیادی از خوشه ها را در بیش از 20 منطقه مدیریت کند.

برنج. 2. مشکلات مدیریت تعداد زیادی از خوشه های Kubernetes

چالش های اصلی مدیریت خوشه ها در این مقیاس چیست؟ همانطور که در شکل نشان داده شده است، چهار مسئله وجود دارد:

• ناهمگونی

ACK باید از انواع مختلفی از کلاسترها، از جمله استاندارد، بدون سرور، Edge، ویندوز و چندین کلاس دیگر پشتیبانی کند. خوشه های مختلف به گزینه ها، اجزا و مدل های میزبانی متفاوتی نیاز دارند. برخی از مشتریان برای سفارشی سازی برای موارد خاص خود به کمک نیاز دارند.

• اندازه های مختلف خوشه

خوشه ها از نظر اندازه متفاوت هستند، از چند گره با چند غلاف تا ده ها هزار گره با هزاران غلاف. نیاز به منابع نیز بسیار متفاوت است. تخصیص نادرست منابع می تواند بر عملکرد تأثیر بگذارد یا حتی باعث شکست شود.

• نسخه های مختلف

Kubernetes بسیار سریع در حال تکامل است. نسخه های جدید هر چند ماه یکبار منتشر می شود. مشتریان همیشه مایلند ویژگی های جدید را امتحان کنند. بنابراین آنها می خواهند بار آزمایشی را روی نسخه های جدید Kubernetes و بار تولید را روی نسخه های پایدار قرار دهند. برای برآورده کردن این نیاز، ACK باید به طور مداوم نسخه های جدید Kubernetes را به مشتریان ارائه دهد و در عین حال نسخه های پایدار را حفظ کند.

• رعایت امنیت

خوشه ها در مناطق مختلف توزیع شده اند. به این ترتیب، آنها باید با الزامات ایمنی مختلف و مقررات رسمی مطابقت داشته باشند. برای مثال، یک خوشه در اروپا باید با GDPR مطابقت داشته باشد، در حالی که یک ابر مالی در چین باید لایه‌های حفاظتی بیشتری داشته باشد. این الزامات اجباری هستند و نادیده گرفتن آنها غیرقابل قبول است، زیرا این امر خطرات زیادی را برای مشتریان پلت فرم ابری ایجاد می کند.

پلتفرم ACK برای حل بیشتر مشکلات فوق طراحی شده است. در حال حاضر بیش از 10 هزار خوشه Kubernetes را در سراسر جهان به طور قابل اعتماد و پایدار مدیریت می کند. بیایید ببینیم که چگونه این امر به دست آمد، از جمله از طریق چندین اصل کلیدی طراحی/معماری.

طرح

مکعب روی مکعب و لانه زنبوری

برخلاف سلسله مراتب متمرکز، معماری مبتنی بر سلول معمولاً برای مقیاس‌بندی یک پلتفرم فراتر از یک مرکز داده واحد یا برای گسترش دامنه بازیابی بلایا استفاده می‌شود.

هر منطقه در ابر علی بابا از چندین ناحیه (AZ) تشکیل شده است و معمولاً مربوط به یک مرکز داده خاص است. در یک منطقه بزرگ (به عنوان مثال Huangzhou)، اغلب هزاران خوشه مشتری Kubernetes وجود دارد که ACK را اجرا می کنند.

ACK این خوشه‌های Kubernetes را با استفاده از خود Kubernetes مدیریت می‌کند، به این معنی که ما یک متاکلاستر Kubernetes داریم که برای مدیریت خوشه‌های Kubernetes کلاینت اجرا می‌شود. به این معماری "kube-on-kube" (KoK) نیز می‌گویند. معماری KoK مدیریت خوشه های مشتری را ساده می کند زیرا استقرار خوشه ساده و قطعی است. مهمتر از آن، ما می توانیم از ویژگی های بومی Kubernetes دوباره استفاده کنیم. به عنوان مثال، مدیریت سرورهای API از طریق استقرار، استفاده از عملگر etcd برای مدیریت etcds های متعدد. چنین بازگشتی همیشه لذت خاصی را به همراه دارد.

بسته به تعداد مشتریان، چندین متاکلاستر Kubernetes در یک منطقه مستقر هستند. ما این متاکلاسترها را سلول می نامیم. برای محافظت در برابر شکست کل یک منطقه، ACK از استقرار چند فعال در یک منطقه پشتیبانی می کند: متاکلاستر اجزای اصلی کلاستر مشتری Kubernetes را در چندین منطقه توزیع می کند و آنها را به طور همزمان اجرا می کند، یعنی در حالت چند فعال. برای اطمینان از قابلیت اطمینان و کارایی Master، ACK قرار دادن اجزا را بهینه می کند و اطمینان می دهد که سرور API و etcd به یکدیگر نزدیک هستند.

این مدل به شما امکان می دهد Kubernetes را به طور کارآمد، انعطاف پذیر و قابل اعتماد مدیریت کنید.

برنامه ریزی منابع متاکلاستر

همانطور که قبلاً اشاره کردیم، تعداد متاکلاسترها در هر منطقه به تعداد مشتریان بستگی دارد. اما در چه مرحله ای باید یک متاکلاستر جدید اضافه کرد؟ این یک مشکل معمولی برنامه ریزی منابع است. به عنوان یک قاعده، مرسوم است که زمانی که متاکلاسترهای موجود تمام منابع خود را تمام کرده اند، یک جدید ایجاد می شود.

به عنوان مثال منابع شبکه را در نظر بگیرید. در معماری KoK، اجزای Kubernetes از کلاسترهای مشتری به عنوان پادها در یک متاکلاستر مستقر می شوند. ما استفاده می کنیم تروی (شکل 3) یک افزونه با کارایی بالا است که توسط Alibaba Cloud برای مدیریت شبکه کانتینری توسعه یافته است. این مجموعه ای غنی از سیاست های امنیتی را ارائه می دهد و به شما امکان می دهد از طریق رابط شبکه الاستیک شبکه Alibaba (ENI) به ابرهای خصوصی مجازی مشتریان (VPC) متصل شوید. برای توزیع مؤثر منابع شبکه در میان گره‌ها، پادها و سرویس‌ها در یک متاکلاستر، باید به دقت استفاده از آنها را در متاکلاستر ابرهای خصوصی مجازی نظارت کنیم. هنگامی که منابع شبکه به پایان می رسد، یک سلول جدید ایجاد می شود.

برای تعیین تعداد بهینه خوشه های مشتری در هر متاکلاستر، هزینه ها، تراکم مورد نیاز، سهمیه منابع، الزامات قابلیت اطمینان و آمار را نیز در نظر می گیریم. تصمیم برای ایجاد یک متاکلاستر جدید بر اساس همه این اطلاعات گرفته می شود. لطفاً توجه داشته باشید که خوشه‌های کوچک می‌توانند در آینده بسیار گسترش یابند، بنابراین مصرف منابع افزایش می‌یابد حتی اگر تعداد خوشه‌ها بدون تغییر باقی بماند. ما معمولا فضای خالی کافی برای رشد هر خوشه باقی می گذاریم.

برنج. 3. معماری شبکه Terway

مقیاس بندی اجزای جادوگر در میان خوشه های مشتری

اجزای Wizard نیازهای منابع مختلفی دارند. آنها به تعداد گره ها و پادها در خوشه، تعداد کنترلرها/اپراتورهای غیر استانداردی که با APIServer تعامل دارند، بستگی دارند.

در ACK، هر خوشه مشتری Kubernetes از نظر اندازه و نیازهای زمان اجرا متفاوت است. هیچ پیکربندی جهانی برای قرار دادن اجزای جادوگر وجود ندارد. اگر به اشتباه محدودیت منابع کم را برای یک کلاینت بزرگ تعیین کنیم، خوشه آن قادر به مقابله با بار نخواهد بود. اگر یک حد محافظه کارانه بالا برای همه خوشه ها تعیین کنید، منابع هدر خواهند رفت.

برای یافتن یک مبادله ظریف بین قابلیت اطمینان و هزینه، ACK از یک سیستم نوع استفاده می کند. یعنی ما سه نوع خوشه را تعریف می کنیم: کوچک، متوسط ​​و بزرگ. هر نوع دارای یک نمایه تخصیص منابع جداگانه است. نوع بر اساس بار اجزای جادوگر، تعداد گره ها و عوامل دیگر تعیین می شود. نوع خوشه ممکن است در طول زمان تغییر کند. ACK به طور مداوم این عوامل را کنترل می کند و می تواند بر اساس آن تایپ کند. هنگامی که نوع خوشه تغییر کرد، تخصیص منابع به طور خودکار با حداقل مداخله کاربر به روز می شود.

ما در تلاش هستیم تا این سیستم را با مقیاس بندی دقیق تر و به روز رسانی نوع دقیق تر بهبود دهیم تا این تغییرات راحت تر اتفاق بیفتد و منطقی اقتصادی بیشتری داشته باشد.

برنج. 4. سوئیچینگ هوشمند چند مرحله ای

تکامل خوشه های مشتری در مقیاس

بخش های قبلی برخی از جنبه های مدیریت تعداد زیادی از خوشه های Kubernetes را پوشش می دهد. با این حال، مشکل دیگری وجود دارد که باید حل شود: تکامل خوشه ها.

Kubernetes "لینوکس" دنیای ابری است. به طور مداوم به روز می شود و مدولارتر می شود. ما باید دائماً نسخه‌های جدید را به مشتریان خود تحویل دهیم، آسیب‌پذیری‌ها را برطرف کنیم و خوشه‌های موجود را به‌روزرسانی کنیم، و همچنین تعداد زیادی مؤلفه مرتبط (CSI، CNI، پلاگین دستگاه، پلاگین Scheduler و بسیاری دیگر) را مدیریت کنیم.

بیایید مدیریت اجزای Kubernetes را به عنوان مثال در نظر بگیریم. برای شروع، ما یک سیستم متمرکز برای ثبت و مدیریت تمام این اجزای متصل ایجاد کردیم.

برنج. 5. اجزای قابل انعطاف و قابل اتصال

قبل از حرکت به جلو، باید مطمئن شوید که به روز رسانی موفقیت آمیز بوده است. برای انجام این کار، سیستمی برای بررسی عملکرد اجزای سازنده ایجاد کرده ایم. بررسی قبل و بعد از به روز رسانی انجام می شود.

برنج. 6. بررسی اولیه اجزای خوشه

برای به‌روزرسانی سریع و مطمئن این مؤلفه‌ها، یک سیستم استقرار مداوم با پشتیبانی از پیشرفت جزئی (مقیاس خاکستری)، مکث و سایر عملکردها کار می‌کند. کنترلرهای استاندارد Kubernetes برای این مورد مناسب نیستند. بنابراین، برای مدیریت اجزای کلاستر، مجموعه‌ای از کنترل‌کننده‌های تخصصی، شامل یک پلاگین و یک ماژول کنترل کمکی (مدیریت سایدکار) را توسعه داده‌ایم.

به عنوان مثال، کنترلر BroadcastJob برای به روز رسانی اجزای هر ماشین کارگر یا بررسی گره ها در هر ماشین طراحی شده است. کار Broadcast روی هر گره در خوشه یک pod اجرا می کند، مانند DaemonSet. با این حال، DaemonSet همیشه پاد را برای مدت طولانی در حال اجرا نگه می دارد، در حالی که BroadcastJob آن را خراب می کند. کنترلر Broadcast همچنین پادها را روی گره های تازه به هم پیوسته راه اندازی می کند و گره ها را با اجزای لازم مقداردهی اولیه می کند. در ژوئن 2019، ما کد منبع موتور اتوماسیون OpenKruise را باز کردیم که خودمان از آن در شرکت استفاده می کنیم.

برنج. 7. OpenKurise اجرای وظیفه Broadcast را در تمام گره ها سازماندهی می کند

برای کمک به مشتریان در انتخاب پیکربندی‌های خوشه‌ای مناسب، مجموعه‌ای از پروفایل‌های از پیش تعریف‌شده شامل پروفایل‌های بدون سرور، لبه، ویندوز و بره متال را نیز ارائه می‌کنیم. همانطور که چشم انداز گسترش می یابد و نیازهای مشتریان ما افزایش می یابد، ما پروفایل های بیشتری را برای ساده سازی فرآیند راه اندازی خسته کننده اضافه خواهیم کرد.

برنج. 8. پروفایل های خوشه ای پیشرفته و انعطاف پذیر برای سناریوهای مختلف

قابلیت مشاهده جهانی در مراکز داده

همانطور که در شکل زیر نشان داده شده است. 9، سرویس ابری کانتینر ابری علی بابا در بیست منطقه در سراسر جهان مستقر شده است. با توجه به این مقیاس، یکی از اهداف کلیدی ACK این است که به راحتی وضعیت خوشه های در حال اجرا را کنترل کند تا اگر یک کلاستر مشتری با مشکلی مواجه شد، بتوانیم به سرعت به وضعیت پاسخ دهیم. به عبارت دیگر، شما باید راه حلی ارائه دهید که به شما امکان می دهد به طور کارآمد و ایمن آمار را در زمان واقعی از خوشه های مشتری در همه مناطق جمع آوری کنید - و نتایج را به صورت بصری ارائه دهید.

برنج. 9. استقرار جهانی سرویس کانتینر ابری علی بابا در بیست منطقه

مانند بسیاری از سیستم های نظارتی Kubernetes، ما از Prometheus به عنوان ابزار اصلی خود استفاده می کنیم. برای هر متاکلاستر، عوامل پرومتئوس معیارهای زیر را جمع آوری می کنند:

• معیارهای سیستم عامل مانند منابع میزبان (CPU، حافظه، دیسک و غیره) و پهنای باند شبکه.
• معیارهایی برای سیستم مدیریت کلاستر متاکلاستر و مشتری، مانند kube-apiserver، kube-controller-manager و kube-scheduler.
• معیارها از kubernetes-state-metrics و cadvisor.
• معیارهای etcd مانند زمان نوشتن دیسک، اندازه پایگاه داده، توان عملیاتی اتصالات بین گره ها و غیره.

آمار جهانی با استفاده از یک مدل تجمیع چند لایه معمولی جمع آوری می شود. داده های مانیتورینگ از هر متاکلاستر ابتدا در هر منطقه جمع می شود و سپس به یک سرور مرکزی ارسال می شود که تصویر کلی را نشان می دهد. همه چیز از طریق مکانیزم فدراسیون کار می کند. یک سرور Prometheus در هر مرکز داده، معیارها را از آن مرکز داده جمع‌آوری می‌کند و سرور مرکزی Prometheus مسئول جمع‌آوری داده‌های نظارت است. AlertManager به Prometheus مرکزی متصل می شود و در صورت لزوم، هشدارها را از طریق DingTalk، ایمیل، SMS و غیره ارسال می کند. تجسم - با استفاده از Grafana.

در شکل 10، سیستم نظارت را می توان به سه سطح تقسیم کرد:

• سطح مرز

دورترین لایه از مرکز. سرور Prometheus Edge در هر متاکلاستر اجرا می شود و معیارها را از متا و کلاسترهای مشتری در همان دامنه شبکه جمع آوری می کند.

• سطح آبشار

عملکرد لایه آبشار Prometheus جمع آوری داده های نظارتی از چندین منطقه است. این سرورها در سطح واحدهای جغرافیایی بزرگتری مانند چین، آسیا، اروپا و آمریکا کار می کنند. همانطور که خوشه ها رشد می کنند، منطقه را می توان تقسیم کرد و سپس یک سرور Prometheus در سطح آبشاری در هر منطقه بزرگ جدید ظاهر می شود. با استفاده از این استراتژی، می توانید به آرامی در صورت نیاز مقیاس بندی کنید.

• سطح مرکزی

سرور مرکزی Prometheus به تمام سرورهای آبشاری متصل می شود و جمع آوری داده های نهایی را انجام می دهد. برای قابلیت اطمینان، دو نمونه مرکزی Prometheus در مناطق مختلف، متصل به سرورهای آبشاری یکسان، مطرح شدند.

برنج. 10. معماری نظارتی چندسطحی جهانی بر اساس مکانیسم فدراسیون پرومتئوس

خلاصه

راه حل های ابری مبتنی بر Kubernetes همچنان صنعت ما را متحول می کند. سرویس کانتینر Alibaba Cloud میزبانی ایمن، قابل اعتماد و با کارایی بالا را ارائه می دهد - این یکی از بهترین هاست های ابری Kubernetes است. تیم Alibaba Cloud قویاً به اصول منبع باز و جامعه منبع باز اعتقاد دارد. ما قطعا به اشتراک گذاری دانش خود در زمینه عملیات و مدیریت فناوری های ابری ادامه خواهیم داد.

منبع: www.habr.com