کوبرنتیز به زبان ساده، چرا باید از آن استفاده کنیم؟ – قسمت دوم (پایانی)

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

در این قسمت از مقاله یک نمونه‌ از نحوه‌ی اجرای کوبرنتیز برای یک برنامه‌ی ساده را بررسی خواهیم کرد. با یک مثال عینی از یک میکروسرویس، کد زیر یک Dockerfile ایجاد می‌کند که تصویری با قابلیت اجرای MySQL ایجاد خواهد کرد:

FROM alpine:3.15.4

RUN apk add –no-cache mysql

ENTRYPOINT [“/usr/bin/mysqld”]

این کد را با استفاده از docker می توان ساخت و آن را با استفاده از چیزی مانند docker push  به یک رجیستری OCI یعنی مکانی که می‌توان چنین تصویری را در زمان اجرا توسط یک کانتینر ذخیره و بازیابی کرد می فرستید. برای این مثال، فرض کنید این تصویر را در جایی اجرا می کنیم. همچنین ممکن است بخواهیم یک کانتینر برای مکالمه با این سرویس بسازیم، شاید یک برنامه پایتون داشته باشیم که به عنوان یک کاربر MySQL عمل می‌کند. ممکن است تصویر Docker آن را اینگونه تعریف کنیم:

FROM python:3.7

WORKDIR /myapp

COPY src/requirements.txt ./

RUN pip install -r requirements.txt

COPY src /myapp

CMD [ “python”, “mysql-custom-client.py” ]

حال اگر بخواهیم کلاینت و سرور MySQL را به صورت کانتینر در محیط کوبرنتیز اجرا کنیم، می‌توانیم به راحتی با ایجاد دو Pod این کار را انجام دهیم. هر یک از این Podها ممکن است یکی از کانتینرهای مربوط را اجرا کند مانند:

ما معمولاً قطعه‌ی YAML قبلی را در یک فایل متنی ذخیره می‌کنیم برای مثال: myapp.yaml و آن را با استفاده از ابزار مشتری کوبرنتیز مانند، kubectl create -f my-app.yaml اجرا می‌کنیم. این ابزار به سرور Kubernetes API متصل می‌شود و YAML را برای ذخیره‌سازی منتقل می‌کند. سپس کوبرنتیز به طور خودکار تعاریف دو Pod را که ما در سرور API داریم دریافت می‌کند و اطمینان حاصل می‌کند که در جایی فعال هستند.

بیشتر بخوانید: کوبرنتیز به زبان ساده، چرا باید از آن استفاده کنیم؟ – قسمت اول

این امر بلافاصله اتفاق نمی‌افتد چراکه به گره‌های کلاستر نیاز دارد تا به رویدادهایی که به طور مداوم رخ می‌دهند و به روزرسانی‌هایی که نیاز است از طریق kubelet با سرور API ارتباط برقرار می‌کنند، پاسخ دهند. همچنین این امر مستلزم آن است که تصاویر OCI برای گره‌های کلاستر کوبرنتیز ما وجود داشته و در دسترس باشند. هر چیزی ممکن است در هر زمان اشتباه پیش برود، بنابراین ما به کوبرنتیز به عنوان یک سیستم، در نهایتِ سازگاری اشاره می‌کنیم، که در آن آشتی دادن وضعیت مطلوب در طول زمان فلسفه‌ی طراحی کلیدی است. این مدل سازگاری در مقایسه با یک مدل سازگاری تضمین شده به ما اطمینان می‌دهد که می‌توانیم به طور مستمر در فضای حالت کلی همه‌ی برنامه‌ها در کلاستر خود درخواست تغییرات کنیم و به پلتفرم کوبرنتیز اجازه می‌دهد تا نحوه‌ی به حرکت درآوردن این برنامه‌ها را در طول زمان مشخص کند.

