فصل سوم کتاب kubernetes in action: پاد چیست؟ اجرای کانتینر در کوبرنتیز

پادها: اجرای کانتینرها در کوبرنتیز

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

نکات کلیدی این فصل:

1. ایجاد، اجرا و توقف پادها: پادها، پایه اصلی اجرای کانتینرها توی کوبرنتیز هستن. این بخش بهت نشون میده چجوری با پادها کار کنی.
2. برچسب‌گذاری (Labels): یه روش ساده برای دسته‌بندی و مدیریت پادها و سایر منابعه که می‌تونی به منابع برچسب بزنی و راحت‌تر مدیریت کنی.
3. مدیریت گروهی با Label: فرض کن می‌خوای چند پاد که یه label مشترک دارن رو مدیریت کنی. اینجا یاد می‌گیری چطوری این کارو راحت انجام بدی، مثلاً حذف یا آپدیت همه پادهای یه دسته مشخص.
4. ‏Namespaces: برای اینکه منابع رو به تیم‌های مختلف یا پروژه‌های جداگانه تقسیم کنی از Namespaces استفاده می‌کنی. با این کار منابع هر گروه جدا از بقیه هستن.
5. زمان‌بندی پادها: این بخش بهت یاد می‌ده چطور پادها رو روی نودهای مختلف قرار بدی، مثلاً با توجه به نیازمندی‌های خاص مثل CPU یا حافظه.

معرفی پادها (Pods)

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

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

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

چرا به پادها نیاز داریم؟

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

استفاده از چند کانتینر به جای اجرای چند فرآیند در یک کانتینرفرض کنید یک اپلیکیشن دارید که شامل چندین فرآیند مختلفه. این فرآیندها باید از طریق ارتباط بین‌فرآیندی (IPC) یا فایل‌های محلی با هم ارتباط برقرار کنند. اگه همه این فرآیندها رو در یک کانتینر قرار بدید، مشکلاتی مثل مدیریت لاگ‌ها و نگهداری هر فرآیند به وجود میاد. پس بهتره هر فرآیند رو در کانتینر جداگانه‌ای اجرا کنید.

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

به این ترتیب، پادها باعث می‌شن تا هم از مزایای ایزوله بودن کانتینرها استفاده کنیم و هم فرآیندهایی که نیاز به همکاری دارن رو به‌راحتی مدیریت کنیم.

درک ایزولاسیون نسبی بین کانتینرهای یک پاد

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

اشتراک منابع بین کانتینرهای یک پاد:

1. شبکه مشترک: تمام کانتینرهای یک پاد از یک فضای شبکه مشترک استفاده می‌کنند. یعنی همه آن‌ها آدرس IP یکسانی دارند و از یک پورت مشترک استفاده می‌کنند. بنابراین، کانتینرها در یک پاد می‌توانند از طریق localhost با یکدیگر ارتباط برقرار کنند.
2. اشتراک نام میزبان (Hostname): کانتینرهای یک پاد یک نام میزبان (hostname) مشترک دارند و به همین دلیل از دید شبکه شبیه به یک سیستم واحد به نظر می‌آیند.
3. اشتراک فضای نام IPC: کانتینرهای یک پاد می‌توانند از IPC (ارتباط بین فرآیندها) برای ارتباط بین فرآیندهای مختلف استفاده کنند، به دلیل اینکه فضای نام IPC آن‌ها مشترک است.

تفاوت در سیستم فایل:هر کانتینر به‌طور پیش‌فرض سیستم فایل خودش را دارد که از تصویر (image) مربوط به آن کانتینر ساخته شده است. اما اگر بخواهید فایل‌ها یا دایرکتوری‌هایی را بین کانتینرها به اشتراک بگذارید، باید از قابلیت Volumes کوبرنتیز استفاده کنید.

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

درک نحوه اشتراک‌گذاری آدرس IP و فضای پورت‌ها در کانتینرها

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

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

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

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

معرفی شبکه تخت (Flat Inter-Pod Network)

