خواندن ۱۲ دقیقه·۴ روز پیش

پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم)

توی این پست میریم سراغ پادها توی کوبر و اونها رو بیشتر میشناسیم و بررسی‌شون می‌کنیم.

خب یه مروری کنیم پست‌های قبلی رو:

دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
خودکارش کن، مشکلاتت حل می‌شه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.
در مسیر دواپس این‌بار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویس‌هامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیس‌ها و تجربیات خودم رو گفتم.
تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.
در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.
در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.
در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.
مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپن‌تله‌متری دادیم.
در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.
در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.
کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

ساختار پادها و جزئیات اجزای آن (Containerها، Volumeها)

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

هر کانتینر یک اپلیکیشن یا سرویس را اجرا می‌کند. آنها بر اساس ایمیج‌های داکر ساخته می‌شوند و درون پاد با یکدیگر ارتباط دارند.

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

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

معمولا توی کوبرنتیز پاد رو به صورت مستقیم نمیسازن حتی پادهایی که یه دونه هستن، به جاش پادهارو با استفاده از ورکلودهایی مثل Deployment و Job میسازن یا اگه نیاز باشه که state پاد رو track کنیم از StatefulSet استفاده میشه. هر پاد معمولا یک اینستنس از اپلیکیشن مورد نظر رو توی خودش داره و سرویس میده و در صورتی‌ نیاز باید تعداد بیشتری از این پادها بالا بیاریم که به این کار رپلیکیشن میگن و معمولا پادهایی که نیاز داریم تعدادشون بیشتر باشه رو Replicated می‌کنیم و با یک ورکلود و کنترلرش اونها رو منیج می‌کنیم.

کانتینر Sidecar:

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

بررسی Init Container

توی صنعت بعضی کارخونه‌ها یه سری موتورهای خیلی بزرگ دارن که یکی از دغدغه‌های اصلی در مورد اونها روشن کردنشون هست! چون اگه اونها رو مستقیم از حالت سکون به برق وصل کنیم تا شروع به کار کنند، توان مصرفی بسیار بالایی نیاز هست و معمولا تامین اون برق ممکن نیست. به عنوان راه حل میان از یک موتور کوچیکتر در کنار اون بزرگه استفاده میکنن و اول اون کوچیکه رو روشن میکنن تا با کمک اون موتور بزرگ اصلی رو به یه گشتاور حداقلی برسونن و بعد دیگه موتور اصلی رو به برق وصل می‌کنن. به اون موتور کوچیکه میگن اینیت موتور :)

اینیت کانتینرها هم همینجوری هستن، کانتینرهایی هستند که قبل از کانتینرهای اصلی در یک پاد اجرا می‌شوند و کارهای اولیه مانند تنظیمات یا انتظار برای منابع خارجی رو انجام میدن تا بعد از اونها کانتیر اصلی کارش را انجام دهد.
تا زمانی که همه Init Containerها تکمیل نشوند، کانتینرهای اصلی شروع به کار نمی‌کنند.
مثلا یک Init Container که قبل از اجرای اپلیکیشن، فایل‌های پیکربندی را دانلود و آماده می‌کند.

بررسی Static Pod

توی پست‌های قبلی توضیح دادیم که درخواست ایجاد پاد به api-server میرسه و بعد scheduler نود مقصد رو مشخص میکنه و بعد api-server درخواست ایجاد این پاد رو میده به kubelet رو اون نود تا ایجاد بشه. اما خود api-server و scheduler هم پاد هستن، خود اینارو کی میاره بالا ؟!! اینجاست که سرو کله‌ی استاتیک پاد پیدا میشه، کیوبلت میگه آقاجان من اصلا کاری ندارم api-server چی میگه و ... اگر مانیفست پادی رو توی مسیر

/etc/kubernetes/manifests

