بالاخره رسیدیم به حضرت کوبرنتیز 😎 اما قبلش اول یه مروری بکنیم که تا الان چه پست‌هایی داشتیم و بعدش از مرور مفاهیم کانتینر و تاریخچه کوبر شروع می‌کنیم و قدم به قدم با هم پیش میریم.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
کانتینر رو به نوعی میتونیم بگیم یه فرم مجازی‌سازی در سطح سیستم‌عامل گفت، از یه کانتینر میتونیم برای ران کردن برنامه‌های مختلف از یک میکروسرویس کوچیک تا پروسه‌های یه اپلیکیشن بزرگ، استفاده کرد.
داخل یک کانتینر تمام کدهای باینری، کتابخانه‌ها و فایل‌های کانفیگ و برنامه‌های اجرایی مورد نیاز اون پروسه وجود دارند، بنابراین کانتینر رو میتونیم هرجایی بالا بیاریم و مثل قبل برامون کار کنه.
نسبت به روش‌های دیگه مثل ماشین مجازی و سرور و ... کانتینرها سبک‌ترند و راحت‌تر و با overhead کمتری میشه اونا رو جابجا کرد. توی پست‌های داکر در مورد کانتینرها و مقایسه اونها با جزئیات بیشتری توضیح دادیم که میتونید برگردید مطالعه کنید.
حالا تا وقتی‌که توی یک سرور هستیم با داکر و داکر کامپوز میتونیم به راحتی کانتینرهامون رو مدیریت کنیم ولی اگه ابعاد از چند تا سرور بیشتر بشه دیگه نیاز داریم که از ابزارهای ارکستریشن استفاده کنیم برای مدیریت کانتینرامون که مثل رهبر ارکستر بیایستن بالاسر سیستم ما تا صدای ساز کانتینرامون رو به خوبی بشنویم 🙃
ابزارهای ارکستریشن، ابزارهایی برای automated configuration, management, coordination اپلیکیشن‌ها و سرویس‌ها و سیستم‌های کامپیوتری هستن. توی دنیای IT اونا به ما کمک میکنن تا تسک‌ها و ورک‌فلوهای پیچیده رو به آسانی مدیریت کنیم.
با اینکه این مقایسه به نوعی اشتباهه اما خیلی جاها می‌بینیم که این دوتا ابزار رو با هم مقایسه میکنن. چرا میگم این مقایسه اشتباهه؟! چونکه داکر یک پلتفرمی است که به با استفاده از یه Container Runtime به ما امکان این رو میده که لینوکس کانتینرها رو داشته باشیم. ولی کوبرنتیز ابزار Orchestration هست کار مدیریت رو انجام میده حتی میتونیم کانتینرهای خود داکر رو با استفاده از کوبرنتیز مدیریت کنیم.
در واقع داکر میتونه اپلیکیشن‌های کانتینری رو روی یک نود به صورت پکیج شده نگهداری کنه در حالی که کوبرنتیز برای مدیریت کلاسترهای چند نوده طراحی شده. بنابراین اگر هم ما بخوایم کوبرنتیز و داکر رو مقایسه کنیم بهتره که کوبرنتیز رو با داکر سوآرم که ارکستریتور داکر هست، مقایسه کنیم که در ادامه میریم سراغش!
اگه بخوایم خلاصه طور روند پیشرفت نگهداری اپلیکیشن‌ها رو یه بررسی بکنیم، مرحله اول به این صورت بود که روی همون سیستم‌عامل شروع می‌کردیم به نصب کردن فریم‌ورک‌ها و لایبرری‌های مورد نیاز و توسعه اپلیکیشن و نهایتا اپلیکیشن‌مون در قالب یک سرویس روی سرور بالا می‌آوردیم.
مرحله دوم به این صورت هست که مستقیم روی سخت افزار یا روی سیستم‌عامل یک هایپروایزر نصب می‌کنیم که با استفاده از اون میتونیم مجازی سازی رو در سطح hardware انجام بدیم و منابع‌مون رو به صورت ایزوله شده و محدود به ماشین‌های مجازی مختلف اختصاص بدیم و روی اون VM ها حالا اپلیکیشن خودمون رو راه‌اندازی کنیم. این همون مجازی‌سازی مرسوم است که خیلی پر استفاده و کاربردی می‌باشد.
در مرحله سوم با استفاده از ابزاری مثل داکر میاییم کرنل رو به اشتراک میذاریم اما در سطح پروسه‌های سیستم عامل مجازی‌سازی رو انجام میدیم و منابع رو به صورت ایزوله‌شده و مدیریت شده در اختیار کانتینرها میذاریم و سرویس‌هامون رو با کانتینرها بالا میاریم.
و حالا در مرحله چهارم این مسیر تکاملی مدیریت کانتینر هامون رو هم به یک ابزار کاربلد ارکستریشن میسپاریم تا بتونیم راحت‌تر اسکیل کنیم و ابعاد بزرگ رو مدیریت کنیم.
داکر سوآرم در واقع یه گروهی از چنتا سرور فیزیکی یا ماشین‌مجازی هست که داکر روی اونها نصب شده و کانفیگ‌شون کردیم تا با هم کلاستر بشن و مدیریت این کلاستر رو ارکستریشن داکر یعنی سوآرم انجام میده.
بنابراین سوآرم به کانتینرها این امکان رو میده که روی کلاستری شامل چندین هاست بالا بیان و کار کنند و باهم ارتباط داشته باشند. این ارتباط رو خود ارکستریشن ایجاد میکنه.
به طور کلی سوآرم خیلی ساده‌تره از کوبرنتیز اما این سادگی در مقابل دست مارو هم میبنده خیلی جاها.
مثلا سوآرم به ما قابلیت Auto Scaling نمیده در حالیکه کوبر این امکان رو بهمون میده. سوآرم کامیونیتی خوبی داره اما کامیونیتی کوبر بسیار بزرگ و فعاله. سوآرم محدود به قابلیت‌های api داکر هست در حالیکه توی کوبر خیلی بیشتر دستمون باز هست اما در مقابلش هم راه اندازی سوآرم به آسونی چنتا دونه کامند ساده هست ولی کوبرنتیز یه مقداری مشکله راه‌اندازیش. راه‌اندازی کوبرنتیز پیچیده‌تر هست اما در کنارش اونقدر ابزار توسعه پیدا کرده که این کار رو برای ما خیلی ساده و روان کرده.
به نظرم برای سایزهای کوچیک سوآرم بعضا انتخاب مناسب‌تری هست از کوبرنتیز حتی ... گاهی وقتا موقعی‌که به شرکتا این پیشنهاد رو میدم برداشت اشتباه میکنن، میگن مثلا طرف کوبرنتیز بلد نیست که میگه سوآرم و ... ولی واقعیتش اینه که توی یه اسکیل‌های کوچیکی اصرار به داشتن کوبرنتیز اشتباهه. دیدم آدمایی رو که به زور واسه دوتا سرویس کوچیک کلاستر کوبر ستاپ کردن و با اون کلاسترشون پدر خودشون و شرکت و همه رو با هم در آوردن 😬 هر چیزی در جای خودش درسته. به نظر من اگر شما تیم نگهداری و پایش کلاستر ندارید و تعداد تغییراتتون کمه و قابلیت‌های زیادی هم از ارکستریشن توقع ندارید سوارم راه حل منطقی برای شما هست. اما اگر یکی از این موارد نقض بشه دیگه سوارم نمی‌تونه جواب نیازمندی شما رو بده.
ابزار کمپانی hashicorp برای ارکستریشن یعنی Nomad یک ابزار ساده و منعطف برای ارکستریشن ورکلودهای مختلف هست. مزیت رقابتی که این ابزار نسبت به کوبرنتیز داره این هست که میتونه به صورت Automated لایف سایکل اپلیکیشن‌های کانتینری و همچنین غیرکانتینری رو مدیریت کنه. به طورکلی اخلاق هشی‌کورپ این مدلیه که میره یه جایی از مارکت رو سعی میکنه پوشش بده که کمتر رفتن سمتش. مثلا با Nomad میشه یه اسکریپ بش رو هم توی کلاستر مدیریت کرد و لزومی نداره حتما کانتینری باشه.
از طرفی طراحی Nomad به شکلی هست که از اول برای هندل کردن پیاده سازی‌های مالتی دیتاسنتر و یا حالا برای اونایی که به کلادهای درست حسابی دسترسی دارن مالتی region، طراحی شده.
کوبرنتیز به لحاظ کامیونیتی بسیار فعال‌تر هست و ساپورتی که از کامیونیتی میگیرید قابل مقایسه با Nomad نیست از طرفی Nomad استفاده و یادگیریش ساده تر هست. به طورکلی Nomad سعی کرده برای اسکیل‌های خیلی بزرگ کارآمد باشه در عین رعایت کردن سادگی. اما کوبرنتز با اینکه پیچیده تر هست اما دستمون هم توش بیشتر باز هست و کامیونیتی قوی‌تری هم داره. توی Nomad هم با کانتینرهای لینوکسی و هم ویندوزی میتونیم کار کنیم و نسبت به کوبرنتیز کمتر درگیر کانفیگ‌های متعدد میشیم و کمتر با چالش‌های نتورکی مواجه هستیم.
اما اینکه آیا این مزیت رقابتی Nomad باعث میشه که در آینده بتونه مارکت رو بکشونه سمت خودش ... سوالیه که باید منتظر جوابش بمونیم ولی حداقل فعلا که کوبرنتیز تو کار خودش یکه‌تاز هست.
پلتفرم متن‌باز RedHat برای منیج، دیپلوی و توسعه اپلیکیشن‌های کانتینری OpenShift هست. اوپن‌شیفت میتونه یه IDE در اختیار دولوپر بذاره که اپلیکیشنش رو توسعه بده و دیپلوی کنه و مدیریتش روی کلاستر کوبر رو اوپن شیفت انجام بده.
شاید مثلا توی مواردی مثل اینتگریت شدن با یه سری ابزارهای جانبی اوپن‌شیفت بهتر باشه اما من میگم موقع کار با اوپن‌شیفت هم اول آخرش باید کوبرنتیز رو بلد باشی، پس دیگه این واسطه رو میشه برداشت و مستقیم رفت سراغ کار کردن با خود کوبرنتیز، اینجوری overhead یادگرفتن یه ابزار دیگه هم کم میشه و میتونی تمرکز بیشتری رو روی کار خودت و نگهداری کلاسترت بذاری.
یه نکته‌ی دیگه‌ای هم که در مورد اپن‌شیفت دارم اینه که به صورت رایگان وقتی داری ازش استفاده می‌کنی یه مشکلاتی باهاش مواجه می‌شی که خیلی راه حل درست و منطقی براش پیدا نمی‌کنی و باید کلی بگردی و خودت به خوبی پیداشون کنی. بیشتر این موارد تو ساپورت داره حل میشه که خود ردهت داره ازش درآمد کسب میکنه و به همین راحتی نمی‌تونی بهش برسی. من پروژه‌های زیادی دیدم که رفتن سمت کوبرنتیز و مجبور شدن که اپن‌شیفت خودشون رو تغییر بدن.
خیله خب دیگه از مقایسه‌ها بگذریم و بریم سراغ خود جناب کوبرنتیز 😎
کوبرنتیز یک پلتفرم متن‌باز برای مدیریت سرویس‌ها و ورکلودهای کانتینری هست که کانفیگوریشن و اتومیشن رو به صورت توصیفی ساده سازی کرده و کامیونیتی و بزرگ و درحال رشدی هم داره.
طبق این مقاله از سایت کوبرنتیز، تجربه بیش از یک دهه نگهداری سرویس‌های کانتینری در گوگل توی پروژه‌های مختلف، در قالب پروژه Borg متن باز شده که کوبرنتیز هم مسیر همون پروژه رو داره ادامه میده و بسیاری از توسعه‌دهندگان کوبرنتیز افرادی هستن که قبلا روی بورگ کار میکردن.
توصیه میکنم قسمت اول و قسمت دوم مستند کوبرنتیز که هم‌روش زحمت زیرنویسش رو کشیده حتما ببینید، خیلی جالبه که ببینیم غول‌های تکنولوژی برای موندن توی مارکت گاها چه تصمیماتی می‌گیرن.
اسم kubernetes یکم طولانی هست ازونجایی که هشت حرف بین k , s قراره داره بهش K8S هم میگن! و این ابزار ارکستریشن امروزه تبدیل شده به یکی از محبوب‌ترین ابزارهایی که سازمان‌های مختلفی دارن سمتش میرن و به اینکه مهاجرت کنن روی کوبر تا از امکانات بهره‌مند بشن، جدی‌تر و بیشتر فکر میکنن.
توی مسیری که داریم با هم پیش میریم متوجه شدیم که کانتینرها راه‌حل خوبی برای اجرای اپلیکیشن‌ها توی محیط‌های پروداکشنی هستن، بنابراین ما نیاز داریم که بتونیم کانتینرهارو مدیریت کنیم و مطمئن بشیم که سرویس‌هامون پایدار هستن و اصطلاحا down time نداشته باشیم.
کوبرنتیز با امکاناتی از قبیل مواردیکه در ادامه براتون لیست میکنم رو در اختیار ما میذاره تا بتونیم با استفاده از اونها کانتینرهامون رو مدیریت کنیم و توی اسکیل‌های بزرگ حتی بتونیم سرویس‌های پایداری رو داشته باشیم.
تصور کنید ابزاری در اختیار دارید که شما براش توضیح می‌دید و می‌گید مثلا از این ایجنت مانیتورینگ من توی هر سرورم یه دونه بیار بالا، از سرویس فرانت‌اند سایتم مثلا میخوام چهارتا دونه بالا باشه که هرکدومش حداقل فلان میزان cpu و فلان میزان ram رو باید داشته باشند و حتی بهش می‌گید که حواست باشه که از مصرف کانتینرهای این سرویس من بالا رفت مثلا اگه ۸۰ درصد ram شون زیرلود پر شد اونوقت تو شروع کن و خودت تعداد اونها ببر بالا مثلا تا سقف ۴۰ تا دونه!!! و بعدش که لود کمتر شد دوباره خودت این تعداد رو کم کن ولی دیگه از سه تا کمتر نشه و همیشه حداقل سه تا بالا باشه.
یا مثلا میخوایم آپدیت انجام بدیم من بهت میگم که مثلا دوتا دوتا از کانتینرهای سرویس قبلی بیار پایین و دوتا ازین نسخه جدید جایگزینش کن، یا نه اصلا اگه الان پنجاه تا دونه از نسخه قبلی بالا هست اشکالی نداره من منابع کافی در اختیارت میذارم تو پنجاه تا هم از نسخه جدید اول بیار بالا من تست بگیرم مطمئن که شدم بعد کلا لود مشتری رو جابجا کن روی این نسخه جدید ...
میبینید؟ اگه تجربه نگهداری سرویس‌های یه مقدار بزرگ توی پروداکشن رو داشته باشید متوجه میشید که اینا کارای بزرگی هستن و ابزاری که این توانایی هارو به ما بده، ابزار ارزشمندیه. کم‌کم داره معلوم میشه چرا کوبر سروصدا کرده :)
طبق گزارش‌هایی که داده شده درصد زیادی از کمپانی‌هایی که سرویس‌های کانتینری نگهداری میکنن توی محیط پروداکشن‌شون هم از کوبرنتیز استفاده می‌کنند.
سه تا مدرک هست که برای کوبرنتیز هستن و مدارک معتبری هستن که CNCF با همکاری Linux Foundation اونها رو بعد از آزمون‌هایی که میگیره به افراد میده، به نام های CKAD, CKA, CKS که در ادامه بررسی‌شون می‌کنیم. دوتا مدرک دیگه هم هست KCNA و KCSA که اونا رو هم توضیح میدم. کوبرنتیز ابزار بسیار بزرگی هست که از زوایای مختلف میشه به اون نگاه کرد که این موضوع به خوبی تو مدرک‌های کوبرنتیز قابل مشاهده است.
هدف این مدرک ارزیابی توانایی‌های ادمین کلاستر کوبر هست که در قالب یک آزمون عملی انجام میشه و این مدرک برای افرادی هست که نگهداری کلاستر رو انجام میدن. این نگاه سمت administration خود کوبرنتیز است.
هدف این مدرک ارزیابی توانایی های افراد برای استفاده از کوبرنتیز برای build و مانیتور و Tshoot اپلیکیشن‌هایی که توسعه میده هست و مناسب افرادی هست که از ساید توسعه‌دهنده ها هستن اما اپلیکیشن اونا قراره روی کوبر مستقر بشه. اینجا نگاه سمت استفاده کننده کوبرنتیز است. یعنی شما به نگهداری کلاستر کاری ندارید و به عنوان مشتری دارید از خود کوبرنتیز استفاده می‌کنید.
افرادی که بخوان این مدرک رو بگیرن ابتدا باید CKA رو داشته باشند و بعد از اون میتونن سراغ این مدرک بیان که بیشتر هدفش تمرکز روی بست‌پرکتیس ها و امن کردن کانتینرها هست و دانش امنیتی افراد رو میسنجه. این نگاه برای افزایش امنیت در استفاده از کوبرنتیز است.
این هم یک مدرک دیگه هست برای افرادیکه کمتر حرفه‌ای هستن که آشنایی اولیه با محیط‌های کلاد نیتیو و اکوسیستم ابری رو میسنجه و آشنایی اولیه با کوبرنتیز که میتونی به نوعی برای آمادگی قبل از سه مدرک دیگه ازش استفاده بشه.
این هم مثل قبلیه اما واسه سکیوریتی !
به کسی هم که هر پنج مدرک رو با هم میگیره اصطلاحا Kubestronaut میگن که اینجا میتونید بیشتر در موردش بخونید.
ما تو ایران هستیم نمی‌تونیم این مدرک‌های رو بگیریم و اونا ما رو تحریم کردن و بهمون نمی‌دن. البته ایرانی‌ها می‌تونند بگیرن ولی اینکه تو کشور ایران هستیم نمی‌شه. دیدم که بعضی‌ها با مسافرت تونستن بگیرن ولی نرمالی اگر فقط سفر کردی نرمالی بهت نمی‌دن. برای امتحانش هم یه نفر آنلاین میشه و بررسی میکنه که چیت نکنی و درست امتحان بدی. کلا مدرک‌های معتبری هست که توصیه میکنم اگر امکانش رو داشتید حتما براش اغدام کنید. سایت‌های زیادی هستن که کمکتون می‌کنند که این مدرک‌ها رو بتویند به خوبی بگیرید که این سایت یکی از بهترین‌ها هست و میتونید ازش استفاده کنید.
بسیار خب این میشه قدم اول‌مون در مسیر کوبرنتیز، تو پست‌های بعدی میریم به سراغ این ابزار و بیشتر باهاش آشنا میشیم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