در کوبرنتیز، پادها (Pods) در یک فضای آدرس شبکه‌ی تخت و مشترک قرار می‌گیرند که به این معنی است که هر پاد می‌تواند به‌راحتی و بدون نیاز به مکانیزم‌های پیچیده‌ای مانند ترجمه آدرس شبکه (NAT)، از طریق آدرس IP با سایر پادها ارتباط برقرار کند. هیچ NAT یا دروازه‌ای بین پادها وجود ندارد و بنابراین، هر زمان که پادها بسته‌های شبکه را ارسال می‌کنند، آدرس IP واقعی پاد دیگر به‌عنوان مبدا در بسته‌های شبکه ظاهر می‌شود.

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

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

سازمان‌دهی کانتینرها در پادها

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

مثالی ساده: فرض کنید یه اپلیکیشن چندلایه داریم که از دو بخش تشکیل شده؛ یه بخش frontend که مربوط به سرور برنامه است و یه بخش backend که دیتابیس رو اجرا می‌کنه. توی این حالت، بهترین کار اینه که این دوتا رو به‌صورت پادهای جداگانه پیکربندی کنید. چرا؟ چون هر بخش عملکرد و منابع خودش رو نیاز داره و معمولاً باید به‌صورت مستقل مقیاس‌پذیر باشن. مثلا frontend شاید نیاز داشته باشه به تعداد زیادی نسخه اجرا بشه تا جوابگوی کاربران باشه، اما backend همچین نیازی نداره و به این راحتی‌ها هم مقیاس‌پذیر نیست.

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

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

تقسیم اپلیکیشن‌های چند لایه به چندین پاد

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

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

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

استفاده چند تا کانتینر توی یه Pod

برای استفاده از چندین کانتینر در یک پاد (Pod) در کوبرنتیز، معمولاً زمانی از این روش استفاده می‌کنید که اپلیکیشن شما شامل یک فرآیند اصلی و چند فرآیند تکمیلی باشد. برای مثال، اگر کانتینر اصلی شما یک وب سرور است که اپلیکیشن شما را اجرا می‌کند، ممکن است یک کانتینر جانبی (Sidecar Container) وظایف تکمیلی مانند دریافت داده‌ها، ثبت و نگهداری لاگ‌ها، یا مدیریت درخواست‌ها را بر عهده بگیرد.

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

مثال کاربردی:تصور کنید یک وب‌سرور (کانتینر اصلی) دارید که فایل‌های استاتیک را از یک دایرکتوری سرویس می‌دهد. در کنار آن، یک کانتینر جانبی دارید که به صورت دوره‌ای فایل‌های جدید را از یک منبع خارجی دانلود کرده و در دایرکتوری مربوطه ذخیره می‌کند. این مدل، ترکیبی از کانتینرهای مرتبط را در یک پاد فراهم می‌کند که به بهبود کارایی و مدیریت اپلیکیشن کمک می‌کند، بدون اینکه همه عملکردها را در یک کانتینر واحد ادغام کنید.

مثال‌های دیگر:

• Log Rotation: یک کانتینر جانبی که مسئول چرخش و مدیریت لاگ‌ها است.
• Data Collector: کانتینری که داده‌های برنامه اصلی را پردازش کرده و آن‌ها را برای تحلیل ارسال می‌کند.

این کانتینرهای جانبی (Sidecar Containers) به افزایش قابلیت مدیریت و بهینه‌سازی عملکرد اپلیکیشن‌ها کمک می‌کنند.

برای تصمیم‌گیری در مورد اینکه چه زمانی باید چندین کانتینر را در یک پاد قرار دهید

وقتی می‌خوای تصمیم بگیری که چند تا کانتینر رو توی یک پاد قرار بدی یا جداگانه اجرا کنی، باید چند تا سوال مهم از خودت بپرسی:

1. آیا باید حتماً با هم اجرا بشن؟اگه کانتینرها نیاز دارن که کنار هم اجرا بشن و به منابع مشترکی دسترسی داشته باشن (مثلاً کانتینر اصلی و کانتینر جانبی که بهش کمک می‌کنه)، بهتره که توی یک پاد باشن. ولی اگه مستقل هستن و نیازی به اجرا در کنار هم ندارن، بهتره جدا باشن.
2. بخشی از یک اپلیکیشن هستن یا اجزای مستقل؟اگه کانتینرها بخشی از یک سیستم بزرگ‌تر باشن و به هم وابسته باشن (مثلاً یکی برای سرویس‌دهی و یکی برای جمع‌آوری لاگ‌ها)، منطقیه که توی یک پاد قرار بگیرن. ولی اگه هیچ وابستگی خاصی بینشون نیست، می‌تونی اون‌ها رو جداگانه اجرا کنی.
3. آیا باید با هم مقیاس‌پذیر بشن؟اگه یکی از کانتینرها نیاز به مقیاس بیشتری نسبت به دیگری داره (مثلاً توی وب سرورهایی که نیاز به مقیاس بیشتری نسبت به دیتابیس دارن)، بهتره که هر کدوم رو توی یک پاد جداگانه قرار بدی. چون کوبرنتیز برای مقیاس‌پذیری، سطح پاد رو مقیاس می‌کنه نه کانتینر رو.

در کل، تا وقتی که دلیل خیلی قوی نداری که کانتینرها رو توی یک پاد بذاری، بهتره جدا اجراشون کنی.

ساخت pod

برای ساخت پاد در کوبرنتیز، معمولاً از فایل‌های YAML یا JSON استفاده می‌شه. این فایل‌ها به API کوبرنتیز فرستاده می‌شن تا منابع مختلف مثل پاد، سرویس، یا سایر اجزا رو تعریف کنن. شاید اوایل این فایل‌ها پیچیده به نظر برسن، ولی نگران نباش. با یاد گرفتن چند اصل و ساختار، می‌بینی که نوشتن این فایل‌ها کار راحت‌تری می‌شه.

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

1. نسخه API و نوع منبع: تو این بخش، نسخه API کوبرنتیز و نوع منبع (مثلاً پاد) رو مشخص می‌کنی.
2. متادیتا Metadata: توی این قسمت، اطلاعاتی مثل اسم پاد، namespace (فضای نام) و برچسب‌ها (labels) ذخیره می‌شه. این برچسب‌ها برای دسته‌بندی و مدیریت راحت‌تر پادها استفاده می‌شن.
3. مشخصات Spec: این بخش مهم‌ترین قسمت فایله، چون توی اینجا تعریف می‌کنی که چه کانتینری باید اجرا بشه، منابعی مثل CPU و حافظه چطور مدیریت بشن و چه پورت‌هایی باز بشن.
4. وضعیت Status: این بخش فقط خواندنیه و وضعیت لحظه‌ای پاد رو نشون می‌ده. نیازی به تعریف این بخش نداری، چون کوبرنتیز خودش خودکار این قسمت رو تکمیل می‌کنه.

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

ایجاد yaml ساده برای Pod

خب، بریم سراغ ایجاد یک پاد با یه فایل YAML ساده. این فایل به نام kubia-manual.yaml ذخیره می‌شه و در واقع مشخصات پاد رو به‌صورت خیلی مختصر و مفید توضیح می‌ده. ساختار کلی فایل این شکلیه:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual
spec:
  containers:
  - image: h0x3ein/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

توضیحات:

• ‏ apiVersion: v1: اینجا مشخص می‌کنیم که از نسخه v1 API کوبرنتیز استفاده می‌کنیم.
• ‏kind: Pod: این قسمت می‌گه که نوع منبع، پاده.
• ‏metadata: اینجا اطلاعاتی مثل اسم پاد رو تعریف می‌کنیم. در اینجا اسمش "kubia-manual" هست.
• ‏spec: این بخش مهم‌ترین قسمته که توش مشخصات پاد رو می‌ذاریم.containers: لیستی از کانتینرهایی که داخل پاد اجرا می‌شن. اینجا فقط یه کانتینر داریم به اسم "kubia".
• ‏image: این هم تصویر کانتینریه که از luksa/kubia استفاده می‌کنه.
• ‏ports: تو این بخش مشخص می‌کنیم که کانتینر روی چه پورتی گوش می‌ده. اینجا پورت 8080 با پروتکل TCP تعریف شده.

این فایل خیلی ساده و قابل فهمه و می‌تونی ازش برای پادهای دیگه هم استفاده کنی. فقط کافیه تنظیمات مربوط به کانتینرها یا پورت‌ها رو به نیاز خودت تغییر بدی.

نکته درباره پورت‌ها:

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

دستور kubectl explain

دستور kubectl explain یه ابزار عالی برای کشف فیلدهای ممکن در API اشیاء کوبرنتیزه. به جای اینکه وقتت رو صرف گشتن توی مستندات مرجع کنی، این دستور بهت اجازه می‌ده تا به سرعت ببینی هر شیء چه ویژگی‌ها و فیلدهایی رو پشتیبانی می‌کنه.

مثلاً فرض کن می‌خوای یه مانفیست برای پاد بنویسی و نمی‌دونی دقیقاً چه فیلدهایی باید استفاده کنی. کافیه این دستور رو وارد کنی:

kubectl explain pods

اینجا بهت لیست کلی فیلدهایی که مربوط به یک پاد هست رو نشون می‌ده. اما می‌تونی بیشتر بری تو عمق و درباره یک فیلد خاص هم اطلاعات بگیری. مثلاً بخش spec که تنظیمات اصلی مثل کانتینرها و منابع رو شامل می‌شه:

kubectl explain pods.spec

اینطوری می‌تونی بفهمی چه چیزایی توی بخش spec تعریف می‌شن، مثل لیست کانتینرها، حجم‌ها (Volumes)، و چیزای دیگه.

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

استفاده از kubectl برای اجرای Pods

برای ساخت یک پاد از فایل YAML، شما باید از دستور kubectl create استفاده کنید که فایل YAML شما رو به کوبرنتیز می‌فرسته تا منابع مورد نظر ایجاد بشن. فرض کنیم شما یه فایلی به اسم kubia-manual.yaml دارید که توش پاد تعریف شده. با اجرای دستور زیر، پاد ایجاد می‌شه:

kubectl create -f kubia-manual.yaml

نتیجه این دستور چیزی شبیه به این خواهد بود:

pod &quotkubia-manual&quot created

دستور kubectl create -f فقط برای پادها نیست؛ شما می‌تونید باهاش هر منبع دیگه‌ای هم که با YAML یا JSON تعریف شده رو بسازید. بعد از اینکه پاد ایجاد شد، می‌تونید با استفاده از این دستور، جزئیات کامل اون رو به صورت YAML ببینید:

kubectl get po kubia-manual -o yaml

اگر فرمت JSON رو ترجیح می‌دید، می‌تونید به جای YAML از JSON استفاده کنید:

kubectl get po kubia-manual -o json

برای اینکه ببینید پادتون در چه وضعیتی قرار داره، می‌تونید دستور زیر رو اجرا کنید تا لیستی از پادها با وضعیت فعلی‌شون ببینید:

kubectl get pods

این خروجی چیزی شبیه به این خواهد بود:

NAME            READY   STATUS    RESTARTS   AGE
kubia-manual    1/1     Running   0          32s
kubia-zxzij     1/1     Running   0          1d

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

مشاهده لاگ های pod

برای مشاهده لاگ‌های اپلیکیشن در یک پاد کوبرنتیز، راهکار ساده‌ای وجود دارد. به‌طور معمول، اپلیکیشن‌های کانتینری لاگ‌ها را به جریان‌های استاندارد خروجی (stdout) و خطای استاندارد (stderr) ارسال می‌کنند، به جای اینکه لاگ‌ها را به فایل‌ها بنویسند. این رویکرد به کاربران امکان می‌دهد تا به‌راحتی لاگ‌های اپلیکیشن‌های مختلف را مشاهده کنند.

اگر از داکر استفاده می‌کنید، معمولاً می‌توانید با دستور زیر لاگ‌های کانتینر را مشاهده کنید:

$ docker logs <container-id>

با این حال، در کوبرنتیز نیازی نیست به سروری که پاد روی آن اجرا می‌شود SSH کنید. کوبرنتیز یک راه ساده‌تر فراهم کرده است.

مشاهده لاگ‌های پاد با kubectl

برای دیدن لاگ‌های اپلیکیشن در یک پاد کوبرنتیز، نیازی نیست مستقیماً به سرور SSH کنید. خوشبختانه کوبرنتیز با دستور ساده‌ای این کار را برایتان راحت کرده. معمولاً اپلیکیشن‌های کانتینری لاگ‌ها را به خروجی استاندارد (stdout) یا خطای استاندارد (stderr) می‌فرستند تا مدیریت لاگ‌ها ساده‌تر بشه.

برای مثال، اگر از داکر استفاده می‌کردید، می‌تونستید با دستور زیر لاگ‌های یک کانتینر رو ببینید:

docker logs <container-id>

اما در کوبرنتیز، با دستور kubectl logs می‌تونید مستقیم لاگ‌های کانتینر رو از طریق کوبرنتیز ببینید، بدون نیاز به دسترسی SSH. برای این کار کافیه دستور زیر رو اجرا کنید:

kubectl logs kubia-manual

این دستور لاگ‌های کانتینر در پاد kubia-manual رو بهتون نشون می‌ده. مثلاً در این مثال، اگر اپلیکیشن شما یک سرور Node.js باشه، ممکنه لاگ‌تون این باشه:

تا وقتی که هیچ درخواست وبی به سرور نرسیده باشه، فقط همین لاگ ابتدایی ثبت می‌شه.

نکته: لاگ‌های کانتینر به‌طور خودکار هر روز و هر زمان که به حجم 10MB برسن، چرخانده می‌شن (log rotation). این دستور فقط لاگ‌های بعد از آخرین چرخش رو نمایش می‌ده.

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

ارسال درخواست به Pod

برای اینکه بتونی از پورت سیستم لوکال خودت به پاد توی کوبرنتیز دسترسی پیدا کنی، می‌تونی از ویژگی Port Forwarding استفاده کنی. این ویژگی بهت اجازه میده که بدون نیاز به ساختن یک سرویس کامل، به پاد دسترسی داشته باشی و اپلیکیشن داخلش رو تست کنی.

مثلاً فرض کن که اپلیکیشنت توی پاد داره روی پورت 8080 اجرا میشه و تو می‌خوای از سیستم لوکالت (پورت 8888) به اون پورت دسترسی پیدا کنی. برای این کار کافیه از دستور زیر استفاده کنی:

kubectl port-forward kubia-manual 8888:8080

با اجرای این دستور، در واقع داری پورت 8888 روی سیستمت رو به پورت 8080 توی پاد kubia-manual متصل می‌کنی. اگر همه چیز درست پیش بره، خروجی‌ای مشابه این دریافت می‌کنی:

... Forwarding from 127.0.0.1:8888 -> 8080
... Forwarding from [::1]:8888 -> 8080

حالا برای اینکه ببینی اپلیکیشنت درست کار می‌کنه، می‌تونی یه درخواست HTTP از طریق پورت 8080 روی لوکال سیستمت ارسال کنی:

curl http://localhost:8888

این دستور درخواستت رو به اپلیکیشن داخل پاد می‌فرسته. مثلاً اگر اپلیکیشنت یه پیغام "You’ve hit kubia-manual" برمی‌گردونه، این پیغام رو توی خروجی می‌بینی.

چرا Port Forwarding؟این روش خیلی سریع و راحت بهت اجازه می‌ده تا اپلیکیشنت رو تست کنی، بدون اینکه لازم باشه سرویس‌های پیچیده‌ای راه‌اندازی کنی. خیلی به درد تست‌های سریع و محلی می‌خوره، مخصوصاً زمانی که تازه داری اپلیکیشن رو دیباگ می‌کنی.

این روش یک راه سریع و موثر برای بررسی صحت عملکرد پاد و ارتباطات شبکه‌ای آن است. این ارتباط از طریق پورتی که روی ماشین محلی باز شده است (در این مثال 8888) به پورت اپلیکیشن داخل پاد (8080) هدایت می‌شود.

استفاده از label

در کوبرنتیز، با افزایش تعداد پادها، سازماندهی آنها ضروری است. لیبل‌ها (Labels) ابزاری برای دسته‌بندی و مدیریت بهتر پادها هستند. این لیبل‌ها شامل جفت‌های کلید-مقدار می‌شوند که می‌توانند در زمان ایجاد یا بعد از آن به پادها و سایر منابع اضافه شوند. لیبل‌ها به شما امکان می‌دهند منابع را بر اساس معیارهای دلخواه مانند نسخه اپلیکیشن، نوع سرویس (فرانت‌اند/بک‌اند) یا محیط اجرا (تست، تولید) دسته‌بندی کنید.

مزایای استفاده از لیبل‌ها:

1. جستجو و دسته‌بندی آسان: می‌توانید به‌سرعت منابع خاص را با استفاده از لیبل‌ها پیدا کنید.
2. مدیریت ساده‌تر: امکان اعمال عملیات‌های مختلف مثل حذف، بروزرسانی یا اسکیل کردن بر روی گروهی از پادها به‌صورت هم‌زمان.
3. انعطاف‌پذیری: محدودیتی در تعداد یا نوع لیبل‌ها وجود ندارد.

استفاده از لیبل‌ها در کوبرنتیز

یکی از امکانات قدرتمند در کوبرنتیز، استفاده از لیبل‌ها برای دسته‌بندی و سازماندهی منابع است. لیبل‌ها به صورت جفت کلید-مقدار (Key-Value) تعریف می‌شوند و به منابع مختلف مانند پادها (Pods) اضافه می‌شوند. این لیبل‌ها کمک می‌کنند که منابع مشابه را به سادگی با استفاده از label selectors فیلتر کرده و آن‌ها را مدیریت کنید.

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

اضافه کردن لیبل‌ها هنگام ساخت پاد

در یک فایل YAML به نام kubia-manual-with-labels.yaml، دو لیبل به پاد اضافه میکنیم:

• creation_method=manual
• env=prod

این لیبل‌ها نشان می‌دهند که پاد به‌صورت دستی ایجاد شده و در محیط تولید (prod) قرار دارد. با استفاده از دستور زیر می‌توان این پاد را ایجاد کرد:

kubectl create -f kubia-manual-with-labels.yaml

برای مشاهده لیبل‌ها، از دستور زیر استفاده کنید:

در کوبرنتیز، می‌توانید لیبل‌ها را بعد از ایجاد پادها اضافه یا تغییر دهید. برای مثال، می‌توانید با دستور kubectl label یک لیبل جدید اضافه کنید یا لیبل‌های قبلی را با استفاده از --overwrite تغییر دهید.

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

چند مثال از Selectorها:

• لیست پادهایی که با لیبل creation_method=manual ایجاد شده‌اند:

kubectl get po -l creation_method=manual

• لیست پادهایی که لیبل env دارند:

kubectl get po -l env

• لیست پادهایی که فاقد لیبل env هستند:

kubectl get po -l '!env'

این دستورات به شما امکان مدیریت سریع و موثر پادها بر اساس گروه‌بندی‌های دلخواه را می‌دهند.

استفاده از label ها و selector ها برای تنظیم مکان قرارگیری پادها

به صورت پیش‌فرض، کوبرنتیز پادها را به طور تصادفی در نودهای کلاستر مستقر می‌کند، اما در برخی موارد شما ممکن است بخواهید پادهای خاصی را روی نودهای خاصی با ویژگی‌های خاص (مثل SSD یا GPU) مستقر کنید. در اینجا لیبل‌ها و سلکتورها به کمک شما می‌آیند.

استفاده از لیبل‌ها برای نودها

می‌توانید به نودها لیبل‌هایی اختصاص دهید که مشخص کنند چه ویژگی‌هایی دارند، مثلاً نودهای دارای GPU را با لیبل gpu=true مشخص کنید. سپس از این لیبل‌ها برای فیلتر کردن نودها و تعیین اینکه کدام نودها واجد شرایط استقرار پادها هستند، استفاده می‌کنید.

مستقر کردن پادها روی نودهای خاص

برای تعیین اینکه یک پاد تنها روی نودهایی با ویژگی مشخص مستقر شود، از فیلد nodeSelector در YAML پاد استفاده می‌شود. برای مثال، می‌توانید پادی را فقط روی نودهایی با GPU مستقر کنید.

الان میتونیم ببینیم روی همون node که این ویژگی رو داره ایجاد شده توی اینجا پاد روی worker-node ایجاد شده.

مستقر کردن پاد روی نود مشخص

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

این قابلیت‌ها به شما امکان می‌دهند که با انعطاف بیشتری پادها را در نودهای مناسب مستقر کنید، به ویژه در کلاسترهای پیچیده که نودها منابع سخت‌افزاری متفاوتی دارند.

حاشیه نویسی یا Annotations

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

تفاوت اصلی با لیبل‌ها:

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

نمونه استفاده:

فرض کنید که می‌خواهید یک Annotation به پاد خود اضافه کنید تا مشخص کنید که چه کسی آن را ایجاد کرده است. از دستور زیر می‌توانید استفاده کنید:

$ kubectl annotate pod kubia-manual createdBy=&quotHossein jafari&quot

این دستور Annotation جدیدی به پاد اضافه می‌کند که نشان می‌دهد پاد توسط Hossein jafari ایجاد شده است.

کاربردهای دیگر:

• نگه‌داری اطلاعاتی که در مراحل بعدی نیاز به بررسی دارند.
• مستندسازی جزئیات اضافی در مورد پادها یا سایر منابع، مانند ورژن‌های بتا یا ابزارهای مدیریت.
• برخی از ویژگی‌های جدید کوبرنتیز ابتدا به صورت Annotations معرفی می‌شوند و پس از تثبیت در نسخه‌های بعدی به فیلدهای API تبدیل می‌شوند.

مشاهده Annotation‌ها:

شما می‌توانید با استفاده از دستور زیر، تمامی Annotations مرتبط با یک پاد را مشاهده کنید:

$ kubectl describe pod kubia-manual

در کل، Annotations روشی انعطاف‌پذیر و قدرتمند برای ذخیره اطلاعات اضافی هستند که به شما کمک می‌کنند تا مدیریت بهتری بر منابع خود داشته باشید.

استفاده از Namespace ها

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

چرا namespace‌ها مهم هستند؟

در یک کلاستر کوبرنتیز با تعداد زیادی منبع، مانند پادها و سرویس‌ها، ممکن است مدیریت آن‌ها به خصوص در محیط‌های بزرگ‌تر یا در معماری‌های میکروسرویس دشوار شود. namespace‌ها به شما اجازه می‌دهند تا این منابع را به گروه‌های جداگانه تقسیم کنید. هر namespace به عنوان یک محدوده مستقل برای منابع عمل می‌کند و شما می‌توانید محیط‌های مختلف مانند تولید (production)، توسعه (development) و تست (QA) را به راحتی جدا از هم مدیریت کنید.

ویژگی‌های namespace:

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

کاربرد namespace‌ها:

1. جداسازی محیط‌ها: با استفاده از namespace‌ ها، می‌توانید منابع مرتبط با محیط‌های تولید، توسعه و آزمایش را از هم جدا نگه دارید. این کار باعث می‌شود که خطاها و تغییرات ناخواسته در یک محیط تأثیری بر سایر محیط‌ها نداشته باشد.
2. مدیریت تیم‌ها: در کلاسترهایی که چندین تیم به صورت مشترک کار می‌کنند، هر تیم می‌تواند از یک namespace جداگانه برای مدیریت منابع خود استفاده کند و نیازی به نگرانی در مورد تداخل منابع نداشته باشد.
3. کنترل منابع: می‌توانید محدودیت‌هایی مانند محدودیت‌های منابع محاسباتی را برای هر namespace تعریف کنید تا از استفاده بیش از حد منابع توسط یک تیم یا سرویس جلوگیری شود.

ایجاد یک namespace جدید

برای ایجاد یک namespace، می‌توانید یک فایل YAML ساده ایجاد کرده و با استفاده از دستور kubectl آن را به API کوبرنتیز ارسال کنید. برای مثال، فایل زیر یک namespace با نام custom-namespace ایجاد می‌کند:

apiVersion: v1
kind: Namespace
metadata:
  name: custom-namespace

سپس از دستور زیر برای ایجاد این namespace استفاده کنید:

kubectl create -f custom-namespace.yaml

مشاهده و مدیریت namespace‌ها

برای مشاهده namespace‌های موجود در کلاستر، می‌توانید از دستور kubectl get ns استفاده کنید. این دستور لیستی از namespace‌ها را به شما نمایش می‌دهد. به‌عنوان مثال، در کلاسترهای پیش‌فرض، namespace‌هایی مانند default و kube-system وجود دارند. kube-system شامل منابع سیستم کوبرنتیز مانند سرویس‌های DNS است.

محدودیت‌های namespace‌ها

با وجود اینکه namespace‌ها منابع را به صورت منطقی جدا می‌کنند، اما به طور پیش‌فرض network isolation بین آن‌ها برقرار نیست. به عبارت دیگر، پادها در namespace‌های مختلف همچنان می‌توانند از طریق آدرس IP با هم ارتباط برقرار کنند مگر اینکه از راه‌حل‌های شبکه‌ای خاصی برای جلوگیری از این ارتباط استفاده شود.

نتیجه‌گیری

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

حذف پادها با استفاده از Label Selectors

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

حذف پادها با Label Selectors

اگر شما به پادها برچسب‌هایی مثل creation_method=manual داده‌اید و می‌خواهید تمام پادهایی که این برچسب را دارند را حذف کنید، دستور زیر را اجرا کنید:

$ kubectl delete po -l creation_method=manual

این دستور تمامی پادهایی که برچسب creation_method=manual دارند را به‌صورت همزمان حذف می‌کند.

حذف Namespace‌ها به همراه تمام منابع داخل آن

اگر قصد دارید تمام منابع داخل یک namespace را به همراه خود آن namespace حذف کنید، می‌توانید از دستور زیر استفاده کنید:

$ kubectl delete ns <namespace_name>

این دستور کل namespace و تمامی پادها و منابع مربوط به آن را حذف می‌کند. این روش معمولاً برای پاک‌سازی کامل محیط‌های توسعه یا تست استفاده می‌شود.

حذف همه پادها بدون حذف Namespace

اگر تنها می‌خواهید پادها را حذف کنید و خود namespace را حفظ کنید، دستور زیر را استفاده کنید:

$ kubectl delete po --all

این دستور تمام پادهای موجود در آن namespace را حذف می‌کند اما namespace باقی می‌ماند.

حذف پادهای ایجاد شده توسط ReplicationController

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

$ kubectl delete rc <replication_controller_name>

حذف همه منابع در یک namespace

برای حذف تمامی منابع موجود در یک namespace (شامل پادها، سرویس‌ها و کنترلرها) می‌توانید از دستور زیر استفاده کنید:

$ kubectl delete all --all

این دستور تقریباً همه منابع مانند ReplicationController، Service و Pod ها را حذف می‌کند. البته برخی منابع خاص مانند Secrets حذف نمی‌شوند و نیاز به حذف جداگانه دارند.