ببینم، اونو میارم بالا ! استاتیک پادها پادهایی هستند که مستقیماً توسط Kubelet در هر نود ایجاد می‌شوند، بدون اینکه در API سرور ثبت شوند. پس ما میتونیم api-server و ... که نیاز داریم بیان بالا با استفاده از استاتیک پاد ایجادشون کنیم. یا مثلا ممکنه برای اجرای سرویس‌های خیلی حیاتی ازش استفاده کنیم. دقت کنید این پاد ها بدون کنترل پلین و فقط توسط kubelet اجرا می شوند.

بررسی و توضیح Pod Template

پاد تمپلت یک قالب است که مشخصات پادها را تعریف می‌کند و در منابعی مانند Deployment، ReplicaSet و ... استفاده می‌شود.

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

بررسی pod phase:

پادها توی کوبرنیز میتونن توی حالت‌های مختلفی قرار بگیرن که در ادامه هرکدوم رو به اختصار توضیح میدیم.

Pending:

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

Running:

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

Succeeded:

زمانیکه تمام کانتینرهای توی پاد به صورت موفق terminate شده باشند و ری‌استارت هم نشده باشند میگیم که پاد ساکسیدد شده.

Failed:

زمانیکه تمام کانتینرهای توی پاد terminate شده باشند و حداقل یکی‌شون توی حالت failure بوده باشه زمان terminate شدن، حالا یا با exit code جز صفر terminate شده باشه یا اینکه توسط سیستم فرقی نمیکنه. توی این حالت میگیم که پاد فِیل شده.

Unknown:

زمانیکه وضعیت پاد قابل تشخیص نباشه که معمولا به علت ایراد در کانکشن بین api-server و نودی که پاد روی اون هست این اتفاق میافته، میگیم که پاد Unknown هست.

بررسی Container States:

کانتینرها هم مثل پادها میتونن توی استیت‌های مختلفی باشند که در ادامه به اختصار توضیح میدم:

Waiting:

اگه یه کانتینر نه توی استیت Running باشه و نه استیت Terminated اون موقع توی استیت ویتینگ هست!!!

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

Running:

استیت رانینگ به این معنی هست که کانتینر بدون مشکل داره اجرا میشه و اگه یه poststart (جلوتر میگم چیه) داشته اون اجرا شده و تموم شده.

Terminated:

یه کانتینر توی حالت terminated هست زمانیکه شروع به اجرا کرده باشه و بعدش یا کارشو کامل کرده باشه و پروسه‌اش کامل شده باشه یا اینکه به هردلیلی fail شده باشه.

بررسی PostStart و PreStop:

کوبرنتیز بهمون این امکان رو میده که یه سری اکشن‌های کاستوم‌شده رو تو زمان‌های مشخصی در lifecycle کانتینر اجرا کنیم که بهشون میگیم PreStop and PostStart lifecycle hooks.

بلافاصله بعد از اینکه کانتینر ساخته میشه و قبل از اینکه entrypoint command اجرا شه، PostStart hook اجرا میشه که یوزکیسش مثلا میشه ستاپ کردن کانفیگ یا اجرای یه سری اسکریپت برای آماده کردن environment یا آماده سازی دیتابیس و ...

و درست قبل از اینکه کانتینر terminated بشه PreStop hook اجرا میشه که معمولا تسک‌های cleanup و مواردی مثل gracefully shutting down یا ذخیره کردن state یا ارسال نوتیف استاپ شدن سرویس یوزکیس‌های مرتبط باهاش هستن.

بررسی لیبل و سلکتور :

لیبل‌ها (Labels): برچسب‌های کلید-مقداری هستند که به منابع کوبرنتیز اضافه می‌شوند تا آنها را دسته‌بندی و سازماندهی کنیم.
سلکتورها (Selectors): ابزارهایی هستند که به ما امکان می‌دهند منابع را بر اساس لیبل‌هایشان انتخاب کنیم.

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

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

بررسی و توضیح Annotations و تفاوتش با Labels

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

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

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

بررسی و توضیح Finalizers و کاربرد آن

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

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

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

توی این پست سعی کردیم تا بیشتر با پادها توی کوبرنتیز آشنا بشیم و ببینیم که چطوری اونها رو مدیریت می‌کنند.

مراقب خودتون باشید. 🌹🐳🌹