این امر به طور طبیعی در سناریوهای دنیای واقعی مقیاس‌بندی می‌شود. به عنوان مثال، اگر به کوبرنتیز بگویید، «من پنج برنامه را در سه منطقه در یک cloud می‌خواهم»، می‌توان این کار را به طور کامل و با تعریف چند خط YAML با استفاده از برنامه ریزی اولیه کوبرنتیز انجام داد. البته، باید مطمئن شوید که آن سه منطقه واقعاً وجود دارند و برنامه‌ریز شما از آنها آگاه است، اما حتی اگر این کار را انجام نداده‌اید، کوبرنتیز حداقل برخی از بارهای کاری را در مناطق موجود برنامه‌ریزی می‌کند.

به طور خلاصه، کوبرنتیز به شما این امکان را می‌دهد تا وضعیت مورد نظر همه‌ی برنامه‌های موجود در کلاستر خود، نحوه شبکه‌بندی آن‌ها، محل اجرا، فضای ذخیره‌سازی آن‌ها و غیره را تعریف کنید، در حالی می‌توانید که اجرای اساسی این جزئیات را به خود کوبرنتیز واگذار کنید. بنابراین، در سناریوی کوبرنتیزِ تولیدی به ندرت به انجام یک به‌روزرسانی Ansible یا Puppet نیاز پیدا می‌کنید مگر اینکه خود کوبرنتیز را دوباره نصب کنید و حتی پس از آن، ابزارهایی مانند Cluster API وجود دارد که شما را قادر می‌سازند تا کوبرنتیز برای مدیریت کوبرنتیز استفاده کنید.

بیشتر بخوانید: منظور از مشاهده‌پذیری و امنیت کوبرنتیز یا Kubernetes چیست – قسمت اول

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

زمان آن رسیده است که به ویژگی‌های اصلی یک پلتفرم ارکستراسیون کانتینر بپردازیم چراکه اساساً کانتینرها به Pods و Pods به کوبرنتیز نیاز دارند تا:

• یک API خنثی مبتنی بر cloud را برای همه عملکردهای سرور API در معرض دید قرار دهد.
• تمام پلتفرم‌های مبتنی بر cloud و هایپروایزر اصلی در مدیریت کنترلر کوبرنتیز که به عنوان KCM نیز شناخته می‌شود) را ادغام کند.
• برای ذخیره و تعریف وضعیت همه‌ی سرویس‌ها، برنامه‌ها و پیکربندی‌های مرکز داده یا سایر زیرساخت‌های پشتیبانی‌شده کوبرنتیز چارچوبی مقاوم در برابر خطا ارائه کند.
• استقرارها را مدیریت کند و در عین حال از کار افتادگی کاربر، چه برای یک میزبان، سرویس یا برنامه، به حداقل برسد.
• مقیاس‌بندی برای میزبان‌ها و برنامه‌های میزبانی شده با آگاهی به روزرسانی مداوم را خودکار کند.
• ادغام‌های داخلی و خارجی معروف به انواع خدمات ClusterIP، NodePort یا LoadBalancer با تعادل بار را ایجاد کند.
• امکان زمان‌بندی برنامه‌ها برای اجرا بر روی سخت‌افزار مجازی‌شده‌ی خاص، بر اساس ابرداده‌های آن، از طریق برچسب‌گذاری گره و زمان‌بندی کوبرنتیز را فراهم ‌کند.
• یک پلتفرم بسیار در دسترس را از طریق DaemonSets و سایر زیرساخت‌های فناوری ارائه دهد، که کانتینرهایی را که روی همه گره‌های کلاستر اجرا می‌شوند، اولویت بندی می‌کند.
• امکان کشف سرویس از طریق سرویس نام دامنه DNS، را فراهم کند که قبلاً توسط KubeDNS و اخیراً توسط CoreDNS، که با سرور API یکپارچه است، پیاده‌سازی شده است.
• فرآیندهای دسته‌ای معروف به Jobs را اجرا کند که از ذخیره‌سازی و کانتینرها به همان روشی که برنامه‌های کاربردی مداوم اجرا می‌شوند استفاده می‌کند.
• برنامه‌های افزودنی API و ساخت برنامه‌های مبتنی بر API بومی با استفاده از تعاریف منابع سفارشی، بدون ایجاد هرگونه نقشه‌برداری پورت یا لوله‌کشی، را شامل شود.
• بازرسی فرآیندهای ناموفق در سراسر کلاستر از جمله اجرای از راه دور در هر ظرف در هر زمان از طریق kubectl exec و kubectl describe را فعال کند.
• امکان نصب ذخیره‌سازی محلی و/یا از راه دور به یک کانتینر و مدیریت حجم‌های ذخیره‌سازی اعلامی برای کانتینرها با API StorageClass و PersistentVolumes را فراهم کند.

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

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

