پشتیبان

در این مقاله سعی می‌کنیم کوبرنتیز (Kubernetes) و معماری آن و نقشی که در یک زیرساخت رایانش ابری و معماری میکروسرویس ایفا می‌کند را توضیح دهیم.

مجازی سازی و کانتینر

فناوری مجازی سازی (Virtualization) با فراهم کردن امکان اجرا شدن سیستم عامل های مختلف و برنامه‌های کاربردی با نیازمندی و وابستگی های گوناگون بر روی سرورها، بازدهی دیتاسنتر ها را تا حد زیادی افزایش داده است. تمرکز مجازی سازی همواره بر یک پارچه سازی [منابع] سرورها ست که خود نیازمند جدا سازی سیستم عامل از سخت افزار است. در این شرایط سیستم عامل ها بدون وابستگی به سخت افزار در یک لایه مجزا شده اجرا می‌شوند و عمل می‌کنند. بدین ترتیب برنامه‌های کاربردی (Applications) که بر روی آن سیستم عامل‌ها اجرا شده‌اند هم مجزا از سخت افزار کار خواهند کرد.

همان طور که در تصویر زیر نشان داده‌ایم، در سمت چپ ماشین های مجازی (VMs) بر روی یک مجازی ساز ایجاد شده اند. بر روی هر ماشین مجازی یک سیستم عامل نصب شده است و در نتیجه هر ماشین مجازی مانند یک میزبان مستقل نگهداری می شود. از طرف دیگر کانتینرها هستند که همان طور که در تصویر میبنید شامل یک انجین کانتینر هستند که کاتینترها را مدیریت می‌کند. مجازی سازی از طریق کانتینرها کانتینرایزیشن (containerization) گفته می شود. بدین ترتیب چندین کانتینر مختلف بر روی یک هسته‌ی سیستم عامل معمولی اجرا می‌شوند که خود از پارتیشن‌های منطقی و سخت افزار مجزا شده است.

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

ماشین‌های مجازی (Virtual Machines) یا VMs

ماشین های مجازی همان طور که از نامشان پیداست به صورت مجازی یک اکوسیستم سخت افزاری را ایجاد می‌کنند که سیستم عامل روی آن مستقر می شود و یک یا چند برنامه کاربردی را اجرا می‌کند. با استفاده از مجازی ساز (hypervisor)، کاربران می‌توانند اینستنس های مختلف سیستم عامل را بر روی یک ماشین ایجاد کنند. کاربر این قابلیت را دارد که برای هر ماشین مجازی منابع CPU  و مموری و دیسک مورد نیاز را اختصاص دهد و اپلیکیشن را از سیستم عامل های نصب شده رها سازد.

مجازی سازی شامل قابلیت های انعطاف پذیری مانند جابه‌جایی در حین سرویس دهی، دسترسی پذیری همیشگی، شبکه نرم‌افزار محور (SDN) و یک پارچه سازی ذخیره سازی‌هاست که تا امروز هیچ کدام از این قابلیت ها در کانتینرایزیشن مهم تلقی نمی شوند. همچنین مجازی سازی یک لایه امنیتی دیگر اضافه می‌کند بدین ترتیب که حجم کار (workload) بر روی یک سیستم عامل مجزا از سیستم عامل اصلی اجرا می‌شود.

کانتینرها (Containers)

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

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

از خصوصیات کانتینرها به موارد زیر میتوان اشاره کرد:

استاندارد: با استفاده از ابزاری مانند داکر یک استادارد واحد برای اجرای برنامه‌ها در هر محیطی وجود خواهد داشت.

سبکبالی: کانتینر ها هسته اصلی سیستم عامل را به صورت مشترک استفاده میکنند که راندمان بهتر در زیرساخت و کاهش هزینه سرور و لایسنس را به همراه می‌آورد و نیاز بکارگیری سیستم عامل مهمان برای هر برنامه کاربردی را برطرف می کند. سبکی کانیتنرها سرعت زیادی به ارمغان می آورد.

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

جداسازی منابع: کانتینر ها می‌توانند با استفاده از منابع از پیش تعیین شده اجرا شوند. بنابراین امکان کنترل و جلوگیری از تصرف ناخواسته منابع بر روی یک سیستم گرفته می شود.

هم آهنگی خودکارسازی‌ها (Orchestration) با کوبرنتیز

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

در تصویر زیر کانتینرها و ماشین های مجازی در یک معماری هیبریدی بکار گرفته شده اند یک اپلیکیشن که با کانتیننر ایزوله شده در یک کلاستر ماشین های مجازی در حال استقرار و به روزرسانی است.

در یک چنین معماری نیاز به یک هم آهنگ ساز دارید تا مدیریت، استقرار، اسکیل، شبکه و دسترسی پذیری یک اپلیکیشن کانتینرشده را بر عهده بگیرد. اینجاست که کوبرنتیز وارد می شود و بسیاری از روند ها را خودکار کرده و خودکار سازی های مورد نیاز را منظم و به ترتیب و در بهینه ترین حالت اجرا می کند.  کوبرنتیز (Kubernetes‎)  نرم افزاری متن باز برای ارکستراسیون برنامه‌های بر پایه کانتینر محسوب می‌شود. به زبان go نوشته شده و ۶ ژوئن ۲۰۱۴؛ با لایسنس آپاچی ۲ منتشر شده است. کوبرنتیز به‌سرعت راه خود را به جوامع فناوری باز کرد و به رقیب بزرگی برای ساز و کارهای دیگر کنترل کانتینرها مانند Apache Mesos و Docker Swarm تبدیل شد.

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

معماری کوبرنتیز

زمانی که کوبرنتیز را مستقر می‌کنید یک کلاستر (cluster) خواهید داشت.  Kubernetes با استفاده از یک شبکه مشترک برای برقراری ارتباط بین هر سرور، ماشین‌های مجازی یا فیزیکی جداگانه را در یک کلاستر جمع می‌کند. این مجموعه، یک بستر فیزیکی است که در آن تمام اجزای Kubernetes، قابلیت‌ها و workloadها پیکربندی شده است.

بخش Master کوبرنتیز

هر یک از ماشین‌های موجود در این مجموعه، در اکوسیستم Kubernetes دارای نقشی هستند. یک بخش(یا گروه کوچکی در Deploymentهایی با دسترسی بسیار بالا) به عنوان بخش master کار می‌کند. این  بخش با قرار دادن یک API برای کاربران و کلاینت‌ها، بررسی سلامت سرورهای دیگر، تصمیم گیری در مورد بهترین روش تقسیم و تخصیص کار (معروف بهscheduling  و تنظیم هماهنگی ارتباطات بین سایر مولفه‌ها، به عنوان یک gateway و مرکز برای cluster عمل می‌کند. سرور master به عنوان نقطه اصلی ارتباط با کلاستر عمل می‌کند و مدیریت و نظارت متمرکز در سراسر سیستم Kubernetes را فراهم می‎نماید. اجزای بخش Master  را به شرح زیر می‌توان معرفی کرد:

kube-apiserver : یکی از مهم ترین اجزای Master  کوبرنتیز API آن است. این بخش رابط جلویی کنترل پنل کوبرنتیز است.  به کاربر اجازه می‌دهد تا  workloadها و واحدهای سازمانی کوبرنتیز را پیکربندی کند. همچنین مسئولیت تضمین سازگاری حافظه و سرویس‌های مستقر در کانتینر را به عهده دارد. این سرور در واقع به عنوان پلی بین اجزای مختلف به منظور نگهداری کلاستر و انتشار اطلاعات و دستورات عمل می‌کند.

Etcd: مخزن نگهداری داده‌های پیکربندی کلاستر است که باید در دسترس نودها قرار داشته باشد.

kube-scheduler: بخش scheduler یا «برنامه ریز» وظیفه اختصاص پادهایی که تازه ایجاد شده اند را به نودها  برعهده دارد تا بر روی آن نود اجرا شوند.

 kube-controller-manager: مدیر کنترل، یک سرویس سراسری است که مسئولیت‌های زیادی دارد. در درجه اول، کنترل کننده‌های مختلفی را کنترل می‌کند که آن‌ها وضعیت کلاستر را تنظیم می‌نمایند، چرخه‌های حیاط workload را مدیریت می‌کنند و کارهای معمول را انجام می‌دهند. به عنوان مثال، یک Replication-Controller تضمین می‌کند که تعداد نسخه‌های مشابه تعریف شده برای یک pod مطابق با تعداد فعلی مستقر شده در کلاستر است. جزئیات این عملیات در etcd نوشته می‌شود که در آن، مدیر کنترل کننده از طریق سرور API تغییرات را مشاهده می‌نماید.

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

نودها Node(s)

کلاسترِ کوبرنتیز از مجموعه‌ای از ماشین‌های کارگر تشکیل شده است که به آنها نود (Node)  می‌گوییم. نودها اپلیکیشن‌های کانتینرایز شده را اجرا می‌کنند. هر node باید به container runtime  مانند Docker یا rkt  مجهز باشد. نود دستورالعمل‌های کار را از Master دریافت می‌کند و کانتینر‌های مربوطه را ایجاد کرده یا از بین می‌برد. همچنین قوانین شبکه را برای مسیریابی و هدایت ترافیک به طور مناسب تنظیم می‌کند. هر کلاستر حداقل از یک نود تشکیل شده است.

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

اجزای تشکیل دهنده هر نود را میتوان به این صورت لیست کرد:

Kubelet: این ایجنت بر روی هر نود اجرا میشود و وظیفه کنترل سلامت کانتینرها و اجرای درست آن‌ها بر روی پادها را بر عهده دارد.

kube-proxy: یک سرویس پراکسی کوچک به نام kube-proxy در هر سرور node اجرا می‌شود. این فرایند درخواست‌ها را به کانتینرهای صحیح هدایت می‌کند که این می‌تواند تعادل بار اولیه را انجام دهد و به طور کلی مسئولیت تضمین قابل پیش بینی بودن و قابلیت دسترسی به محیط شبکه (اما در صورت لزوم جدا) را به عهده دارد.

پادها Pods

نودهای کارگر، میزبان پادها (Pods) هستند که خود workloadهای اپلیکیشن را میزبانی می‌کنند. pod اساسی‌ترین واحدی است که kubernetes با آن سرو کار دارد. container ها خودشان به میزبان اختصاص داده نمی‌شوند؛ بلکه، یک یا چند container محکم بهم پیوسته و در شیئ‌ای به نام pod بسته‌بندی می‌شوند.

پاد به طور کلی نشان دهنده یک یا چند container است که باید به عنوان یک برنامه کنترل شود. پادها از   container هایی تشکیل شده‌اند که از نزدیک با هم کار می‌کنند، چرخه حیات مشترک دارند و باید همیشه روی node یکسانی کار کنند. آن‌ها به طور کامل به عنوان یک واحد مدیریت می‌شوند و محیط، volume  و فضای IP خود را به اشتراک می‌گذارند. با توجه به اجرای آن‌ها در یک کانتینر، شما باید پادها را به عنوان یک برنامه یکپارچه در نظر بگیرید تا چگونگی مدیریت مجموعه و منابع و عملکرد pod را به بهترین شکل درک نمایید.

معمولاً podها از یک container اصلی تشکیل می‌شوند که هدف کلی workload و به طور اختیاری برخی از containerهای کمکی را برآورده می‌کند. این‌ها برنامه‌هایی هستند که از اجرا و مدیریت در containerهای خود بهره‌مند می‌شوند، اما کاملاً به برنامه اصلی node متصل هستند. به عنوان مثال، یک pod ممکن است دارای یک container باشد که سرور اصلی برنامه را اجرا می‌کند و دارای یک container کمکی باشد که (وقتی تغییرات در یک مخزن خارجی شناسایی می‌شود) فایل‌ها را به سیستم فایل مشترک منتقل می‌کند. مقیاس بندی افقی به طور کلی در سطح pod تمام نمی‌شود؛ زیرا اشیا سطح بالاتر دیگری نیز وجود دارند که برای انجام این کار مناسب‌ترند.

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