1. یک گره به صفحه کنترل پاسخ نمی دهد.
2. صفحه کنترل، Podهای در حال اجرا بر روی گره غیر پاسخگو را به گره یا گره‌های دیگر تغییر می‌دهد.
3. هنگامی که یک کاربر از طریق kubectl با سرور API تماس برقرار می‌کند، سرور API با اطلاعات صحیح در مورد گره پاسخگو و مکان جدید Pods پاسخ می‌دهد.
4. همه کلاینت‌هایی که با سرویس Pod ارتباط برقرار می‌کنند به مکان جدید آن هدایت می‌شوند.
5. حجم‌های ذخیره‌سازی متصل به Podها در گره خراب به مکان Pod جدید منتقل می‌شوند تا داده‌های قدیمی آن همچنان قابل خواندن باشند.

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

اجرای کوبرنتیز در بالای سیستم عامل‌های تغییرناپذیر طبیعی است شما یک سیستم عامل پایه دارید که تنها زمانی به روزرسانی می‌شود که کل سیستم عامل را به روز کنید و بنابراین تغییر ناپذیر است)؛ و شما Nodes/Kubernetes خود را با استفاده از آن سیستم عامل نصب می‌کنید. اجرای یک سیستم عامل تغییرناپذیر مزایای زیادی خواهد داشت. شما می‌توانید کوبرنتیز را در فضای مبتنی برcloud ، روی سرورهای bare metal و یا حتی روی Raspberry Pi اجرا کنید.

دستگاه‌های (IBM حتی از کلاسترهای در حال اجرا بر روی فریم‌های اصلی نسل بعدی خود، یعنی PowerPC ها نیز پشتیبانی می‌کند. همانطور که اکوسیستم بومی cloud در اطراف کوبرنتیز به رشد خود ادامه می‌دهد، سازمان‌ها را قادر می‌سازد تا بهترین شیوه‌ها را شناسایی کرده، و به طور فعال تغییراتی را برای جلوگیری از مشکلات ایجاد کنند و سازگاری محیط را حفظ کنند تا از جابجایی جلوگیری شود؛ در این جریان‌ها  و جابجایی‌ها برخی از ماشین‌ها کمی متفاوت از سایرین رفتار می‌کنند چراکه پچ‌ها از قلم افتاده، اعمال نشده و یا به طور نادرست اعمال شده اند.

کوبرنتیز با هوشمندی و امکانات فراوان خود، به سازمان ها این اجازه را می‌دهد تا به طور همزمان و بهینه‌تر نرم‌افزارهای خود را در سرتاسر شبکه مدیریت کنند. با استفاده از مفهوم کانتینرها و اتوماسیون، شما می‌توانید روند نصب، راه‌اندازی و مدیریت سرورهای خود را به شکل ساده‌تر و سریع‌تری انجام دهید. در تاریخ 18 مهرماه 1402 شرکت APK در راستای آشنایی بیشتر با کوبرنتیز اقدام به برگزاری کارگاهی با موضوع “کارگاه آشنایی با مسیر مهاجرت به کوبرنتیس و داکر” کرد. علاقمندان در صورت علاقه به دریافت فایل تصویری این ورکشاب می توانند ار طریق شماره 58274000-021 با همکاران ما تماس بگیرید.

مقاله های مرتبط: