باید ابتدا مشخص شود که با ری‌استارت کانتینر در همان پاد روبه‌رو هستیم یا ایجاد مجدد پاد در کوبرنتیز اتفاق افتاده است. معیارهایی مانند Pod UID و تعداد ری‌استارت کانتینر (restartCount) در ادامه به ما کمک می‌کنند این دو وضعیت را از یکدیگر تشخیص دهیم.

در این مقاله بررسی می‌کنیم کوبرنتیز در چه شرایطی کانتینر را دوباره اجرا می‌کند، چه تغییراتی باعث جایگزینی پاد می‌شوند و چگونه می‌توان با بررسی وضعیت پاد تشخیص داد که کانتینر در همان پاد ری‌استارت شده یا پاد جدیدی ساخته شده است. این مقاله بر رفتارهای مستندشده در Kubernetes 1.35 تمرکز دارد و قابلیت In-place Pod Resize را نیز بررسی می‌کند که در این نسخه به وضعیت پایدار رسید.

تفاوت ری‌استارت کانتینر با ایجاد مجدد پاد چیست؟

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

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

اگر فرایند یک کانتینر متوقف شود، در صورت اجازه سیاست ری‌استارت (restartPolicy)، kubelet همان کانتینر را دوباره داخل همان پاد اجرا می‌کند. در این حالت، خود پاد حذف نمی‌شود و هویت آن تغییر نمی‌کند؛ بنابراین Pod UID ثابت باقی می‌ماند و تعداد ری‌استارت همان کانتینر افزایش پیدا می‌کند.

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

ایجاد مجدد یا جایگزینی پاد

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

کنترلرهایی مانند دیپلویمنت می‌توانند هنگام تغییر الگوی پاد (Pod Template) یک Rollout جدید آغاز کنند. در این فرایند، ReplicaSet جدید ایجاد می‌شود و پادهای جدید بر اساس الگوی جدید ساخته می‌شوند. ازآنجایی‌که این پادها هویت مستقلی دارند، تعداد ری‌استارت کانتینرهای آن‌ها از صفر آغاز می‌شود، مگر اینکه کانتینرهای پاد جدید پس از ایجاد، ری‌استارت شوند.

جدول مقایسه ری‌استارت کانتینر و ایجاد مجدد پاد

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

نقش restartPolicy در ری‌استارت کانتینرها

پاد مشخص می‌کند که پس از متوقف شدن کانتینر، kubelet در چه شرایطی آن را دوباره اجرا کند. فیلد restartPolicy در مشخصات پاد تعریف می‌شود و برای کانتینرهای برنامه می‌تواند یکی از سه مقدار Always ،OnFailure یا Never را داشته باشد. مقدار پیش‌فرض آن Always است. ری‌استارت‌هایی که بر اساس این سیاست انجام می‌شوند، کانتینر را داخل همان پاد و روی همان نود دوباره اجرا می‌کنند و به معنای ایجاد پاد جدید نیستند.

سیاست Always

با انتخاب سیاست Always، هر بار که اجرای کانتینر به پایان برسد، kubelet صرف‌نظر از اینکه اجرای آن با موفقیت یا خطا پایان یافته باشد، کانتینر را دوباره اجرا می‌کند. به همین دلیل، این سیاست برای بارهای کاری (Workload) که باید به‌صورت مداوم در حال اجرا باشند کاربرد دارد. برای نمونه، دیپلویمنت‌ها از restartPolicy: Always استفاده می‌کنند تا برنامه‌ها به‌طور پیوسته اجرا شوند.

سیاست OnFailure

در سیاست OnFailure، نحوه خاتمه کانتینر تعیین می‌کند که اجرای مجدد انجام شود یا خیر. اگر کانتینر با خطا و وضعیت خروج غیرصفر (Non-zero Exit Status) خاتمه پیدا کند، kubelet آن را دوباره اجرا می‌کند، اما اگر کانتینر با وضعیت خروج صفر و به‌صورت موفق خاتمه یابد، ری‌استارت انجام نمی‌شود. معمولا Jobها از OnFailure یا Never برای مدیریت وظایف پردازش دسته‌ای استفاده می‌کنند.

سیاست Never

با انتخاب Never، کانتینر پس از خاتمه (صرف‌نظر از اینکه اجرای آن موفق بوده یا با خطا پایان یافته باشد) به‌طور خودکار دوباره اجرا نمی‌شود. بنابراین، برخلاف Always و OnFailure، حتی خاتمه ناموفق کانتینر هم باعث نمی‌شود kubelet آن را بر اساس سیاست ری‌استارت دوباره اجرا کند.

تاخیر تصاعدی میان ری‌استارت‌ها

در تنظیمات پیش‌فرض، kubelet پس از توقف‌های متوالی کانتینر از تأخیر تصاعدی استفاده می‌کند. فاصله میان تلاش‌های بعدی از ۱۰ ثانیه آغاز می‌شود و به‌ترتیب به ۲۰، ۴۰ ثانیه و مقادیر بیشتر افزایش می‌یابد تا به سقف پیش‌فرض ۳۰۰ ثانیه برسد. این سقف به فاصله میان تلاش‌ها مربوط است و به معنای محدود بودن تعداد تلاش‌های ری‌استارت نیست. اگر کانتینر ۱۰ دقیقه بدون مشکل اجرا شود، kubelet تأخیر میان تلاش‌های ری‌استارت را دوباره از مقدار اولیه محاسبه می‌کند.

این سازوکار با وضعیت CrashLoopBackOff ارتباط دارد. این وضعیت نشان می‌دهد کانتینر به‌طور مکرر با شکست مواجه شده و سازوکار تأخیر میان تلاش‌های اجرای مجدد آن فعال است.

CrashLoopBackOff به چه معناست؟

CrashLoopBackOff زمانی مشاهده می‌شود که یک کانتینر به‌طور مکرر متوقف شود و در صورت اجازه سیاست ری‌استارت، kubelet برای اجرای مجدد آن تلاش کند. با تکرار این چرخه، تعداد ری‌استارت کانتینر افزایش می‌یابد و kubelet با استفاده از سازوکار Backoff، فاصله میان تلاش‌های متوالی برای اجرای مجدد کانتینر را به‌تدریج بیشتر می‌کند.

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

Probeها چه زمانی باعث ری‌استارت کانتینر می‌شوند؟

پروب‌ها (Probe) برای بررسی وضعیت کانتینرها در کوبرنتیز استفاده می‌شوند، اما شکست همه آن‌ها نتیجه یکسانی ندارد. بسته به نوع پروب، نتیجه بررسی می‌تواند به ری‌استارت کانتینر منجر شود یا روی آماده بودن آن برای دریافت ترافیک تأثیر بگذارد. برای درک این تفاوت، باید عملکرد پروب زنده‌بودن (Liveness Probe)، پروب آمادگی (Readiness Probe) و پروب راه‌اندازی (Startup Probe) را جداگانه بررسی کرد.

تفاوت Liveness ،Readiness و Startup Probe

هر سه پروب هدف متفاوتی دارند و شکست آن‌ها هم نتیجه یکسانی ایجاد نمی‌کند:

• پروب زنده‌بودن: مشخص می‌کند کانتینر همچنان سالم است یا باید متوقف شود. اگر Liveness Probe بیش از تعداد دفعات تعیین‌شده شکست بخورد، kubelet کانتینر را متوقف می‌کند. رفتار بعدی به سیاست ری‌استارت پاد بستگی دارد و در صورت اجازه این سیاست، کانتینر داخل همان پاد دوباره اجرا می‌شود. بنابراین، شکست این پروب به‌خودی‌خود به معنای ساخته شدن پاد جدید نیست.
• پروب آمادگی: مشخص می‌کند کانتینر برای دریافت ترافیک آماده است یا خیر. اگر Readiness Probe شکست بخورد، آدرس پاد از EndpointSlice سرویس‌های منطبق حذف می‌شود؛ اما kubelet کانتینر را به‌دلیل شکست این پروب ری‌استارت نمی‌کند.
• پروب راه‌اندازی: مشخص می‌کند برنامه داخل کانتینر شروع به کار کرده است یا خیر. اگر Startup Probe تعریف شده باشد، پروب‌های زنده‌بودن و آمادگی تا موفق شدن آن اجرا نمی‌شوند. اگر این پروب بیش از تعداد دفعات تعیین‌شده شکست بخورد، kubelet کانتینر را متوقف می‌کند و رفتار بعدی بر اساس سیاست ری‌استارت پاد تعیین می‌شود.

در نتیجه، شکست Readiness Probe فقط بر دریافت ترافیک تأثیر می‌گذارد؛ اما شکست Liveness Probe یا Startup Probe می‌تواند به توقف کانتینر و سپس اجرای مجدد آن در همان پاد منجر شود.

هنگام تغییر Image چه اتفاقی برای پاد می‌افتد؟

ایمیج کانتینر (Container Image) نسخه آماده‌ای است که کانتینر بر اساس آن ساخته و اجرا می‌شود. برای مثال، تغییر ایمیج از یک نسخه برنامه به نسخه‌ای دیگر مشخص می‌کند که کانتینرهای جدید باید کدام نسخه را اجرا کنند.

در یک دیپلویمنت، ایمیج کانتینر بخشی از Pod Template است؛ یعنی همان الگویی که مشخصات پادهای موردنظر را تعریف می‌کند. با تغییر ایمیج، این الگو نیز تغییر می‌کند. اگر دیپلویمنت در حالت Paused نباشد، این تغییر یک Rollout جدید را آغاز می‌کند. سپس ReplicaSet جدیدی ایجاد می‌شود و پادهای جدید بر اساس ایمیج به‌روزشده ساخته می‌شوند. بنابراین، تغییر ایمیج در دیپلویمنت به معنای ری‌استارت کانتینر داخل پادهای موجود نیست؛ بلکه پادهای جدیدی ساخته می‌شوند که کانتینرهای آن‌ها از ایمیج جدید استفاده می‌کنند.

تغییر Pod Template و ایجاد ReplicaSet جدید

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

پس از تغییر الگوی پاد، استقرار یک ReplicaSet جدید ایجاد می‌کند و پادهای جدید براساس الگوی به‌روزشده ساخته می‌شوند. در به‌روزرسانی تدریجی (Rolling Update)، کوبرنتیز به‌تدریج تعداد پادهای جدید را افزایش و تعداد پادهای قبلی را کاهش می‌دهد. این فرایند با افزایش مقیاس ReplicaSet جدید و کاهش مقیاس ReplicaSet قبلی انجام می‌شود. اگر Deployment در حالت Paused باشد، تغییر Pod Template ثبت می‌شود، اما Rollout تا زمان خارج شدن Deployment از این حالت پیش نمی‌رود.

تفاوت Rolling Update با ری‌استارت کانتینر

در به‌روزرسانی تدریجی، کانتینر داخل همان پاد دوباره اجرا نمی‌شود، بلکه پادهای جدید براساس الگوی پاد جدید ساخته می‌شوند. این تفاوت را می‌توان با Pod UID (شناسه منحصربه‌فرد پاد) تشخیص داد. با ایجاد پاد جدید، این شناسه تغییر می‌کند، اما در ری‌استارت کانتینر، همان شناسه قبلی حفظ می‌شود.

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

رفتار Deployment در ImagePullBackOff

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

در به‌روزرسانی تدریجی، ممکن است دیپلویمنت بخشی از پادهای قبلی را همچنان در حال اجرا نگه دارد و جایگزینی پادها متوقف شود. تعداد پادهای قبلی باقی‌مانده و نحوه ادامه Rollout به تنظیماتی مانند maxUnavailable و maxSurge بستگی دارد. بنابراین، وقوع ImagePullBackOff لزوماً به معنای حذف همه پادهای قبلی نیست.

آیا تغییر ConfigMap باعث ری‌استارت پاد می‌شود؟

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

مصرف ConfigMap از طریق متغیر محیطی

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

برای دریافت مقادیر جدید در یک دیپلویمنت، باید Rollout جدیدی انجام شود تا پادهای جدید با متغیرهای محیطی به‌روز ساخته شوند. صرف تغییر ConfigMap این Rollout را به‌صورت خودکار آغاز نمی‌کند؛ زیرا تغییر ConfigMap به‌خودی‌خود Pod Template یک دیپلویمنت را تغییر نمی‌دهد.

اتصال ConfigMap به‌صورت Volume

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

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

محدودیت استفاده از subPath

subPath مشخص می‌کند که به‌جای اتصال کل Volume، فقط یک فایل یا مسیر مشخص از آن داخل کانتینر متصل شود. رفتار اتصال ConfigMap با subPath متفاوت است. براساس مستندات رسمی کوبرنتیز، کانتینری که ConfigMap را با استفاده از subPath به‌صورت Volume متصل کرده باشد، به‌روزرسانی‌های بعدی ConfigMap را دریافت نمی‌کند. بنابراین، برخلاف اتصال کامل ConfigMap به‌صورت Volume که فایل‌های متصل‌شده می‌توانند به‌روزرسانی شوند، در اتصال مبتنی بر subPath تغییرات جدید ConfigMap در فایل متصل‌شده منعکس نمی‌شوند.

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

به‌روزرسانی فایل و بارگذاری مجدد تنظیمات توسط برنامه دو فرایند متفاوت هستند. کوبرنتیز می‌تواند در اتصال معمول ConfigMap به‌صورت Volume، فایل‌های متصل‌شده را به‌روزرسانی کند؛ اما این اتفاق به‌تنهایی باعث نمی‌شود برنامه تنظیمات جدید را بارگذاری کند.

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

دستور rollout restart چه کاری انجام می‌دهد؟

دستور kubectl rollout restart برای راه‌اندازی مجدد Rollout یک دیپلویمنت استفاده می‌شود. در این عملیات، پادهای دیپلویمنت مطابق استراتژی به‌روزرسانی آن با پادهای جدید جایگزین می‌شوند. بنابراین، این دستور، کانتینر را داخل همان پاد دوباره اجرا نمی‌کند و پادهای جایگزین هویت و Pod UID جدیدی دارند.

تغییر CPU و Memory بدون ایجاد مجدد پاد

قابلیت In-place Pod Resize امکان تغییر Request و Limit مربوط به CPU و Memory را بدون جایگزینی پاد فراهم می‌کند. این قابلیت به همین دو نوع منبع محدود است و منابعی غیر از CPU و Memory همچنان با این سازوکار قابل تغییر نیستند.

قابلیت In-place Pod Resize چیست؟

قابلیت In-place Pod Resize در کوبرنتیز نسخه 1.35 به وضعیت پایدار رسید. پیش از ارائه این قابلیت، مقادیر CPU و Memory تخصیص‌یافته به کانتینر در مشخصات پاد تغییرناپذیر بودند و تغییر آن‌ها به حذف و ایجاد مجدد پاد نیاز داشت. این قابلیت Request و Limit مربوط به CPU و Memory را قابل تغییر می‌کند و امکان اعمال آن‌ها را داخل پاد در حال اجرا فراهم می‌سازد.

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

نقش resizePolicy در ری‌استارت کانتینر

رفتار کانتینر هنگام تغییر منابع به resizePolicy تعریف‌شده برای هر منبع بستگی دارد. این سیاست می‌تواند یکی از دو مقدار NotRequired یا RestartContainer را داشته باشد.

با سیاست NotRequired، تغییر منبع بدون نیاز به ری‌استارت کانتینر اعمال می‌شود. در مقابل، سیاست RestartContainer مشخص می‌کند که برای اعمال تغییر، کانتینر داخل همان پاد دوباره اجرا شود. برای مثال، می‌توان تغییر CPU را بدون ری‌استارت انجام داد و برای تغییر Memory، ری‌استارت کانتینر را الزامی کرد.

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

محدودیت‌های In-place Pod Resize

قابلیت In-place Pod Resize با وجود رسیدن به وضعیت پایدار در کوبرنتیز 1.35، همچنان محدودیت‌هایی دارد. براساس منبع رسمی، در حال حاضر CPU و Memory را می‌توان با این روش تغییر داد و سایر منابع همچنان تغییرناپذیر هستند.

همچنین استفاده از این قابلیت همراه با Swap، Static CPU Manager و Static Memory Manager پشتیبانی نمی‌شود. برخی محیط‌های اجرای زبان‌های برنامه‌نویسی هم برای تغییر Memory بدون ری‌استارت محدودیت دارند. برای مثال، طبق منبع رسمی، Java و Python در زمان انتشار این مطلب از تغییر اندازه حافظه بدون ری‌استارت پشتیبانی نمی‌کردند.

در نتیجه، In-place Pod Resize امکان تغییر CPU و Memory بدون ساخت پاد جدید را فراهم می‌کند؛ اما نحوه اعمال تغییر و نیاز به ری‌استارت کانتینر می‌تواند به سیاست تعریف‌شده و محدودیت‌های محیط اجرا بستگی داشته باشد.

چگونه ری‌استارت کانتینر را از جایگزینی پاد تشخیص دهیم؟

برای تشخیص ری‌استارت کانتینر در همان پاد از ایجاد پاد جدید، می‌توان شناسه پاد، تعداد ری‌استارت کانتینر و رویدادهای ثبت‌شده را بررسی کرد. Pod UID و تعداد ری‌استارت کانتینر دو معیار مهم برای این تشخیص هستند و بررسی وضعیت و رویدادهای پاد نیز اطلاعات تکمیلی در اختیار ما قرار می‌دهد.

بررسی Pod UID

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

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

بررسی restartCount

تعداد ری‌استارت کانتینر نشان می‌دهد کانتینر چند بار توسط kubelet در همان پاد دوباره اجرا شده است. بنابراین، افزایش این مقدار همراه با ثابت ماندن Pod UID نشان‌دهنده ری‌استارت کانتینر در همان پاد است.

پاد تازه‌ساخته‌شده وضعیت کانتینرهای خود را مستقل از پاد قبلی دارد؛ بنابراین اگر کانتینرهای آن هنوز ری‌استارت نشده باشند، تعداد ری‌استارت کانتینر صفر خواهد بود. به همین دلیل، این مقدار را بهتر است همراه با Pod UID بررسی کرد.

بررسی وضعیت و رویدادهای پاد

برای بررسی دقیق‌تر می‌توان وضعیت و رویدادهای پاد را هم مشاهده کرد. دستور زیر اطلاعات کلی وضعیت پاد را نمایش می‌دهد:

kubectl get pod <pod-name> -o wide

kubectl get pod <pod-name> -o wide

برای مشاهده جزئیات پاد و رویدادهای مرتبط با آن می‌توان از دستور زیر استفاده کرد:

kubectl describe pod <pod-name>

kubectl describe pod <pod-name>

نمایش JSON پاد با دستور زیر امکان‌پذیر است:

kubectl get pod <pod-name> -o json

kubectl get pod <pod-name> -o json

برای مشاهده هم‌زمان نام پاد، Pod UID، آدرس IP، نام کانتینرها و تعداد ری‌استارت هر کانتینر می‌توان از دستور زیر استفاده کرد:

kubectl get pod <pod-name> -o custom-columns=\
"NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[0].restartCount"

kubectl get pod <pod-name> -o custom-columns=\
"NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[0].restartCount"

این دستور فقط تعداد ری‌استارت اولین کانتینر موجود در containerStatuses را نمایش می‌دهد. در پادهای چندکانتینری، برای مشاهده وضعیت همه کانتینرها باید آرایه containerStatuses در خروجی JSON پاد بررسی شود.

جدول نهایی: هر تغییر چه اثری روی کانتینر و پاد دارد؟

جدول زیر نشان می‌دهد در سناریوهای بررسی‌شده، چه زمانی کانتینر در همان پاد ری‌استارت می‌شود و چه زمانی پاد جدیدی با Pod UID متفاوت ایجاد می‌شود.

جمع‌بندی

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

برای تشخیص این دو وضعیت، تعداد ری‌استارت کانتینر و Pod UID دو معیار کاربردی هستند. تعداد ری‌استارت به تشخیص اجرای مجدد کانتینر در همان پاد کمک می‌کند و Pod UID مشخص می‌کند که هویت پاد تغییر کرده است یا خیر.

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

The post ری‌استارت کانتینر یا ساخت پاد جدید؛ کوبرنتیز چگونه تصمیم می‌گیرد؟ appeared first on بلاگ هم‌روش.

کنترل‌پلین (Control Plane) مجموعه‌ای از اجزای اصلی کوبرنتیز است که اغلب به‌عنوان مغز کلاستر شناخته می‌شود و وضعیت کلی آن را مدیریت می‌کند. سرور API کوبرنتیز (Kubernetes API) را در دسترس قرار می‌دهد، Scheduler پادهای بدون نود را به نود مناسب اختصاص می‌دهد و مدیر کنترلر، کنترلرهای موردنیاز برای اجرای رفتارهای API کوبرنتیز را اجرا می‌کند. به همین دلیل، می‌توان کنترل‌پلین را لایه مدیریتی کلاستر دانست؛ بخشی که وظیفه اصلی آن مدیریت وضعیت و هماهنگی فرایندهای کلاستر است، نه اجرای بارهای کاری کاربران.

همچنین تفاوت کنترل‌پلین و نود ورکر (Worker Node) را نقش آن‌ها در معماری کلاستر مشخص می‌کند؛ بارهای کاری کاربران روی نودهای ورکر اجرا می‌شوند، درحالی‌که کنترل‌پلین مسئول مدیریت وضعیت کلاستر، تصمیم‌گیری و هدایت فرایندهای کنترلی است. در ادامه، معماری کنترل‌پلین کوبرنتیز، اجزای اصلی آن و نحوه کار کنترل‌پلین کوبرنتیز را بررسی می‌کنیم.

کنترل‌پلین چه نقشی در معماری کوبرنتیز دارد؟

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

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

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

اجزای اصلی کنترل‌پلین کوبرنتیز کدام‌اند؟

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

سرور API یا kube-apiserver

سرور API یا kube-apiserver یکی از اجزای اصلی کنترل‌پلین است که API کوبرنتیز را در دسترس قرار می‌دهد. ابزارهایی مانند kubectl و سایر سرویس‌گیرنده‌های API، از طریق این رابط با کلاستر تعامل می‌کنند. درخواست‌های دریافتی در این بخش اعتبارسنجی شده و مراحل احراز هویت، مجوزدهی و کنترل پذیرش (Admission Control به معنی بررسی، پذیرش، رد یا اصلاح درخواست پیش از ثبت آن) روی آن‌ها انجام می‌شود. همچنین سرور API برای ثبت و بازیابی وضعیت منابع و اطلاعات پیکربندی کلاستر با etcd تعامل می‌کند.

سرور API مسئول اجرای مستقیم کانتینرها نیست. اجرای پادها و کانتینرهای مربوط به بارهای کاری روی نودهای ورکر و به‌وسیله kubelet و محیط اجرای کانتینر انجام می‌شود.

پایگاه داده etcd

پایگاه داده etcd یک مخزن کلید-مقدار (Key-Value Store) سازگار و توزیع‌شده است که داده‌های API کوبرنتیز، از جمله اطلاعات منابع و پیکربندی کلاستر، را نگهداری می‌کند. ازآنجایی‌که تمام داده‌های سرور API در آن ذخیره می‌شوند، ازدست‌رفتن داده‌های etcd می‌تواند بازیابی کلاستر را دشوار یا غیرممکن کند. به همین دلیل، پشتیبان‌گیری، امنیت و دسترس‌پذیری آن برای پایداری کنترل‌پلین حیاتی است. در معماری کوبرنتیز، تمام اجزای کنترل‌پلین مستقیما به etcd متصل نمی‌شوند، بلکه تعامل آن‌ها با وضعیت کلاستر از طریق سرور API انجام می‌گیرد.

زمان‌بند یا kube-scheduler

Scheduler پادهایی را پیدا می‌کند که هنوز به نودی اختصاص داده نشده‌اند و هر پاد را به یک نود مناسب اختصاص می‌دهد. Scheduler فقط نود مناسب را برای هر پاد انتخاب می‌کند. پس از آن، kubelet روی نود ورکر از اجرای کانتینرهای پاد اطمینان حاصل می‌کند و محیط اجرای کانتینر مسئول اجرای کانتینرها است.

مدیر کنترلر یا kube-controller-manager

مدیر کنترلر یا kube-controller-manager کنترلرهایی را اجرا می‌کند که مبتنی بر مفهوم «حلقه کنترل» (Control Loop) کار می‌کنند. این کنترلرها وضعیت منابع را از طریق API مشاهده کرده و تلاش می‌کنند وضعیت فعلی را با وضعیت مطلوب تطبیق دهند. برای مثال، اگر تعداد پادهای در حال اجرا کمتر از تعداد تعریف‌شده باشد، کنترلر مربوط این اختلاف را تشخیص می‌دهد و برای ایجاد منابع لازم اقدام می‌کند. از نمونه‌های مهم این کنترلرها می‌توان به Node Controller (برای نظارت بر وضعیت نودها) و Job Controller اشاره کرد.

مدیر کنترلر ابری یا cloud-controller-manager

مدیر کنترلر ابری یا cloud-controller-manager یک جزء اختیاری کنترل‌پلین است که کوبرنتیز را با ارائه‌دهندگان زیرساخت ابری یکپارچه می‌کند. بنابراین، وجود این جزء به محیط استقرار کلاستر وابسته است و همه کلاسترها الزاما از آن استفاده نمی‌کنند.

یک درخواست چگونه در کنترل‌پلین پردازش می‌شود؟

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

۱. کاربر مشخصات دیپلویمنت را از طریق kubectl ارسال می‌کند.

۲. درخواست به سرور API می‌رسد و مراحل احراز هویت، مجوزدهی، کنترل پذیرش و اعتبارسنجی لازم را طی می‌کند.

۳. وضعیت مطلوب از طریق سرور API در etcd ثبت می‌شود.

۴. کنترلر دیپلویمنت ایجاد این منبع را مشاهده می‌کند و ReplicaSet لازم را می‌سازد؛ سپس کنترلر ReplicaSet، پادهای موردنیاز را ایجاد می‌کند.

۵. Scheduler برای پادهای بدون نود، نود مناسب انتخاب می‌کند.

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

۷. وضعیت جدید دوباره از طریق سرور API ثبت می‌شود و کنترلرها به نظارت خود ادامه می‌دهند.

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

در صورت خرابی کنترل‌پلین چه اتفاقی می‌افتد؟

پیامد خرابی کنترل‌پلین به نوع خرابی و میزان افزونگی معماری بستگی دارد. خرابی یک فرایند یا یک نود کنترل‌پلین در معماری دسترس‌پذیر لزوماً کل کنترل‌پلین را از دسترس خارج نمی‌کند؛ زیرا Instanceهای سالم می‌توانند ارائه سرویس را ادامه دهند. در مقابل، ازدسترس‌خارج‌شدن کامل کنترل‌پلین، فعالیت‌های مدیریتی کلاستر را مختل می‌کند. پیامدهای از دسترس خارج شدن کامل کنترل‌پلین عبارت‌اند از:

• پردازش نشدن درخواست‌های جدید API
• اختلال در ایجاد، تغییر یا حذف منابع از طریق API
• زمان‌بندی‌نشدن پادهای جدید
• توقف فرایند تطبیق وضعیت فعلی با وضعیت مطلوب
• مختل‌شدن مشاهده وضعیت کلاستر با ابزارهایی مانند kubectl

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

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

کنترل‌پلین با دسترس‌پذیری بالا چگونه طراحی می‌شود؟

در معماری دارای دسترس‌پذیری بالا، اجزای کنترل‌پلین روی بیش از یک نود اجرا می‌شوند و در محیط‌های ابری، این نودها پشت یک لود بالانسر مبتنی بر TCP قرار می‌گیرند. لود بالانسر ترافیک ورودی API کوبرنتیز را میان instanceهای سالم kube-apiserver توزیع می‌کند و باید بتواند از طریق پورت سرور API با همه نودهای کنترل‌پلین ارتباط برقرار کند. برای افزایش دسترس‌پذیری کنترل‌پلین، معمولا از اصول زیر در طراحی معماری استفاده می‌شود:

• استفاده از چند نود کنترل‌پلین
• توزیع نودهای کنترل‌پلین و اعضای etcd میان دامنه‌های خرابی مستقل، در صورت امکان
• قراردادن instanceهای kube-apiserver پشت یک لود بالانسر
• اطمینان از ارتباط لود بالانسر با instanceهای kube-apiserver و هدایت ترافیک به instanceهای سالم
• انتخاب یکی از دو توپولوژی stacked etcd یا external etcd
• استفاده از تعداد فرد اعضای etcd برای حفظ حد نصاب و تداوم فعالیت کلاستر در صورت خرابی برخی از اعضا
• پایش سلامت اجزای کنترل‌پلین
• تهیه نسخه پشتیبان منظم از etcd و آزمایش فرایند بازیابی آن
• حفاظت از گواهی‌ها و اطلاعات حساس کنترل‌پلین

مستندات رسمی کوبرنتیز دو توپولوژی اصلی را برای استقرار کنترل‌پلین با دسترس‌پذیری بالا معرفی می‌کنند:

تفاوت اصلی این دو رویکرد در هم‌مکان بودن یا جدا بودن اعضای etcd و نودهای کنترل‌پلین است. روش stacked etcd به زیرساخت کمتری نیاز دارد، درحالی‌که روش external etcd با جدا کردن این دو بخش، ماشین‌های بیشتری را برای اعضای etcd در نظر می‌گیرد.

دسترسی به کنترل‌پلین چگونه ایمن می‌شود؟

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

• استفاده از ارتباط رمزنگاری‌شده مبتنی بر TLS
• اعمال احراز هویت و مجوزدهی مبتنی بر کمترین سطح دسترسی
• حفاظت از فایل‌های kubeconfig، گواهی‌ها و کلیدهای کنترل‌پلین
• ثبت و بررسی رویدادهای Audit
• محافظت از دسترسی شبکه‌ای و داده‌های etcd

مدیریت کنترل‌پلین در کوبرنتیز خودمدیریت‌شده و مدیریت‌شده چه تفاوتی دارد؟

در یک کلاستر کوبرنتیز خودمدیریت‌شده (Self-managed Kubernetes) مبتنی بر kubeadm، تیم بهره‌بردار باید نودهای کنترل‌پلین، لود بالانسر مربوط به kube-apiserver و توپولوژی etcd را راه‌اندازی و مدیریت کند. همچنین این تیم باید اجزای لازم را روی نودهای کنترل‌پلین مستقر کند و در مدل external etcd، کلاستر جداگانه etcd را پیش از راه‌اندازی کنترل‌پلین آماده سازد.

در کوبرنتیز مدیریت‌شده (Managed Kubernetes)، ارائه‌دهنده، سرویس کنترل‌پلین را مدیریت می‌کند و اجزای اصلی آن، مانند kube-apiserver، etcd ،kube-scheduler و kube-controller-manager، در محدوده کنترل‌پلین مدیریت‌شده قرار می‌گیرند. در مقابل، نودهای ورکر، زیرساختی هستند که برنامه‌های کاربران را اجرا می‌کنند.

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

جمع‌بندی

درپاسخ به این پرسش که کنترل‌پلین در کوبرنتیز چیست، می‌توان گفت کنترل‌پلین لایه تصمیم‌گیری و مدیریت وضعیت کلاستر است. اجزایی مانند kube-apiserver ،etcd ،kube-scheduler و kube-controller-manager مسئولیت مشخصی در مدیریت وضعیت کلاستر بر عهده دارند و در کنار یکدیگر امکان تصمیم‌گیری و هماهنگی فرایندهای کنترلی را فراهم می‌کنند. در سمت مقابل، اجرای مستقیم بارهای کاری بر عهده نودهای ورکر است، نه کنترل‌پلین.

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

The post کنترل‌پلین در کوبرنتیز چیست و چگونه کلاستر را مدیریت می‌کند؟ appeared first on بلاگ هم‌روش.

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

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

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

• ارتقا نسخه و نصب اصلاحیه‌ها (Patch): تیم باید نسخه‌ها و اصلاحیه‌های جدید، از جمله اصلاحیه‌های امنیتی را دنبال و برای اعمال آن‌ها روی کلاسترها برنامه‌ریزی کند.
• رسیدگی به APIهای منسوخ‌شده: نسخه‌های قدیمی API ابتدا منسوخ می‌شوند و ممکن است در نسخه‌های بعدی دیگر ارائه نشوند. به همین دلیل، تیم باید وابستگی فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌ها به این APIها را شناسایی کند و در صورت نیاز، آن‌ها را به نسخه‌های جدیدتر انتقال دهد.
• رفع ناسازگاری افزونه‌ها (Add-on): ابزارها و افزونه‌های نصب‌شده روی کلاستر ممکن است با نسخه جدید کوبرنتیز سازگار نباشند، بنابراین تیم باید سازگاری آن‌ها را بررسی کند و در صورت نیاز، نسخه مناسب‌تری از آن‌ها را به کار بگیرد.
• ارتقا هلم چارت‌ها (Helm Chart): نسخه‌های جدید هلم چارت‌ها باید از نظر تغییر مانیفست‌ها (Manifest)، وابستگی‌ها و سازگاری با کلاستر بررسی شوند. حتی اگر بررسی مانیفست‌ها بدون خطا انجام شود، ممکن است برخی ناسازگاری‌ها فقط هنگام اجرای واقعی سیستم آشکار شوند.
• دنبال‌کردن تغییرات پروژه‌های بالادستی (Upstream): پلتفرم‌های مبتنی بر کوبرنتیز معمولا از چند پروژه متن‌باز تشکیل شده‌اند. تغییراتی مانند انتشار نسخه‌های جدید، ارائه اصلاحیه‌های امنیتی یا پایان پشتیبانی هر یک از این پروژه‌ها می‌تواند تیم را به ارتقا یکی از اجزای پلتفرم ملزم کند.
• آزمایش و پایش پس از تغییرات: تغییرات باید پیش از استقرار بررسی شوند و پس از اجرا هم عملکرد سرویس‌ها در محیط واقعی پایش شود؛ زیرا برخی ناسازگاری‌ها فقط هنگام اجرا یا پس از گذشت زمان آشکار می‌شوند.

حجم بار نگهداری چقدر است؟

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

Munib Ali، مدیر مهندسی SRE در Fairwinds، می‌گوید در بسیاری از استقرارهای متوسط EKS (مخفف Amazon Elastic Kubernetes Service، سرویس مدیریت‌شده کوبرنتیز در زیرساخت ابری AWS)، انجام یک ارتقا Minor در سه منطقه (Region) می‌تواند چهار تا شش هفته تلاش مهندسی مصرف کند و توسعه دو تا سه قابلیت در سطح نقشه راه را به تعویق اندازد. این عدد که یک مشاهده تجربی از سوی Fairwinds است، به شرایط محیط بستگی دارد و نباید به همه کلاسترهای کوبرنتیز تعمیم داده شود

همچنین Jehoszafat Zimnowoda و Matthias Erll، مهندسان ارشد نرم‌افزار در Akamai، انتشارهای سه سال گذشته ۱۴ پروژه متن‌باز را بررسی کرده‌اند. بر اساس تجربه و تحلیل آن‌ها، یک پلتفرم متکی به این مجموعه پروژه‌ها ممکن است در هر سال با ۲ تا ۵ ارتقا اصلی، ۴۳ تا ۵۲ ارتقا فرعی و ۲۷۶ تا ۳۲۷ اصلاحیه روبه‌رو شود. این داده هم به همان پروژه‌های بررسی‌شده مربوط است و معیار عمومی همه پلتفرم‌های کوبرنتیز نیست.

چرا ارتقا کوبرنتیز پیچیده‌تر از یک ارتقا نسخه (Version Bump) است؟

چند عامل فنی مانند تغییر APIها، وابستگی میان نسخه اجزای مختلف کلاستر و بررسی سازگاری افزونه‌ها (Add-on) و چارت‌های Helm باعث می‌شوند فرایند ارتقا کلاستر کوبرنتیز، پیچیده‌تر از یک به‌روزرسانی ساده باشد. 

تغییر و حذف APIها

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

مهاجرت APIهای منسوخ‌شده کوبرنتیز ممکن است به تغییر فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌های سفارشی نیاز داشته باشد. مستندات رسمی، ابزار kubectl convert را نیز برای تبدیل خودکار بعضی منابع معرفی می‌کنند؛ بااین‌حال، این تبدیل ممکن است از مقادیر پیش‌فرض نامناسب استفاده کند و نتیجه آن باید با مراجعه به مستندات API همان منبع بررسی شود.

وابستگی میان نسخه اجزا

پروژه کوبرنتیز شاخه‌های سه نسخه Minor اخیر را نگهداری می‌کند و نسخه‌های ۱.۱۹ به بعد تقریباً یک سال پشتیبانی از Patch دریافت می‌کنند. بنابراین، باقی‌ماندن روی نسخه‌های قدیمی نمی‌تواند برای مدتی نامحدود ادامه پیدا کند و برنامه ارتقا باید چرخه پشتیبانی کوبرنتیز را در نظر بگیرد.

اجزای مختلف کلاستر همچنین باید از قواعد اختلاف نسخه (Version Skew؛ محدوده مجاز تفاوت نسخه میان اجزای مختلف کوبرنتیز) پیروی کنند. برای مثال، kubelet نباید از kube-apiserver جدیدتر باشد و می‌تواند حداکثر سه نسخه Minor از آن قدیمی‌تر باشد. kube-proxy نیز نباید از kube-apiserver جدیدتر باشد و باید محدودیت اختلاف نسخه با kube-apiserver و kubelet را رعایت کند.

این محدودیت‌ها بر ترتیب ارتقا اثر می‌گذارند. ابتدا kube-apiserver ارتقا پیدا می‌کند. در کلاسترهای دارای دسترس‌پذیری بالا، تمام نمونه‌های kube-apiserver که سایر اجزای Control Plane ممکن است با آن‌ها ارتباط برقرار کنند، باید پیش از ارتقا kube-controller-manager، ‏kube-scheduler و cloud-controller-manager ارتقا یافته باشند. پس از آن، kubelet و kube-proxy را می‌توان با رعایت محدوده مجاز اختلاف نسخه ارتقا داد.

ناسازگاری Add-onها و Helm Chartها

ارتقا افزونه‌ها و هلم چارت‌ها هم می‌تواند با چالش‌هایی همراه باشد. برخی نسخه‌های جدید هلم چارت تغییراتی در فیلدهای تغییرناپذیر (Immutable Fields) منابع کوبرنتیز ایجاد می‌کنند که می‌تواند فرایند ارتقا را با مشکل مواجه کند.

همه مشکلات در مرحله بررسی مانیفست‌ها مشخص نمی‌شوند و بعضی ناسازگاری‌ها فقط هنگام اجرای واقعی سامانه آشکار می‌شوند. پیش از اعمال تغییرات، می‌توان مانیفست‌های رندرشده نسخه فعلی و نسخه جدید را با یکدیگر مقایسه کرد، آن‌ها را با طرح‌واره OpenAPI (همان OpenAPI schema) کوبرنتیز و CRDهای اضافه‌شده سنجید و تغییرات را به‌صورت Dry Run (بررسی آزمایشی یک تغییر، بدون اعمال و ذخیره‌کردن واقعی آن در کلاستر) در برابر کلاستر در حال اجرا بررسی کرد.

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

چگونه بار نگهداری را ساختاریافته‌تر کنیم؟

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

• خودکارسازی شناسایی نسخه‌های جدید و ایجاد درخواست تغییر (Pull Request): بخشی از فرایند شناسایی نسخه‌های جدید پروژه‌های متن‌باز و هلم چارت‌ها را می‌توان خودکار کرد تا پس از انتشار نسخه جدید، یک درخواست تغییر برای بررسی و اعمال به‌روزرسانی ایجاد شود.
• شناسایی APIهای منسوخ‌شده: مستندات رسمی کوبرنتیز استفاده از هشدارهای کلاینت، معیارها و اطلاعات Audit را برای یافتن وابستگی به APIهای منسوخ‌شده پیشنهاد می‌کنند. پس از شناسایی این وابستگی‌ها، فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌های سفارشی باید پیش از حذف نسخه قدیمی به APIهای منسوخ‌نشده مهاجرت کنند.
• اعتبارسنجی مانیفست‌های رندرشده پیش از اعمال تغییرات: می‌توان تمام مانیفست‌هایی را که پلتفرم مستقر می‌کند با طرح‌واره OpenAPI کوبرنتیز و CRDهای اضافه‌شده اعتبارسنجی کرد. مقایسه مانیفست‌های نسخه فعلی و نسخه جدید و اجرای Dry Run در برابر کلاستر در حال اجرا نیز می‌تواند تغییرات مخرب احتمالی را پیش از اعمال آن‌ها آشکار کند
• اجرای تست‌های یکپارچگی و پایش پس از ارتقا: اجرای موفق فرایند استقرار، به‌تنهایی تضمین نمی‌کند که سامانه همچنان مطابق انتظار عمل می‌کند. به همین دلیل، اجرای تست‌های یکپارچگی روی کلاسترِ در حال اجرا و پایش مداوم سامانه پس از ارتقا، بخشی از فرایند نگهداری محسوب می‌شود.

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

مدیریت داخلی کوبرنتیز چه زمانی توجیه دارد؟

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

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

چگونه واگذاری نگهداری کوبرنتیز ظرفیت تیم داخلی را آزاد می‌کند؟

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

در سازمان‌هایی که تمایلی به مدیریت مستقیم همه فعالیت‌های عملیاتی کوبرنتیز ندارند، استفاده از خدمات مدیریت‌شده کوبرنتیز (Kubernetes as a Service یا KaaS) هم می‌تواند یکی از گزینه‌های قابل بررسی باشد. البته قابلیت‌ها و مسئولیت‌های هر سرویس مدیریت‌شده به ارائه‌دهنده آن بستگی دارد و باید بر اساس مستندات رسمی همان سرویس ارزیابی شود.

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

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

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

The post مدیریت داخلی ارتقا کوبرنتیز چه هزینه‌ای دارد؟ بررسی نقش کوبرنتیز مدیریت‌شده appeared first on بلاگ هم‌روش.

چرا مدیریت چند کلاستر کوبرنتیز دشوار است؟

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

• پراکندگی تنظیمات و پیکربندی: در مدیریت ایستای چند کلاستر، تیم‌ها ممکن است ناچار شوند قواعد Placement، یعنی قواعد انتخاب کلاستر مقصد و نحوه توزیع بار کاری، را به‌صورت ثابت تعریف کنند. همچنین باید مانیفست‌های مشابهی برای تعریف منابع و تنظیمات بار کاری بسازند و چند Context را مدیریت کنند. هر Context مجموعه‌ای از تنظیمات Kubeconfig است که کلاستر، کاربر و Namespace هدف را مشخص می‌کند. با افزایش تعداد کلاسترها، هماهنگ نگه‌داشتن این تعاریف و مقصدهای استقرار دشوارتر می‌شود.
• دشواری انتخاب محل اجرای بار کاری: انتخاب کلاستر مقصد فقط به نام یا موقعیت آن محدود نیست و ممکن است به ظرفیت در دسترس، Affinity (قواعد ترجیح یا الزام برای انتخاب محل اجرای بار کاری) و قواعد توزیع بار کاری وابسته باشد. با تغییر وضعیت کلاسترها، قواعد ثابت یا انتخاب دستی نمی‌توانند همیشه مقصد مناسبی را برای اجرای بار کاری تعیین کنند.
• نبود Failover خودکار: داشتن چند کلاستر به‌تنهایی باعث نمی‌شود بارهای کاری یک کلاستر ناموفق در کلاستر سالم دیگری اجرا شوند. بدون یک سازوکار ارکستریشن یا فرایند عملیاتی مشخص، تیم باید مقصد استقرار را تغییر دهد و اجرای مجدد بار کاری را مدیریت کند.

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

Karmada چیست؟

کارمادا (Karmada)، کوتاه‌شده عبارت Kubernetes Armada، یک سیستم مدیریت و ارکستریشن چندکلاستری برای کوبرنتیز است. این سیستم امکان اجرای برنامه‌های Cloud-Native را در چند کلاستر و چند محیط ابری فراهم می‌کند، بدون آنکه برای این منظور لازم باشد تعریف اصلی برنامه‌ها تغییر کند.

کلاسترهای عضو کارمادا می‌توانند در ابر عمومی، دیتاسنتر خصوصی یا محیط Edge قرار داشته باشند. کارمادا با APIهای بومی کوبرنتیز کار می‌کند و یک کنترل‌پلین (Control Plane) بالاتر از کلاسترهای عضو در اختیار تیم قرار می‌دهد تا تعریف بارهای کاری و قواعد توزیع آن‌ها به‌صورت متمرکز مدیریت شود.

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

کارمادا یک پروژه Incubating در بنیاد CNCF است. این عنوان وضعیت بلوغ و پذیرش پروژه را در چرخه CNCF نشان می‌دهد و به معنای بتا بودن نرم‌افزار نیست. برای آشنایی بیشتر با این پروژه، می‌توانید به وب‌سایت رسمی Karmada مراجعه کنید.

معماری کارمادا چگونه کار می‌کند؟

معماری کارمادا بر یک کنترل‌پلین مرکزی استوار است که منابع، سیاست‌ها و تصمیم‌های مربوط به توزیع بارهای کاری را مدیریت می‌کند. API Server نقطه ورود درخواست‌ها و APIهای کارمادا است و etcd اشیای API را نگهداری می‌کند. Controller Manager مجموعه‌ای از کنترل‌گرها را اجرا می‌کند که منابع کارمادا را مشاهده و عملیات لازم برای انتشار آن‌ها در کلاسترهای عضو را هماهنگ می‌کنند. Scheduler هم بر اساس سیاست‌های تعریف‌شده، دربارهٔ محل اجرای بارهای کاری در کلاسترهای عضو تصمیم می‌گیرد و به عبارتی فرایند زمان‌بندی را انجام می‌دهد.

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

• مرحله ۱: کاربر یک منبع کوبرنتیز، مانند Deployment را در کنترل‌پلین کارمادا تعریف می‌کند.
• مرحله ۲: سیاست انتشار (PropagationPolicy) مشخص می‌کند چه منابعی انتخاب شوند و در کدام کلاسترها انتشار یابند.
• مرحله ۳: Scheduler بر اساس سیاست و اطلاعات کلاسترها درباره محل اجرای منبع تصمیم می‌گیرد.
• مرحله ۴: نتیجه Scheduler در یک ResourceBinding ثبت می‌شود.
• مرحله ۵: کنترل‌گرهای کارمادا بر اساس این Binding، منابع Work موردنیاز کلاسترهای مقصد را ایجاد می‌کنند.
• مرحله ۶: منابع تعریف‌شده از طریق Work در کلاسترهای عضو مقصد اعمال می‌شوند و بار کاری در آن کلاسترها اجرا می‌شود.

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

کارمادا از دو مدل برای اتصال کلاسترهای عضو پشتیبانی می‌کند. در حالت Push، کنترل‌پلین مستقیماً به API Server کلاستر عضو (Member Cluster) متصل می‌شود و منابع را در آن منتشر می‌کند. در حالت Pull، مؤلفه karmada-agent داخل کلاستر عضو اجرا می‌شود، از همان‌جا با کنترل‌پلین ارتباط برقرار می‌کند و منابع تخصیص‌یافته را دریافت و در کلاستر عضو اجرا می‌کند. این عامل جزء ثابت کنترل‌پلین نیست و فقط در مدل Pull کاربرد دارد. انتخاب میان این دو مدل به توپولوژی شبکه، محدودیت‌های فایروال و الزامات امنیتی بستگی دارد.

قابلیت‌ها و کاربردهای اصلی Karmada

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

استقرار بارهای کاری بر اساس سیاست انتشار (Policy)

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

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

توزیع Replicaها میان کلاسترها

در حالت Duplicated، تعداد Replica تعریف‌شده در هر کلاستر مقصد ایجاد می‌شود. برای مثال، اگر یک Deployment با ۵ عدد Replica در ۳ کلاستر توزیع شود، هر کلاستر، ۵ عدد Replica و در مجموع ۱۵ عدد Replica دریافت می‌کند.

در حالت Divided، تعداد کل Replicaها میان کلاسترهای مقصد تقسیم می‌شود. برای مثال، اگر تعداد کل ۱۵ عدد Replica باشد و ۳ کلاستر با شرایط یکسان انتخاب شوند، ممکن است در هر کلاستر ۵ عدد Replica اجرا شود. این توزیع می‌تواند با توجه به سیاست و وضعیت منابع کلاسترها متفاوت باشد.

اعمال تنظیمات متفاوت برای هر کلاستر

یک مانیفست یکسان همیشه برای تمام کلاسترها مناسب نیست. ممکن است StorageClass ،Container Registry ،IngressClass ،Annotationهای وابسته به Cloud Provider یا تنظیمات مرتبط با Region در کلاسترهای مختلف تفاوت داشته باشند.

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

Failover

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

انتقال بار کاری به کلاستر دیگر، به‌تنهایی بازیابی کامل برنامه‌های Stateful را تضمین نمی‌کند. اگر هنگام اختلال شبکه، برنامه هم‌زمان در کلاستر مبدأ و مقصد فعال بماند، ممکن است هر دو نسخه به‌طور مستقل، داده‌ها را تغییر دهند و باعث ناسازگاری یا خرابی داده شوند؛ وضعیتی که به آن Split-Brain می‌گویند. علاوه بر جلوگیری از این وضعیت، کلاستر مقصد نیز باید ظرفیت کافی برای اجرای بار کاری منتقل‌شده داشته باشد.

سناریوهای کاربردی

سناریوهای کاربرد کارمادا شامل Multi-Cloud ،Hybrid Cloud ،Cloud Bursting، بازیابی بار کاری پس از خرابی یک کلاستر، استقرار جغرافیایی و کاهش دامنه خرابی از طریق توزیع بارهای کاری میان چند کلاستر است.

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

تفاوت GitOps با کارمادا چیست؟

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

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

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

کارمادا و GitOps می‌توانند در کنار یکدیگر استفاده شوند. برای مثال، ابزار GitOps می‌تواند بارهای کاری، سیاست‌های انتشار (PropagationPolicy) و سیاست‌های بازنویسی (OverridePolicy) را با کنترل‌پلین کارمادا همگام کند و کارمادا هم محل اجرا و انتشار آن‌ها در کلاسترهای عضو را بر عهده بگیرد.

مزایا و محدودیت‌های کارمادا

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

مزایای کارمادا

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

• سازگاری با APIهای Kubernetes: کارمادا با APIها و منابع آشنای کوبرنتیز کار می‌کند و می‌تواند با ابزارهای موجود این اکوسیستم یکپارچه شود.
• مدیریت متمرکز چند کلاستر: بارهای کاری، سیاست‌ها و تصمیم‌های محل اجرا از طریق کنترل‌پلین کارمادا مدیریت می‌شوند.
• جداسازی تعریف بار کاری از قواعد استقرار: می‌توان یک بار کاری را مستقل از محل اجرای آن تعریف کرد و بعدا با سیاست‌های جداگانه مشخص کرد که در چه کلاسترهایی اجرا شود.
• توزیع و زمان‌بندی Replicaها: کارمادا از توزیع Duplicated و Divided پشتیبانی می‌کند و می‌تواند Replicaهای یک بار کاری را بر اساس سیاست میان کلاسترهای مقصد توزیع کند.
• پشتیبانی از معماری‌های Multi-Cloud و Hybrid Cloud: کارمادا برای اجرای بارهای کاری در چند ابر یا ترکیب ابر عمومی و دیتاسنتر خصوصی طراحی شده است.
• سازگاری با ابزارهای موجود کوبرنتیز: کارمادا را می‌توان در کنار ابزارهای دیگر اکوسیستم کوبرنتیز به کار گرفت.
• کاهش وابستگی در لایه هماهنگ‌سازی: کارمادا می‌تواند توزیع بارهای کاری میان چند محیط ابری را از سازوکار اختصاصی یک ارائه‌دهنده ابر مستقل‌تر کند. بااین‌حال، وابستگی اپلیکیشن به سرویس‌های اختصاصی هر ارائه‌دهنده را به‌طور خودکار از بین نمی‌برد.

محدودیت‌های کارمادا

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

• اضافه‌شدن یک کنترل‌پلین جدید: API Server، ذخیره‌ساز داده، کنترل‌گرها و اجزای زمان‌بندی این لایه باید ایمن‌سازی، پایش، پشتیبان‌گیری و نگهداری شوند.
• افزایش پیچیدگی مانیتورینگ و عیب‌یابی: ممکن است که بررسی علت یک مشکل نیازمند بررسی هم‌زمان کلاستر عضو و کنترل‌پلین کارمادا باشد.
• نیاز به طراحی دقیق ارتباط شبکه: اتصال کنترل‌پلین به کلاسترهای عضو، مخصوصا وقتی کلاسترها در شبکه‌ها یا محیط‌های مختلف باشند، نیازمند طراحی جداگانه است.
• پیچیده‌ترشدن RBAC و مدیریت دسترسی: با اضافه‌شدن یک لایه مدیریتی جدید، مدیریت مجوزهای دسترسی هم پیچیده‌تر می‌شود.
• افزایش فشار عملیاتی در خرابی گسترده: خرابی یک کلاستر بزرگ می‌تواند باعث زمان‌بندی مجدد هم‌زمان تعداد زیادی بار کاری و افزایش فشار بر کنترل‌پلین کارمادا و سرور API کلاسترهای سالم شود.
• عدم حل خودکار مسائل ذخیره‌سازی و Replication داده: کارمادا مشکلات مربوط به فضای ذخیره‌سازی یا همگام‌سازی داده‌ها را به‌صورت خودکار حل نمی‌کند.
• نیاز به تیم مسلط به کوبرنتیز و سیستم‌های توزیع‌شده: استفاده مؤثر از کارمادا نیازمند دانش کافی در هر دو حوزه است.

راه‌اندازی و شروع کار با کارمادا

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

مراحل کلی راه‌اندازی کارمادا

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

• آماده‌سازی یک کلاستر Kubernetes برای میزبانی کنترل‌پلین کارمادا
• نصب اجزای کنترل‌پلین، از جمله API Server ،Controller Manager ،Scheduler و etcd
• آماده‌سازی Kubeconfig مربوط به کارمادا
• اتصال کلاسترهای عضو به روش Push یا Pull
• بررسی سلامت و دسترس‌پذیری کلاسترهای عضو
• تعریف بار کاری در کنترل‌پلین کارمادا
• تعریف سیاست انتشار (PropagationPolicy) برای مشخص‌کردن کلاسترهای مقصد
• بررسی انتشار بار کاری در کلاسترهای عضو

روش‌های نصب کارمادا

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

توصیه برای ارزیابی اولیه

اگر هدفتان فقط آشنایی با کارمادا یا اجرای یک نمونه آزمایشی (Proof of Concept) است، می‌توانید از محیط توسعه رسمی استفاده کنید. کد منبع و اسکریپت راه‌اندازی محیط توسعه کارمادا در مخزن رسمی Karmada در GitHub در دسترس است. این محیط، Control Plane و کلاسترهای عضو آزمایشی را به‌صورت خودکار آماده می‌کند و فرایند یادگیری را ساده‌تر می‌سازد. البته این محیط برای توسعه و آزمایش طراحی شده است و الگوی مناسبی برای استقرار در محیط عملیاتی نیست.

چه زمانی کارمادا انتخاب مناسبی است؟

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

چه زمانی استفاده از کارمادا منطقی است؟

اگر شرایط زیر را دارید، کارمادا می‌تواند انتخاب مناسبی برای مدیریت زیرساخت شما باشد:

• چند کلاستر کوبرنتیز عملیاتی دارید و باید آن‌ها را به‌صورت متمرکز مدیریت کنید.
• مقصد اجرای بارهای کاری همیشه ثابت نیست و باید با توجه به شرایط، میان کلاسترهای مختلف انتخاب شود.
• در چند ابر، منطقه جغرافیایی یا دیتاسنتر فعالیت می‌کنید.
• به توزیع Replicaهای یک بار کاری میان چند کلاستر نیاز دارید.
• Failover در سطح کلاستر و اجرای مجدد بارهای کاری در کلاستر سالم، یکی از نیازهای واقعی شماست.
• تیم Platform Engineering یا SRE توانایی نگهداری و پایش یک Control Plane جدید را دارد.

چه زمانی کارمادا انتخاب مناسبی نیست؟

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

• فقط یک کلاستر یا چند کلاستر ساده دارید.
• مقصد استقرار بارهای کاری همیشه مشخص و ثابت است.
• ابزار GitOps فعلی تمام نیازهای شما را پوشش می‌دهد.
• چالش اصلی شما مدیریت فضای ذخیره‌سازی یا انتقال و همگام‌سازی داده‌هاست.
• تیم شما ظرفیت نگهداری، مانیتورینگ و عیب‌یابی یک Control Plane دیگر را ندارد.
• هنوز مسئله واقعی Multi-Cluster ندارید و صرفا به‌دلیل جذابیت فناوری به استفاده از آن فکر می‌کنید.

جمع‌بندی

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

این قابلیت‌ها می‌توانند در سناریوهای Multi-Cloud ،Hybrid Cloud، استقرار جغرافیایی متنوع و انتقال خودکار در زمان خرابی در سطح بار کاری مفید باشند. بااین‌حال، کارمادا یک کنترل‌پلین جدید به زیرساخت اضافه می‌کند و مسائل شبکه، ذخیره‌سازی و Replication داده را به‌تنهایی حل نمی‌کند.

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

The post کارمادا چیست؟ آشنایی با ابزار مدیریت چند کلاستر کوبرنتیز appeared first on بلاگ هم‌روش.

K9s ابزاری ترمینال‌محور برای کوبرنتیز است که مشاهده، پیمایش و مدیریت اپلیکیشن‌های مستقر روی کلاستر را ساده‌تر می‌کند. این ابزار با ارائه یک رابط کاربری مبتنی بر ترمینال، فرایند مشاهده (Observe)، پیمایش (Navigate) و مدیریت (Manage) منابع و اپلیکیشن‌های کوبرنتیز را ساده‌تر می‌کند تا بسیاری از عملیات روزمره، بدون نیاز به اجرای مکرر دستورهای مختلف، از طریق یک محیط یکپارچه انجام شوند. در این آموزش K9s، ابتدا به این سوال پاسخ می‌دهیم که K9s چیست و سپس به نحوه نصب، رابط کاربری، کارهای عملی با K9s و برخی قابلیت‌های پیشرفته آن را می‌پردازیم.

K9s چیست؟

K9s یک رابط کاربری متنی (Terminal-based UI) برای تعامل با کلاسترهای کوبرنتیز است که به‌طور کامل داخل ترمینال اجرا می‌شود. این ابزار مدیریت کوبرنتیز، با هدف ساده‌تر کردن مشاهده، پیمایش و مدیریت اپلیکیشن‌ها و منابع مستقر روی کلاستر توسعه یافته است. کد منبع و روند توسعه این ابزار در مخزن رسمی K9s در GitHub در دسترس است.

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

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

K9s چگونه با kubeconfig ،Kubernetes API و RBAC کار می‌کند؟

یکی از مزیت‌های K9s این است که برای اتصال به کلاستر کوبرنتیز از همان Kubernetes API استفاده می‌کند که ابزار kubectl هم بر پایه آن کار می‌کند. به همین دلیل، اگر kubeconfig معتبر باشد و context انتخاب‌شده امکان اتصال به کلاستر را داشته باشد، K9s می‌تواند از همان پیکربندی برای اتصال استفاده کند.

نکته مهم این است که K9s مجوز یا سیاست دسترسی مستقلی ایجاد نمی‌کند. این ابزار با استفاده از اطلاعات اتصال و احراز هویت موجود در kubeconfig به Kubernetes API متصل می‌شود و سطح دسترسی آن را مجوزهای تعریف‌شده در RBAC (مخفف Role-Based Access Control) کلاستر تعیین می‌کنند. بنابراین، کاربر یا ServiceAccount مرتبط با context فعال فقط می‌تواند عملیاتی را در K9s انجام دهد که طبق سیاست‌های RBAC اجازه انجام آن‌ها را دارد. برای مثال، اگر مجوز کاربر به مشاهده منابع محدود باشد، امکان ویرایش یا حذف آن‌ها را از طریق K9s نیز نخواهد داشت. به بیان دیگر، K9s محدودیت‌های دسترسی کوبرنتیز را دور نمی‌زند و در همان محدوده مجاز تعریف‌شده برای هویت فعلی کار می‌کند.

همچنین هنگام اجرای K9s، می‌توانید یک context مشخص از فایل kubeconfig را انتخاب کنید یا برنامه را به‌طور مستقیم در یک namespace خاص اجرا کنید.

تفاوت K9s و kubectl چیست؟

K9s و kubectl نقش یکسانی ندارند و K9s را نباید جایگزین کامل kubectl دانست. kubectl ابزار خط فرمان استاندارد کوبرنتیز است، اما K9s یک رابط کاربری متنی (Terminal-based UI) برای انجام سریع‌تر عملیات روزمره و تعاملی به شمار می‌آید. 

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

ازآنجایی‌که K9s کاملاً در ترمینال اجرا می‌شود، می‌توان آن را روی Bastion Host یا سرور واسطی اجرا کرد که کاربران از طریق SSH به آن متصل می‌شوند و از آنجا به کلاستر کوبرنتیز دسترسی دارند. در مقابل، اگر هدف خودکارسازی عملیات، استفاده در اسکریپت‌ها یا ادغام با فرایندهای CI/CD باشد، همچنان kubectl انتخاب اصلی است. جدول زیر مهم‌ترین تفاوت‌های این دو ابزار را نشان می‌دهد:

پیش‌نیازهای استفاده از K9s

پیش از نصب K9s، بهتر است مطمئن شوید محیط کاری شما برای اتصال به کلاستر کوبرنتیز آماده است. این ابزار روی سیستم‌عامل‌های لینوکس، macOS و ویندوز اجرا می‌شود. پیش‌نیازهای نصب و استفاده از این ابزار عبارت‌اند از:

• دسترسی به یک کلاستر کوبرنتیز فعال: پیش از هر چیز باید به یک کلاستر کوبرنتیز در حال اجرا دسترسی داشته باشید، زیرا K9s ابزاری برای تعامل با یک کلاستر موجود است، نه راه‌اندازی کلاستر جدید.
• پیکربندی دسترسی به کلاستر: باید kubeconfig معتبر و امکان اتصال به کلاستر را داشته باشید. در محیط کاری معمول، بهتر است پیش از اجرای K9s از امکان اتصال به کلاستر اطمینان پیدا کنید.
• فایل kubeconfig معتبر: فایل kubeconfig باید به‌درستی تنظیم و به کلاستر موردنظر متصل شده باشد تا K9s بدون نیاز به تنظیمات اضافی بتواند به آن متصل شود.
• دسترسی‌های لازم مطابق RBAC: چون سطح دسترسی K9s تابع همان قوانین RBAC تعریف‌شده برای کاربر است، باید مطمئن شوید مجوزهای لازم برای مشاهده یا مدیریت منابع موردنظرتان از قبل برایتان تعریف شده باشد.
• ترمینال با پشتیبانی از ۲۵۶ رنگ: K9s برای نمایش صحیح رابط کاربری به حالت ۲۵۶ رنگ ترمینال نیاز دارد. اکثر ترمینال‌های مدرن به‌صورت پیش‌فرض از این قابلیت پشتیبانی می‌کنند، اما در سیستم‌های مبتنی بر یونیکس مانند لینوکس و macOS، در صورت نیاز می‌توانید متغیر محیطی TERM را به‌صورت زیر تنظیم کنید:

 export TERM=xterm-256color

 export TERM=xterm-256color

• تنظیم EDITOR یا KUBE_EDITOR: برای ویرایش مستقیم منابع کوبرنتیز از داخل K9s، لازم است یکی از متغیرهای محیطی EDITOR یا KUBE_EDITOR روی ویرایشگر دلخواه شما تنظیم شده باشد، مثلاً:

export KUBE_EDITOR=vim

export KUBE_EDITOR=vim

روش‌های نصب K9s روی لینوکس، macOS و ویندوز

K9s روی سیستم‌عامل‌های لینوکس، macOS و ویندوز در دسترس است. می‌توانید علاوه بر استفاده از Package Manager، فایل‌های Binary رسمی را هم از صفحه انتشار (Release) پروژه دریافت و نصب کنید. همچنین در صورت نیاز، امکان کامپایل برنامه از سورس هم وجود دارد.

نصب K9s روی macOS

در مستندات رسمی، دو روش برای نصب K9s روی مک معرفی شده است:

برای نصب با Homebrew:

brew install derailed/k9s/k9s

brew install derailed/k9s/k9s

برای نصب با MacPorts:

sudo port install k9s

sudo port install k9s

نصب K9s روی لینوکس

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

برای نصب با LinuxBrew:

brew install derailed/k9s/k9s

brew install derailed/k9s/k9s

برای نصب با Pacman:

pacman -S k9s

pacman -S k9s

نصب K9s روی ویندوز

برای نصب K9s روی ویندوز مستندات رسمی K9s روش‌های زیر را پیشنهاد می‌کنند:

برای نصب با Scoop:

scoop install k9s

scoop install k9s

نصب با Chocolatey:

choco install k9s

choco install k9s

نصب K9s با Binary رسمی یا ساخت از روی سورس

اگر نمی‌خواهید از Package Manager استفاده کنید، می‌توانید فایل اجرایی متناسب با سیستم‌عامل خود را از صفحه انتشارهای رسمی K9s در GitHub دریافت کنید. فایل‌های رسمی K9s برای لینوکس، macOS و ویندوز در این صفحه در دسترس‌اند. همچنین، اگر قصد دارید K9s را از کد منبع بسازید، طبق مستندات نصب مورداستفاده در این مقاله باید Go نسخه ۱.۱۴ یا بالاتر روی سیستم نصب باشد. در این روش، ابتدا مخزن پروژه را Clone و سپس برنامه را با دستور زیر Build و اجرا کنید:

make build && ./execs/k9s

make build && ./execs/k9s

اجرای اولیه K9s و گزینه‌های مهم CLI

پس از اینکه فرایند نصب را انجام دادید، کافی است دستور k9s را اجرا کنید تا محیط تعاملی برنامه باز شود. در بخش بالای صفحه، اطلاعاتی مانند نام کلاستر، Context فعلی، نسخه کوبرنتیز و میزان مصرف CPU و Memory نمایش داده می‌شود. همچنین در بخش میانی، فهرست منابع کوبرنتیز قرار دارد و در پایین صفحه، مسیر پیمایش (Breadcrumb) و پیام‌های وضعیت دیده می‌شوند. هر زمان کلید : یا / را فشار دهید، نوار فرمان برای اجرای دستورها یا جستجو ظاهر می‌شود. 

نکته کاربردی دیگر این است که کنار نام هر Namespace، عددی نمایش داده می‌شود. در اینجا عدد ۰ نمایانگر همه Namespaceها است و اعداد دیگر به‌ترتیب به Namespaceهایی اختصاص پیدا می‌کنند که در همان نشست کاری بازدید کرده‌اید.

مستندات رسمی K9s چند گزینه مهم برای اجرای برنامه معرفی کرده است که در ادامه با آن‌ها آشنا می‌شوید.

مشاهده راهنما و اطلاعات برنامه

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

k9s help

k9s help

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

k9s info

k9s info

اجرای K9s در یک Namespace مشخص

اگر فقط قصد کار با یک Namespace خاص را دارید، می‌توانید K9s را به‌طور مستقیم در همان Namespace اجرا کنید:

k9s -n <namespace-name>

k9s -n <namespace-name>

اجرای K9s با گزینه -n باعث می‌شود برنامه کار را در namespace مشخص‌شده آغاز کند. این روش در کلاسترهای شلوغ، دسترسی به منابع namespace موردنظر را ساده‌تر می‌کند.

اجرای مستقیم در نمای پاد

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

k9s -c pod

k9s -c pod

اجرای K9s با Context دلخواه

اگر فایل kubeconfig شما شامل چند Context باشد، هنگام اجرای K9s، می‌توانید Context موردنظر را مشخص کنید:

k9s --context <context-name>

k9s --context <context-name>

این قابلیت زمانی مفید است که بین چند کلاستر کوبرنتیز جابه‌جا می‌شوید و نمی‌خواهید Context پیش‌فرض را تغییر دهید.

اجرای K9s در حالت فقط‌خواندنی

برای جلوگیری از هرگونه تغییر ناخواسته روی منابع، می‌توانید K9s را با گزینه --readonly اجرا کنید:

k9s --readonly

k9s --readonly

در این حالت، تمام دستورهای ویرایش، حذف و سایر عملیات تغییردهنده غیرفعال می‌شوند.

تغییر Context و Namespace در زمان اجرا

K9s علاوه بر گزینه‌های خط فرمان، امکان جابه‌جایی بین Contextها و Namespaceها را از داخل محیط برنامه هم فراهم می‌کند. برای مشاهده و تغییر Context فعال، دستور زیر را وارد کنید:

:ctx

:ctx

یا مستقیما به یک Context مشخص بروید:

:ctx <context-name>

:ctx <context-name>

برای تغییر Namespace هم کافی است بنویسید:

:ns

:ns

همچنین می‌توانید با ساختار :pod <namespace-name>، پادهای یک Namespace مشخص را مشاهده کنید. برای نمایش پادها در یک Context دیگر نیز از ساختار :pod @<context-name> استفاده کنید. اجرای دستور دوم، Context فعال K9s را نیز به Context مشخص‌شده تغییر می‌دهد. توجه داشته باشید که این دستور دوم، Context فعلی شما را هم تغییر می‌دهد.

آشنایی با رابط کاربری K9s

همان‌طور که در بخش قبل دیدیم، صفحه اصلی K9s شامل بخش بالایی (نام کلاستر، Context، نسخه کوبرنتیز و مصرف CPU/Memory)، جدول منابع در وسط و نوار پیمایش در پایین صفحه است. تصویر زیر نمونه‌ای از این چیدمان را در نمای پادها نشان می‌دهد:

نکته مهم درباره این رابط این است که میانبرهای نمایش‌داده‌شده در بالای صفحه، بسته به نوع منبعی که مشاهده می‌کنید تغییر می‌کنند. برای مثال، کلید s روی پادها به‌معنای Shell است، اما همین کلید روی دیپلویمنت‌ها به‌معنای Scale خواهد بود. به همین دلیل نیازی نیست این میانبرها را از قبل حفظ کنید، چون K9s همیشه میانبرهای مرتبط با نمای فعلی را نمایش می‌دهد.

دو میانبر کاربردی که بهتر است به خاطر بسپارید، ? و Ctrl+a هستند. کلید ? در هر بخشی از K9s راهنما را باز می‌کند و Ctrl+a فهرست تمام alias‌های منابع شناخته‌شده توسط K9s را نشان می‌دهد. اگر نام کوتاه یا alias یک منبع را نمی‌دانید، می‌توانید با فشردن Ctrl+a فهرست aliasهای موجود را مشاهده کنید.

برای جابه‌جایی در محیط K9s هم می‌توانید از کلیدهای جهت‌دار یا j/k (مشابه Vim) استفاده کنید. علاوه بر این‌ها، با فشردن Enter وارد یک منبع می‌شوید و با Esc به نمای قبلی بازمی‌گردید.

مشاهده و جابه‌جایی بین منابع کوبرنتیز در K9s

یکی از مهم‌ترین قابلیت‌های K9s، دسترسی سریع به منابع مختلف کوبرنتیز از طریق میانبرهای متنی (Resource Alias) است. به‌جای اجرای مداوم دستورهای kubectl، کافی است کلید : را فشار دهید و نام منبع موردنظر را وارد کنید تا همان نما در ترمینال باز شود. از پرکاربردترین میانبرهای K9s می‌توان به موارد زیر اشاره کرد:

اگر بخواهید فقط منابع یک Namespace مشخص را مشاهده کنید، می‌توانید هنگام ورود به نمای پاد، نام Namespace را هم مشخص کنید:

:pod kube-system

:pod kube-system

همچنین اگر بخواهید پادهای یک Context دیگر را ببینید، می‌توانید از دستور زیر استفاده کنید. این دستور، Context فعال را هم تغییر می‌دهد.

:pod @<context-name>

:pod @<context-name>

جابه‌جایی بین Context و Namespace

در محیط‌هایی که چند کلاستر یا Namespace در اختیار دارید، جابه‌جایی سریع میان آن‌ها اهمیت زیادی دارد. K9s این کار را با چند دستور ساده امکان‌پذیر می‌کند:

• :ctx برای مشاهده و تغییر Context
• :ctx <context-name> برای رفتن مستقیم به یک Context مشخص
• :ns برای مشاهده و تغییر Namespace

همچنین با فشردن کلید 0 می‌توانید منابع موجود در تمام Namespaceها را به‌صورت یکجا مشاهده کنید. این گزینه برای بررسی وضعیت کلی کلاستر بسیار کاربردی است.

جست‌وجو و فیلتر کردن منابع در K9s

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

برای فیلتر کردن منابع، کافی است کلید / را فشار دهید و عبارت موردنظر را وارد کنید. این فیلتر به‌صورت لحظه‌ای روی نمای فعلی اعمال می‌شود و تنها منابع منطبق با عبارت جست‌وجو را نمایش می‌دهد.

یکی از قابلیت‌های کاربردی K9s، پشتیبانی از عبارت‌های منظم (Regular Expression یا Regex) است؛ بنابراین می‌توانید چند الگو را به‌طور هم‌زمان جست‌وجو کنید. برای مثال، دستور زیر تمام منابعی را که نام آن‌ها با یکی از دو عبارت مشخص‌شده مطابقت داشته باشد، نمایش می‌دهد:

/fred|blee

/fred|blee

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

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

/!error

/!error

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

کارهای عملی با K9s؛ Logs ،Describe ،YAML ،Shell و Port Forward

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

اگر پاد چند کانتینر داشته باشد، ابتدا می‌توانید کانتینر موردنظر را انتخاب و سپس با کلید l لاگ آن را مشاهده کنید. همچنین در شرایطی که یک کانتینر دچار Crash شده و پس از راه‌اندازی مجدد، لاگ فعلی اطلاعات کافی در اختیار شما قرار نمی‌دهد، می‌توانید با استفاده از Shift+L لاگ کانتینر قبلی را مشاهده و علت بروز خطا را بررسی کنید.

نمونه‌ای از عیب‌یابی یک Deployment

فرض کنید یکی از Deploymentهای کلاستر با مشکل مواجه شده است. در K9s می‌توان مراحل عیب‌یابی را به‌ترتیب زیر انجام داد:

• با دستور :deploy به نمای دیپلویمنت‌ها بروید و دیپلویمنت موردنظر را انتخاب کنید.
• کلید d را فشار دهید و بخش Events را بررسی کنید تا علت اولیه خطا مشخص شود.
• با فشردن Enter، پادهای مربوط به آن دیپلویمنت را مشاهده و پادی را که در وضعیت Running نیست، انتخاب کنید.
• با کلید l، لاگ پاد را بررسی کنید تا خطاهایی مانند OOMKilled، نبود متغیرهای محیطی یا خطاهای ارتباطی را شناسایی کنید.
• در صورت نیاز، با کلید y فایل YAML منبع را مشاهده و تنظیمات آن را بررسی کنید.
• اگر مشکل مشخص شد، با کلید e منبع را ویرایش کرده و تغییرات را ذخیره کنید. K9s این تغییر را اعمال می‌کند و می‌توانید ری‌استارت شدن پاد را مشاهده کنید.
• به نمای دیپلویمنت بازگردید و مطمئن شوید Replicaها به وضعیت سالم بازگشته‌اند.

مانیتورینگ، قابلیت‌های پیشرفته، Pluginها، نکات Production و محدودیت‌ها

ابزار K9s در کنار عملیات روزمره مشاهده و مدیریت منابع، مجموعه‌ای از قابلیت‌های تکمیلی هم در اختیار کاربران قرار می‌دهد که از پایش لحظه‌ای وضعیت کلاستر تا امکان تعریف Plugin اختصاصی را پوشش می‌دهند. در ادامه، این قابلیت‌ها را به همراه نکاتی برای استفاده در محیط Production و محدودیت‌های K9s بررسی می‌کنیم.

مشاهده زنده وضعیت منابع و متریک‌ها

K9s فعالیت منابع کلاستر و متریک‌های مرتبط با پادها، کانتینرها و نودها را به‌صورت زنده نمایش می‌دهد. در استفاده روزمره، یکی از اولین کارهایی که بسیاری از مدیران کلاستر انجام می‌دهند، بررسی سلامت کلی محیط است. برای این منظور می‌توان با دستور :pulses نمایی خلاصه از وضعیت کلاستر مشاهده کرد. این نما تعداد دیپلویمنت‌ها، پادها، StatefulSetها، DaemonSetها و جاب‌ها را نمایش می‌دهد و مشخص می‌کند چه تعداد از آن‌ها با مشکل مواجه هستند.

پس از آن، معمولا وضعیت نودها با دستور :node بررسی می‌شود تا مشخص شود که آیا همه نودها در وضعیت Ready قرار دارند یا خیر. همچنین وجود وضعیت‌هایی مانند MemoryPressure یا DiskPressure می‌تواند نشانه بروز مشکل در اجرای Workloadها باشد.

در ادامه هم با ورود به نمای پادها و فشردن کلید 0 برای نمایش همه Namespaceها، می‌توان ستون STATUS را بررسی کرد و پادهایی را که در وضعیت‌هایی مانند CrashLoopBackOff ،Error ،Pending یا ImagePullBackOff قرار دارند، به‌سرعت شناسایی کرد.

نکته مهم این است که K9s برای مشاهده و بررسی تعاملی وضعیت فعلی کلاستر کاربرد دارد؛ اما برای ذخیره‌سازی و تحلیل تاریخچه متریک‌ها، ساخت داشبورد و هشداردهی مستمر طراحی نشده است. برای این کاربردها باید از ابزارهای تخصصی مانند Prometheus و Grafana استفاده کرد.

Pulses ،XRay و RBAC

K9s چند قابلیت پیشرفته برای تحلیل وضعیت کلاستر هم در اختیار کاربران قرار می‌دهد. قابلیت Pulses یک داشبورد سطح بالا از وضعیت کلی کلاستر ارائه می‌کند و برای بررسی سریع سلامت منابع بسیار کاربردی است. همان‌طور که در بخش قبل اشاره شد، اجرای دستور :pulses دید مناسبی از وضعیت دیپلویمنت‌ها، پادها و سایر منابع در اختیار مدیر کلاستر قرار می‌دهد.

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

:xray deploy

:xray deploy

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

Popeye در K9s

با اجرای دستور :popeye می‌توانید بررسی کلاستر را براساس مجموعه‌ای از Best Practiceها آغاز کنید:

:popeye

:popeye

این قابلیت مواردی مانند نبود Probeهای لازم، مشکلات ایمیج‌ها، تخصیص نامناسب منابع و پیکربندی نادرست RBAC را بررسی و نتیجه را با وضعیت‌هایی مانند OK ،Info ،Warn یا Error نمایش می‌دهد.

Pluginها در K9s

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

$XDG_CONFIG_HOME/k9s/plugins.yaml

$XDG_CONFIG_HOME/k9s/plugins.yaml

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

$XDG_CONFIG_HOME/k9s/plugins
$XDG_DATA_HOME/k9s/plugins
$XDG_DATA_DIRS/k9s/plugins

$XDG_CONFIG_HOME/k9s/plugins
$XDG_DATA_HOME/k9s/plugins
$XDG_DATA_DIRS/k9s/plugins

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

$XDG_DATA_HOME/k9s/clusters/<cluster-name>/<context-name>/plugins.yaml

$XDG_DATA_HOME/k9s/clusters/<cluster-name>/<context-name>/plugins.yaml

در این مسیر، <cluster-name> و <context-name> مقادیر جایگزین‌شدنی هستند و باید با نام کلاستر و Context موردنظر جایگزین شوند. هر Plugin می‌تواند شامل میانبر اجرا، توضیح، دامنه منابع، فرمان اجرایی و آرگومان‌های موردنیاز باشد. گزینه scopes مشخص می‌کند که Plugin در نمای کدام منابع فعال باشد. برای مثال، اگر مقدار آن روی pods تنظیم شود، میانبر Plugin در نمای پادها در دسترس خواهد بود.

نمونه زیر یک Plugin برای اجرای فرمان kubectl debug روی پاد انتخاب‌شده تعریف می‌کند:

plugins:
  debug:
    shortCut: Shift-D
    description: Debug pod
    scopes:
      - pods
    command: kubectl
    background: false
    args:
      - debug
      - -it
      - $NAME
      - -n
      - $NAMESPACE
      - --image=busybox

plugins:
  debug:
    shortCut: Shift-D
    description: Debug pod
    scopes:
      - pods
    command: kubectl
    background: false
    args:
      - debug
      - -it
      - $NAME
      - -n
      - $NAMESPACE
      - --image=busybox

در این مثال، با فشردن میانبر Shift+D در نمای پادها، فرمان تعریف‌شده برای Pod انتخاب‌شده اجرا می‌شود. متغیر $NAME نام منبع انتخاب‌شده و $NAMESPACE نام Namespace آن را در اختیار فرمان قرار می‌دهد. K9s متغیرهای دیگری مانند $CONTEXT و $CLUSTER را نیز برای استفاده در آرگومان‌های Plugin ارائه می‌کند. به این ترتیب، می‌توان فرمان‌هایی تعریف کرد که بر اساس منبع انتخاب‌شده، Namespace ،Context یا کلاستر فعال اجرا شوند.

نکات استفاده از K9s در محیط Production

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

مهم‌ترین توصیه، اجرای برنامه در حالت فقط‌خواندنی است:

k9s --readonly

k9s --readonly

در این حالت، تمام عملیات‌های تغییردهنده مانند Edit ،Delete و Kill غیرفعال می‌شوند و تنها امکان مشاهده منابع وجود دارد. همچنین هنگام حذف منابع باید به تفاوت میان دو میانبر توجه داشت. کلید Ctrl+d قبل از حذف، از کاربر تایید می‌گیرد، اما Ctrl+k منبع را بدون نمایش پیام تأیید حذف می‌کند؛ بنابراین در محیط Production استفاده از Ctrl+d گزینه ایمن‌تری است.

ازآنجایی‌که K9s کاملاً در ترمینال اجرا می‌شود، می‌توانید آن را از طریق SSH روی Bastion Host یا Jump Server نیز اجرا کنید. این موضوع در بسیاری از زیرساخت‌های سازمانی مزیت مهمی محسوب می‌شود.

در کلاسترهای بزرگ که تعداد زیادی پاد در حال اجراست، می‌توانید مقدار refreshRate را در فایل تنظیمات افزایش دهید تا فاصله زمانی میان به‌روزرسانی‌ها بیشتر شود. همچنین می‌توانید K9s را با گزینه -n در Namespace موردنظر اجرا کنید:

k9s -n <namespace-name>

k9s -n <namespace-name>

در این دستور، <namespace-name> باید با نام Namespace موردنظر جایگزین شود. شروع کار در یک Namespace مشخص، دسترسی به منابع همان Namespace را در کلاسترهای شلوغ ساده‌تر می‌کند.

در نهایت، اگر اعضای تیم به‌صورت مشترک از K9s استفاده می‌کنند، می‌توانید فایل‌های تنظیمات، میانبرها، Pluginها و Skinهای سفارشی را در یک مخزن Git نگهداری کنید تا امکان به‌اشتراک‌گذاری و هماهنگ‌سازی این تنظیمات میان اعضای تیم فراهم شود.

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

K9s با وجود قابلیت‌های متعدد، محدودیت‌هایی نیز دارد که بهتر است پیش از استفاده از این ابزار از آن‌ها آگاه باشید. مهم‌ترین محدودیت این است که K9s برای Automation طراحی نشده است. خروجی آن قابل استفاده در Scriptها نیست و نمی‌توان از آن در Pipelineهای CI/CD یا Cron Jobها استفاده کرد. برای این سناریوها همچنان kubectl ابزار اصلی به شمار می‌آید.

همچنین ناوبری K9s تا حدی از Vim الهام گرفته است؛ بنابراین اگر قبلا با کلیدهایی مانند k ،j یا فرمان‌های مبتنی بر : کار نکرده باشید، ممکن است در روزهای نخست برای یادگیری نحوه کار با آن به کمی زمان نیاز داشته باشید. از دیگر محدودیت‌ها می‌توان به موارد زیر اشاره کرد:

• امکان مشاهده هم‌زمان دو کلاستر در یک پنجره وجود ندارد و برای مقایسه آن‌ها باید دو نمونه جداگانه از K9s را اجرا کنید.
• Port Forwardهایی که در K9s ایجاد می‌شوند، پس از بسته‌شدن برنامه متوقف می‌شوند. برای اتصال‌های پایدارتر باید از روش دیگری مانند kubectl port-forward استفاده کنید.
• K9s برای دنبال‌کردن هم‌زمان لاگ چند پاد یا کانتینر طراحی نشده است و در هر نوبت، لاگ یک کانتینر را نمایش می‌دهد.
• K9s قابلیت نگهداری History یا ارسال Alert ندارد و اگر بخواهید اطلاعاتی مانند لاگ‌ها یا خروجی Viewها را نگه دارید، باید قبل از خروج با Ctrl+s آن‌ها را ذخیره کنید.
• اگرچه Pluginهای آماده‌ای برای K9s وجود دارد، اما تعداد آن‌ها محدود است و با وجود Pluginهای آماده، ممکن است برای پوشش نیازهای اختصاصی تیم به تعریف Plugin سفارشی نیاز داشته باشید.

جمع‌بندی

در این راهنمای K9s توضیح دادیم که این ابزار چگونه مشاهده، پیمایش و مدیریت تعاملی منابع کوبرنتیز را از داخل ترمینال ساده‌تر می‌کند. K9s با دنبال‌کردن مداوم تغییرات کلاستر، انجام کارهای روزمره‌ای مانند بررسی پادها، مشاهده لاگ‌ها، اجرای describe و جابه‌جایی میان Namespaceها را سریع‌تر می‌کند.

بااین‌حال، K9s جایگزین کامل kubectl نیست. برای اسکریپت‌نویسی، فرایندهای CI/CD و خودکارسازی عملیات همچنان باید از ابزارهایی مانند kubectl استفاده کنید. K9s همچنین قابلیت نگهداری تاریخچه داده‌ها یا ارسال هشدار را فراهم نمی‌کند.

استفاده از K9s در محیط‌های Production باید با احتیاط همراه باشد. اجرای برنامه در حالت readonly، توجه به مجوزهای تعریف‌شده در RBAC و دقت در عملیات مخربی مانند Delete یا Kill می‌تواند احتمال ایجاد تغییرات ناخواسته در کلاستر را کاهش دهد.

The post آموزش K9s؛ راهنمای نصب و استفاده از ابزار مدیریت کوبرنتیز در ترمینال appeared first on بلاگ هم‌روش.

نکته مهم اینجاست که وجود CPU آزاد روی نود، لزوما به این معنا نیست که همه کانتینرها بدون محدودیت از منابع پردازشی استفاده می‌کنند. حتی اگر بخشی از ظرفیت پردازشی نود هنوز آزاد باشد، اعمال CPU Limit می‌تواند باعث CPU Throttling در سرویس‌های حساس به تاخیر شود. در ادامه بررسی می‌کنیم که CPU Request و CPU Limit در کوبرنتیز چه تفاوتی با هم دارند، کوبرنتیز هرکدام را در چه مرحله‌ای به کار می‌گیرد و چرا این تنظیم به‌ظاهر ساده می‌تواند تاثیر زیادی بر عملکرد سرویس‌ها داشته باشد.

CPU Request و CPU Limit در کوبرنتیز چه تفاوتی دارند؟

CPU Request و CPU Limit دو کاربرد متفاوت دارند. CPU Request مشخص می‌کند یک پاد برای اجرا به چه میزان CPU نیاز دارد. کوبرنتیز هنگام انتخاب نود (در فرایند Scheduling)، بررسی می‌کند که با توجه به Request پادهای مستقرشده، کدام نود ظرفیت کافی برای پاد جدید دارد. در این تصمیم، مصرف لحظه‌ای CPU ملاک نیست؛ بنابراین ممکن است CPU یک نود در عمل کم‌مصرف باشد، اما به‌دلیل مجموع Requestهای ثبت‌شده، پاد جدید روی آن اجرا نشود.

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

برای درک بهتر تفاوت Request و Limit، در مثال زیر مقدار منابع موردنیاز کانتینر برای انتخاب نود و همچنین سقف مصرف آن پس از اجرا مشخص شده است:

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: web
      image: nginx
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "1"
          memory: "512Mi"

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: web
      image: nginx
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "1"
          memory: "512Mi"

در این مثال:

• requests.cpu: 500m یعنی پاد برای زمان‌بندی به نیم هسته CPU نیاز دارد.
• requests.memory: 512Mi یعنی Scheduler باید نودی را انتخاب کند که بتواند حداقل 512Mi حافظه را برای این پاد در نظر بگیرد.
• limits.cpu: 1 یعنی کانتینر در زمان اجرا نمی‌تواند بیش از یک هسته CPU مصرف کند.
• limits.memory: 512Mi سقف مصرف حافظه را مشخص می‌کند و عبور از این مقدار می‌تواند به OOM Kill منجر شود. در OOM Kill، کرنل به‌دلیل فشار حافظه یا عبور کانتینر از محدودیت حافظه، یکی از فرایندهای آن را متوقف می‌کند.

Request در Scheduling چه نقشی دارد؟

یکی از رایج‌ترین سو برداشت‌ها درباره CPU Request در کوبرنتیز این است که آن را معادل مصرف واقعی برنامه در نظر می‌گیرند؛ درحالی‌که Request در اصل یک سیگنال برای زمان‌بندی (Scheduling در کوبرنتیز) است و قرار نیست گزارشی از مصرف لحظه‌ای کانتینر ارائه دهد. به همین دلیل ممکن است نود از نظر مصرف واقعی CPU تقریبا بیکار به نظر برسد، اما Scheduler همچنان نتواند پاد جدیدی را روی آن قرار دهد. 

اگر مجموع CPU Request پادهای مستقر روی یک نود به ظرفیت قابل تخصیص (Allocatable) آن رسیده باشد، کوبرنتیز دیگر پاد جدیدی را روی آن نود قرار نمی‌دهد؛ حتی اگر نمودارهای مانیتورینگ نشان دهند که مصرف واقعی CPU پایین است. در چنین شرایطی، اگر نود مناسب دیگری هم وجود نداشته باشد، پاد جدید در وضعیت Pending باقی می‌ماند و اجرا نمی‌شود.

تنظیم نادرست Requestها می‌تواند روی بهره‌وری کل کلاستر هم تاثیر بگذارد. اگر Requestها بیش از نیاز واقعی Workload تعیین شوند، Scheduler باید آن مقدار را در محاسبه ظرفیت قابل زمان‌بندی نود لحاظ کند. در نتیجه، بخشی از ظرفیت قابل زمان‌بندی (Schedulable Capacity) برای استقرار پادهای دیگر قابل استفاده نخواهد بود؛ حتی اگر مصرف واقعی CPU پایین باشد. پس بهتر است Request را بر اساس نیاز واقعی Workload تنظیم کنیم، زیرا Scheduler برای استقرار Podها به همین مقدار تکیه می‌کند و مصرف لحظه‌ای برنامه را معیار قرار نمی‌دهد.

CPU Limit در کوبرنتیز در پشت صحنه چطور اعمال می‌شود؟

برخلاف تصور رایج، کوبرنتیز مستقیماً مصرف CPU کانتینر را محدود نمی‌کند. پس از اینکه Scheduler نود مناسب را برای پاد انتخاب کرد، kubelet که روی آن نود اجرا می‌شود، مشخصات پاد را دریافت می‌کند. (عامل اجرایی کوبرنتیز روی هر نود است که پادها و کانتینرهای آن نود را راه‌اندازی و مدیریت می‌کند.) سپس kubelet از طریق Container Runtime (مانند containerd)، کانتینر را راه‌اندازی می‌کند.

Container Runtime برای هر کانتینر یک cgroup ایجاد کرده و مقادیر Request و Limit را به آن‌ها اعمال می‌کند. cgroup قابلیتی در لینوکس است که برای مدیریت و محدودکردن منابع پردازشی کانتینرها به کار می‌رود. از این مرحله به بعد، اعمال محدودیت CPU بر عهده کرنل لینوکس است.

در این فرایند، CPU Request و CPU Limit نقش‌های متفاوتی دارند. مقدار CPU Request معمولاً به cpu.weight تبدیل می‌شود و وزن نسبی کانتینر را هنگام رقابت بر سر CPU مشخص می‌کند. این مقدار به معنای اختصاص یا رزرو مقدار ثابتی از CPU نیست. در مقابل، CPU Limit به cpu.max تبدیل می‌شود و سقف سخت مصرف CPU کانتینر را تعیین می‌کند.

cpu.max = <quota> <period>

cpu.max = <quota> <period>

برای مثال، اگر CPU Limit برابر 200m باشد، مقدار cpu.max به‌صورت زیر تنظیم می‌شود:

cpu.max = 20000 100000

cpu.max = 20000 100000

در این مثال، کانتینر در هر بازه ۱۰۰،۰۰۰ میکروثانیه (معادل ۱۰۰ میلی‌ثانیه) فقط مجاز است ۲۰،۰۰۰ میکروثانیه (معادل ۲۰ میلی‌ثانیه) از CPU استفاده کند. اگر این سهم را پیش از پایان بازه مصرف کند، کرنل اجرای آن را تا شروع دوره بعدی متوقف می‌کند. همین توقف موقت را CPU Throttling در کوبرنتیز می‌نامند. رابطه میان Request و Limit با تنظیمات cgroup را می‌توان به‌صورت زیر خلاصه کرد:

CPU request → cpu.weight → controls fairness
CPU limit   → cpu.max    → enforces a hard cap

CPU request → cpu.weight → controls fairness
CPU limit   → cpu.max    → enforces a hard cap

نکته مهم این است که CPU Throttling صرفا به معنای «کمی کندتر شدن» کانتینر نیست. اگر سهم CPU مجاز در یک بازه زمانی به‌طور کامل مصرف شود، کانتینر تا آغاز بازه بعدی، عملا امکان دریافت CPU بیشتری را نخواهد داشت.

چرا با وجود CPU آزاد روی نود باز هم پاد Throttle می‌شود؟

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

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

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

در نتیجه، با وجود ظرفیت پردازشی بلااستفاده روی نود، سرویس ممکن است با افزایش تأخیر، تشکیل صف درخواست‌ها (Queue Buildup) و در نهایت Timeout مواجه شود.

CPU Limit با Memory Limit چه فرقی دارد؟

یکی از اشتباهات رایج درباره CPU Limit در کوبرنتیز این است که آن را با همان منطق Memory Limit در نظر می‌گیرند؛ درحالی‌که این دو از نظر نوع و رفتار هنگام رسیدن به Limit با هم متفاوت‌اند. جدول زیر این تفاوت را نشان می‌دهد:

این تفاوت در محیط‌های عملیاتی اهمیت زیادی دارد. اگر افزایش زمان پاسخ‌گویی مشاهده می‌کنید، ممکن است ریشه مشکل CPU Throttling باشد. اگر کانتینری به‌طور ناگهانی Restart می‌شود، ابتدا Last Termination Reason را بررسی کنید تا مشخص شود آیا دلیل توقف آن OOMKilled بوده است یا نه. در صورت مشاهده این وضعیت، Memory Limit و میزان واقعی مصرف حافظه را بررسی کنید.

برای سرویس‌های حساس به تاخیر چه الگویی بهتر است؟

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

همان‌طور که پیش‌تر دیدیم، CPU Limit سخت‌گیرانه می‌تواند حتی با وجود CPU آزاد روی نود باعث Throttling شود. به همین دلیل، برای بسیاری از سرویس‌های حساس به تاخیر، تنظیم یک CPU Request متناسب با مصرف واقعی و حذف CPU Limit می‌تواند به کانتینر اجازه دهد از CPU آزاد نود برای مدیریت Burstهای کوتاه‌مدت (افزایش ناگهانی و موقت مصرف CPU) استفاده کند. نمونه زیر همین رویکرد را نشان می‌دهد:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: checkout-api
        image: example.com/checkout-api:1.0.0
        resources:
          requests:
            cpu: "300m"
            memory: "512Mi"
          limits:
            memory: "512Mi"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: checkout-api
        image: example.com/checkout-api:1.0.0
        resources:
          requests:
            cpu: "300m"
            memory: "512Mi"
          limits:
            memory: "512Mi"

در این مثال، برای هر پاد CPU Request برابر 300m و Memory Request برابر 512Mi تعریف شده است. Memory Limit نیز روی 512Mi قرار دارد، اما هیچ‌گونه CPU Limit تعریف نشده است. حذف CPU Limit به سرویس اجازه می‌دهد در صورت وجود ظرفیت آزاد روی نود، Burstهای کوتاه‌مدت مصرف CPU را بدون مواجهه با یک سقف سخت مدیریت کند.

البته این توصیه به این معنا نیست که CPU Limit همیشه باید حذف شود. در برخی Workloadهای حساس به تاخیر، حذف CPU Limit می‌تواند گزینه مناسب‌تری باشد؛ اما تنها زمانی که CPU Request باتوجه‌به رفتار واقعی برنامه تنظیم شده و الگوی مصرف آن در محیط عملیاتی بررسی شده باشد.

برای عیب‌یابی Request و Limit چه مواردی را بررسی کنیم؟

اگر احتمال می‌دهید مشکل به تنظیمات Request یا Limit مربوط باشد، چند بررسی اولیه می‌تواند سرنخ‌های مهمی در اختیارتان قرار دهد. ابتدا مصرف فعلی CPU و Memory هر پاد را بررسی کنید:

kubectl top pod

kubectl top pod

سپس جزئیات پاد را مشاهده کنید تا مقدار Request ،Limit، کلاس QoS، رویدادها (Events) و آخرین دلیل توقف کانتینر (Last Termination Reason) را ببینید:

kubectl describe pod <pod-name>

kubectl describe pod <pod-name>

اگر احتمال می‌دهید پاد به‌دلیل کمبود منابع روی هیچ نودی زمان‌بندی نشده است، Eventهای مربوط به Scheduling را نیز بررسی کنید:

kubectl describe pod frontend | grep -A 9999999999 Events

kubectl describe pod frontend | grep -A 9999999999 Events

به این نکته توجه داشته باشید که kubectl top pod فقط مصرف فعلی CPU و Memory را نمایش می‌دهد و به‌تنهایی برای تشخیص CPU Throttling کافی نیست. برای تشخیص این وضعیت باید متریک‌های مربوط به CPU Throttling را در ابزار مانیتورینگ بررسی کنید.

چه زمانی CPU Limit نگذاریم؟

CPU Limit در کوبرنتیز ممکن است حتی در صورت وجود CPU آزاد روی نود، باعث CPU Throttling و افزایش تاخیر شود. تعریف‌نکردن CPU Limit می‌تواند برای موارد زیر مناسب‌تر باشد:

• سرویس‌های حساس به تاخیر
• Workloadهایی که برای مدیریت Burstهای کوتاه‌مدت (افزایش ناگهانی و موقت مصرف CPU) باید بتوانند از CPU آزاد نود استفاده کنند
• سرویس‌هایی که CPU Throttling در آن‌ها باعث افزایش تاخیر، تشکیل صف درخواست‌ها، Timeout یا کاهش Throughput می‌شود

در این شرایط، CPU Request باید براساس مصرف واقعی Workload تنظیم شود. CPU Limit نیز فقط زمانی تعریف شود که Workload واقعاً به یک سقف سخت برای مصرف CPU نیاز داشته باشد.

چه زمانی CPU Limit در کوبرنتیز همچنان مفید است؟

با اینکه حذف CPU Limit در کوبرنتیز می‌تواند برای بسیاری از سرویس‌های حساس به تأخیر مناسب‌تر باشد، استفاده از آن در برخی سناریوها همچنان قابل دفاع است. CPU Limit باید زمانی تعریف شود که Workload واقعاً به یک سقف سخت برای مصرف CPU نیاز داشته باشد، نه صرفاً به این دلیل که به‌صورت پیش‌فرض در یک الگوی پیکربندی قرار گرفته است. استفاده از CPU Limit در شرایط زیر می‌تواند مناسب باشد:

• کلاسترهای Multi-tenant که چند تیم یا چند سرویس از منابع مشترک استفاده می‌کنند
• Workloadهای غیر قابل اعتماد (Untrusted) که باید مصرف CPU آن‌ها به‌طور سخت‌گیرانه کنترل شود
• جاب‌های پردازش دسته‌ای (Batch Jobs) که به سقف مشخصی برای مصرف CPU نیاز دارند
• محیط‌های Benchmark و Performance Test که تکرارپذیری نتایج اهمیت دارد
• سرویس‌هایی که بر اساس پلن‌های ثابت CPU به مشتریان ارائه می‌شوند
• سناریوهایی که Strict Cost Control در آن‌ها اهمیت دارد و مصرف CPU باید در یک بودجه مشخص باقی بماند
• محیط‌هایی که سیاست‌های پلتفرم، تعریف CPU Limit را الزامی می‌کنند

در این سناریوها، CPU Limit یک سقف مشخص برای مصرف CPU ایجاد می‌کند؛ هرچند ممکن است امکان استفاده Workload از CPU آزاد نود را در زمان Burst محدود کند. CPU Limit نیز باید فقط زمانی تعریف شود که Workload واقعاً به یک سقف سخت برای مصرف CPU نیاز داشته باشد.

جمع‌بندی 

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

The post راهنمای عملی تنظیم CPU Limit در کوبرنتیز؛ از Request تا Throttling appeared first on بلاگ هم‌روش.

در این مقاله بررسی می‌کنیم که ingress-nginx چیست، دقیقاً چه بخشی از این پروژه بازنشسته شده، چرا کوبرنتیز این تصمیم را گرفته است و ادامه استفاده از آن چه ریسک‌هایی دارد. همچنین گزینه‌های موجود برای جایگزین ingress-nginx، نقش Gateway API و مراحل مهاجرت از اینگرس nginx با استفاده از ابزار Ingress2Gateway را به‌صورت عملی آموزش می‌دهیم.

اهمیت بازنشستگی ingress-nginx؛ چرا کوبرنتیز درباره آن هشدار می‌دهد؟

بازنشستگی ingress-nginx صرفا پایان عمر یک پروژه متن‌باز نیست، بلکه به پایان چرخه نگهداری یکی از پرکاربردترین Ingress Controllerهای کوبرنتیز اشاره دارد. بر اساس بیانیه رسمی کوبرنتیز، ادامه استفاده از این پروژه پس از پایان دوره پشتیبانی، می‌تواند ریسک‌های امنیتی و عملیاتی جدیدی برای محیط‌های Production ایجاد کند.

اهمیت این موضوع زمانی بیشتر مشخص می‌شود که بخش قابل توجهی از کلاسترهای کوبرنتیز همچنان از ingress-nginx برای مدیریت ترافیک HTTP و HTTPS استفاده می‌کنند. هرچند استقرارهای فعلی به کار خود ادامه می‌دهند، اما پس از بازنشستگی، هیچ وصله امنیتی، اصلاح باگ یا نسخه جدیدی برای پروژه منتشر نمی‌شود و آسیب‌پذیری‌های آینده ممکن است بدون راهکار رسمی باقی بمانند.

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

ingress-nginx چیست؟

ingress-nginx یک Ingress Controller مبتنی بر NGINX برای کوبرنتیز است که منابع Ingress را پایش کرده و بر اساس قوانین تعریف‌شده، پیکربندی NGINX را به‌صورت خودکار ایجاد و به‌روزرسانی می‌کند تا ترافیک HTTP و HTTPS به سرویس‌های مناسب هدایت شود.

در کوبرنتیز، منبع Ingress فقط شامل قوانین مسیریابی است و به‌تنهایی درخواست‌ها را پردازش نمی‌کند. برای اعمال این قوانین به یک Ingress Controller نیاز است و ingress-nginx یکی از شناخته‌شده‌ترین پیاده‌سازی‌های این مدل به شمار می‌آید.

یکی از دلایل محبوبیت ingress-nginx، متن‌باز بودن و امکان استفاده از آن در انواع محیط‌های کوبرنتیز، چه در سرویس‌های ابری و چه در زیرساخت‌های On-Premise، بود و به همین دلیل در میان تیم‌های DevOps و SRE جایگاه ویژه‌ای پیدا کرد.

دقیقاً چه چیزی بازنشسته شده است؟

نکته مهمی که باید بدانید این است که قابلیت Ingress همچنان بخشی از کوبرنتیز باقی می‌ماند، اما پروژه ingress-nginx پس از پایان دوره پشتیبانی دیگر به‌روزرسانی نمی‌شود. بر اساس اعلام رسمی کوبرنتیز ، پس از پایان نگهداری پروژه:

• نسخه جدیدی از ingress-nginx منتشر نمی‌شود
• باگ‌های جدید برطرف نخواهند شد
• برای آسیب‌پذیری‌های آینده وصله امنیتی ارائه نمی‌شود
• مخازن GitHub پروژه در حالت فقط‌خواندنی (Read-only) قرار می‌گیرند.

در عین حال، استقرارهای فعلی همچنان به کار خود ادامه می‌دهند و آرتیفکت‌هایی مانند Helm Chartها و Container Imageهای موجود در دسترس هستند. البته با این حال استفاده از نرم‌افزاری که دیگر به‌روزرسانی امنیتی دریافت نمی‌کند، می‌تواند به مرور زمان ریسک‌های عملیاتی و امنیتی را افزایش دهد. اگر می‌خواهید بررسی کنید که آیا کلاستر شما از ingress-nginx استفاده می‌کند یا خیر، می‌توانید دستور زیر را اجرا کنید:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

اگر این دستور خروجی داشته باشد، کلاستر شما از ingress-nginx استفاده می‌کند و بهتر است وضعیت زیرساخت خود را ارزیابی و برای مهاجرت از ingress nginx یا انتخاب یک جایگزین ingress-nginx مناسب برنامه‌ریزی کنید.

چرا ingress-nginx بازنشسته شد؟

بازنشستگی ingress-nginx نتیجه مجموعه‌ای از چالش‌های فنی و مدیریتی است که طی سال‌های گذشته شکل گرفته‌اند. تیم کوبرنتیز اعلام کرده است که نگهداری این پروژه برای مدت طولانی بر عهده تعداد محدودی افراد مسئول نگهداری بوده و این مدل برای یکی از پرکاربردترین اجزای اکوسیستم Cloud Native پایداری لازم را نداشته است.

عامل مهم دیگر، انباشت بدهی فنی (Technical Debt) است. ingress-nginx در ابتدا به‌عنوان یکی از پیاده‌سازی‌های Ingress API توسعه یافت، اما به مرور زمان قابلیت‌ها و Annotationهای متعددی به آن اضافه شد. این انعطاف‌پذیری برای کاربران مفید بود، اما پیچیدگی نگهداری و مدیریت امنیت پروژه را افزایش داد.

از سوی دیگر، جامعه کوبرنتیز در سال‌های اخیر به سمت معماری‌ها و استانداردهای جدیدتر مدیریت ترافیک حرکت کرده است؛ به همین دلیل، به جای توسعه بیشتر ingress-nginx، تمرکز اکوسیستم به سمت راهکارهایی مانند Gateway API و نسل جدید Ingress Controllerها معطوف شده است.

در مجموع، بازنشستگی ingress-nginx را می‌توان حاصل سه عامل اصلی محدودیت در نگهداری پروژه، افزایش بدهی فنی و حرکت اکوسیستم کوبرنتیز به سمت مدل‌های جدیدتر مدیریت ترافیک دانست.

اگر مهاجرت نکنیم چه اتفاقی می‌افتد؟

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

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

موضوع دیگر، افزایش بدهی فنی است. هرچه وابستگی سرویس‌ها به قابلیت‌های اختصاصی ingress-nginx، تنظیمات ویژه و Annotationها بیشتر شود، فرایند مهاجرت در آینده پیچیده‌تر و پرهزینه‌تر می‌شود.

همچنین ممکن است به دلیل عدم به‌روزرسانی پروژه ingress-nginx برای سازگاری با تغییرات، در نسخه‌های آینده کوبرنتیز یا سایر اجزای اکوسیستم، ناسازگاری‌های جدیدی ایجاد شود. توصیه جامعه کوبرنتیز این است که سازمان‌ها پیش از تبدیل شدن این وابستگی به یک چالش عملیاتی، وضعیت کلاسترهای خود را بررسی و برای مهاجرت از ingress nginx یا انتخاب یک جایگزین ingress-nginx مناسب برنامه‌ریزی کنند.

جایگزین‌های ingress-nginx چیست؟

بازنشستگی ingress-nginx به این معنا نیست که کوبرنتیز دیگر از مدیریت ترافیک ورودی پشتیبانی نمی‌کند. این اکوسیستم از مدت‌ها قبل گزینه‌های مختلفی برای این منظور در اختیار کاربران قرار داده است و در اطلاعیه‌های رسمی هم به مهاجرت از ingress nginx یا انتخاب یک جایگزین مناسب توصیه شده است.

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

Traefik

Traefik یکی از شناخته‌شده‌ترین Ingress Controllerهای کوبرنتیز است که علاوه بر Ingress API، از Gateway API هم پشتیبانی می‌کند. این ویژگی امکان مهاجرت تدریجی را برای بسیاری از تیم‌ها فراهم می‌کند. همچنین راه‌اندازی ساده، یکپارچگی مناسب با کوبرنتیز و پشتیبانی هم‌زمان از مدل‌های مختلف مدیریت ترافیک، از مهم‌ترین دلایل محبوبیت این پروژه است.

Traefik معمولاً برای تیم‌هایی مناسب است که به دنبال مهاجرت کم‌دردسر از ingress-nginx هستند و می‌خواهند علاوه بر Ingress API، به‌تدریج از Gateway API نیز استفاده کنند. سادگی راه‌اندازی و مدیریت، این گزینه را برای کلاسترهای کوچک و متوسط جذاب کرده است.

Kong Gateway

Kong Gateway یکی دیگر از گزینه‌های شناخته‌شده برای مدیریت ترافیک در Kubernetes است که علاوه بر قابلیت‌های Ingress Controller، امکانات گسترده‌ای در حوزه API Gateway نیز ارائه می‌دهد. این پروژه از Gateway API پشتیبانی می‌کند و برای سازمان‌هایی که علاوه بر مسیریابی ترافیک، به قابلیت‌هایی مانند احراز هویت، Rate Limiting، مدیریت API و سیاست‌های امنیتی پیشرفته نیاز دارند، گزینه مناسبی محسوب می‌شود.

Envoy Gateway

Envoy Gateway با تمرکز بر Gateway API توسعه یافته است و بیشتر برای سازمان‌هایی مناسب است که قصد دارند معماری مدیریت ترافیک خود را بر پایه استانداردهای جدید کوبرنتیز طراحی کنند. این پروژه یکی از گزینه‌هایی است که در سال‌های اخیر توانسته توجه بسیاری از تیم‌های Cloud Native را به خود جلب کند.

Envoy Gateway بیشتر برای سازمان‌هایی مناسب است که قصد دارند از ابتدا بر پایه Gateway API حرکت کنند یا به قابلیت‌های پیشرفته مدیریت ترافیک در معماری‌های Cloud Native و Microservices نیاز دارند.

NGINX Gateway Fabric

NGINX Gateway Fabric راهکار دیگری است که بر پایه Gateway API توسعه یافته است و توسط اکوسیستم NGINX ارائه می‌شود. این گزینه می‌تواند برای تیم‌هایی که تجربه کار با محصولات NGINX را دارند، مسیر مهاجرت آشناتری ایجاد کند.

NGINX Gateway Fabric گزینه مناسبی برای تیم‌هایی است که تجربه کار با NGINX را دارند و می‌خواهند ضمن استفاده از Gateway API، همچنان در اکوسیستم محصولات NGINX باقی بمانند.

نکته مهم: در اطلاعیه رسمی بازنشستگی ingress-nginx، تیم کوبرنتیز استفاده از Gateway API را به‌عنوان یکی از مسیرهای آینده مدیریت ترافیک معرفی کرده است. البته Gateway API جایگزین مستقیم و یک‌به‌یک Ingress نیست و معمولا مهاجرت به آن به بررسی دقیق معماری فعلی نیاز دارد.

Gateway API؛ چرا در آینده کوبرنتیز اهمیت بیشتری پیدا می‌کند؟

Gateway API در کوبرنتیز مجموعه‌ای از APIهای جدید برای مدیریت ترافیک در کوبرنتیز است که با هدف ایجاد انعطاف‌پذیری بیشتر و پوشش سناریوهای پیچیده‌تر طراحی شده است. بسیاری از پروژه‌های جدید اکوسیستم کوبرنتیز هم توسعه خود را بر اساس این استاندارد انجام می‌دهند.

یکی از دلایل توجه گسترده به Gateway API، رفع برخی محدودیت‌های مدل سنتی Ingress است. در این استاندارد، قابلیت‌هایی که پیش‌تر معمولاً از طریق Annotationهای اختصاصی هر Ingress Controller پیاده‌سازی می‌شدند، به‌صورت استاندارد و قابل حمل تعریف می‌شوند. همچنین تفکیک مسئولیت‌ها بین تیم‌های زیرساخت و توسعه ساده‌تر شده و امکان مدیریت سناریوهای پیچیده‌تر ترافیک فراهم می‌شود.

البته این موضوع به معنای حذف Ingress API نیست. در واقع Ingress همچنان بخشی از کوبرنتیز محسوب می‌شود و بسیاری از کلاسترها به استفاده از آن ادامه می‌دهند. با این حال، جهت‌گیری کلی اکوسیستم به سمت استفاده گسترده‌تر از Gateway API است و به همین دلیل بسیاری از سازمان‌ها هنگام برنامه‌ریزی برای مهاجرت از ingress nginx، این استاندارد را هم در ارزیابی‌های خود در نظر می‌گیرند.

چرا مهاجرت از ingress-nginx همیشه ساده نیست؟

مهاجرت از ingress-nginx به یک کنترلر دیگر یا Gateway API، پیچیدگی‌های خاص خود را دارد و فراتر از تبدیل چند فایل YAML است. طی سال‌های گذشته، ingress-nginx رفتارها و قابلیت‌های خاصی را از طریق Annotationها و تنظیمات اختصاصی ارائه کرده که بخشی از استاندارد کوبرنتیز نیستند و احتمالا در راهکارهای دیگر باید به شکل متفاوت یا بدون معادل مستقیم پیاده‌سازی شوند. حتی اگر تبدیلات ظاهرا درست انجام شوند، ممکن است رفتار سرویس‌ها تغییر کند یا اختلالی ایجاد شود. بر اساس مستندات رسمی کوبرنتیز، هنگام مهاجرت باید به موارد زیر توجه ویژه داشت:

• پردازش مسیرهای مبتنی بر Regular Expression
• تاثیر Annotationهای اختصاصی مانند use-regex
• رفتار وابسته به rewrite-target
• مدیریت مسیرهای دارای یا فاقد / انتهایی
• تفاوت در URL Normalization

این موارد ممکن است در کنترلر جدید یا پیاده‌سازی‌های Gateway API به شکل متفاوتی عمل کنند، بنابراین قبل از انتقال کامل ترافیک، تنظیمات جدید باید به‌دقت بررسی و آزمایش شوند. جامعه کوبرنتیز ابزارهایی برای ساده‌تر کردن این فرایند توسعه داده است که در بخش بعدی به مهم‌ترین آن‌ها، یعنی Ingress2Gateway، می‌پردازیم.

مهاجرت واقعی و ابزارها؛ آموزش عملی با Ingress2Gateway

تا اینجا دیدیم که مهاجرت از ingress-nginx همیشه یک تبدیل ساده و یک‌به‌یک نیست. در واقع تفاوت در Annotationها، رفتارهای خاص این کنترلر و تفاوت معماری Gateway API باعث می‌شود که انتقال بدون برنامه‌ریزی، ریسک ایجاد اختلال در سرویس را به همراه داشته باشد.

تیم SIG Network ابزار رسمی Ingress2Gateway را معرفی کرده است. در مستندات رسمی، این ابزار به‌عنوان یک Migration Assistant یا دستیار مهاجرت معرفی می‌شود که می‌تواند بررسی Ingressهای فعلی را انجام دهد و آن‌ها را تا حد امکان به Gateway API تبدیل کند. همچنین می‌تواند در عین حال، در مورد بخش‌هایی که نیاز به بازبینی دستی دارند به شما هشدار ‌دهد. به طور کلی، Ingress2Gateway سه هدف اصلی زیر را دنبال می‌کند: 

• تبدیل پیکربندی: ترجمه Ingressها و Annotationهای پشتیبانی‌شده به Gateway API
• شناسایی مشکلات: تشخیص تنظیماتی که معادل مستقیمی ندارند
• ارائه پیشنهاد: اعلام هشدارها و پیشنهاد برای اصلاح دستی

نسخه ۱.۰ چه قابلیت‌هایی دارد؟

نسخه ۱.۰ که در مارس ۲۰۲۶ منتشر شد، نسبت به نسخه‌های قبلی پیشرفت قابل توجهی داشته است. مهم‌ترین تغییرات این نسخه عبارت‌اند از:

• پشتیبانی از بیش از ۳۰ Annotation رایج ingress-nginx 
• پشتیبانی از قابلیت‌هایی مانند CORS ،Backend TLS ،Regex Matching و Path Rewrite 
• تست‌های یکپارچگی برای اطمینان از یکسان بودن رفتار Ingress-NGINX و Gateway API 
• سیستم هشدار و گزارش‌دهی برای بخش‌هایی که قابل ترجمه نیستند

مرحله اول: نصب Ingress2Gateway

برای استفاده از این ابزار، ابتدا باید آن را نصب کنید. اگر روی سیستم خود محیط Go را دارید، می‌توانید با دستور زیر آخرین نسخه پایدار را نصب کنید:

go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

اگر از macOS و Homebrew استفاده می‌کنید، دستور نصب آن ساده‌تر است:

brew install ingress2gateway

brew install ingress2gateway

همچنین امکان دانلود فایل باینری از GitHub یا کامپایل ابزار از سورس هم وجود دارد.

مرحله دوم: اجرای Ingress2Gateway

پس از نصب می‌توانید مانیفست‌های Ingress را به Ingress2Gateway ارسال کنید، یا ابزار را مستقیما از کلاستر خود بخوانید.

# ارسال به فایل
ingress2gateway print --input-file my-manifest.yaml,my-other-manifest.yaml --providers=ingress-nginx > gwapi.yaml
# استفاده از فضای نام در کلاستر خودتان
ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml
# یا برای کل کلاستر
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml

# ارسال به فایل
ingress2gateway print --input-file my-manifest.yaml,my-other-manifest.yaml --providers=ingress-nginx > gwapi.yaml
# استفاده از فضای نام در کلاستر خودتان
ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml
# یا برای کل کلاستر
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml

نکته: همچنین می‌توانید --emitter <agentgateway|envoy-gateway|kgateway> را برای خروجی پسوندهای خاص پیاده‌سازی ارسال کنید.

مرحله سوم: بررسی خروجی

این مهم‌ترین مرحله است. دستورات بخش قبلی یک مانیفست Gateway API را در gwapi.yaml خروجی می‌دهند. همچنین هشدارهایی منتشر می‌کنند که توضیح می‌دهند چه چیزی دقیقا ترجمه نشده است و چه چیزی را باید به صورت دستی مرور کنید.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-http
    port: 80
    protocol: HTTP
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        - Keep-Alive
        - User-Agent
        - X-Requested-With
        - If-Modified-Since
        - Cache-Control
        - Content-Type
        - Range
        - Authorization
        allowMethods:
        - GET
        - PUT
        - POST
        - DELETE
        - PATCH
        - OPTIONS
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: (?i)/users/(\d+).*
    name: rule-0
    timeouts:
      request: 10s
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com-ssl-redirect
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 80
  rules:
  - filters:
    - requestRedirect:
        scheme: https
        statusCode: 308
      type: RequestRedirect

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-http
    port: 80
    protocol: HTTP
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        - Keep-Alive
        - User-Agent
        - X-Requested-With
        - If-Modified-Since
        - Cache-Control
        - Content-Type
        - Range
        - Authorization
        allowMethods:
        - GET
        - PUT
        - POST
        - DELETE
        - PATCH
        - OPTIONS
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: (?i)/users/(\d+).*
    name: rule-0
    timeouts:
      request: 10s
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com-ssl-redirect
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 80
  rules:
  - filters:
    - requestRedirect:
        scheme: https
        statusCode: 308
      type: RequestRedirect

همان‌طور که در بالا مشاهده کردید، Ingress2Gateway با موفقیت برخی annotationها را به معادل‌های Gateway API خود ترجمه کرد. به عنوان مثال، nginx.ingress.kubernetes.io/enable-cors به یک فیلتر CORS ترجمه شد، اما با بررسی دقیق‌تر، annotationهای nginx.ingress.kubernetes.io/proxy-{read,send}-timeout و nginx.ingress.kubernetes.io/proxy-body-size کاملا نگاشت نمی‌شوند. لاگ‌ها دلیل این حذفیات و همچنین استدلال پشت ترجمه را نشان می‌دهند.

┌─ WARN  ────────────────────────────────────────
│  Unsupported annotation nginx.ingress.kubernetes.io/configuration-snippet
│  source: INGRESS-NGINX
│  object: Ingress: my-ns/my-ingress
└─
┌─ INFO  ────────────────────────────────────────
│  Using case-insensitive regex path matches. You may want to change this.
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  ingress-nginx only supports TCP-level timeouts; i2gw has made a best-effort translation to Gateway API timeouts.request. Please verify that this meets your needs. See documentation: https://gateway-api.sigs.k8s.io/guides/http-timeouts/
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Failed to apply my-ns.my-ingress.metadata.annotations."nginx.ingress.kubernetes.io/proxy-body-size" from my-ns/my-ingress: Most Gateway API implementations have reasonable body size and buffering defaults
│  source: STANDARD_EMITTER
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Gateway API does not support configuring URL normalization (RFC 3986, Section 6). Please check if this matters for your use case and consult implementation-specific details.
│  source: STANDARD_EMITTER
└─

┌─ WARN  ────────────────────────────────────────
│  Unsupported annotation nginx.ingress.kubernetes.io/configuration-snippet
│  source: INGRESS-NGINX
│  object: Ingress: my-ns/my-ingress
└─
┌─ INFO  ────────────────────────────────────────
│  Using case-insensitive regex path matches. You may want to change this.
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  ingress-nginx only supports TCP-level timeouts; i2gw has made a best-effort translation to Gateway API timeouts.request. Please verify that this meets your needs. See documentation: https://gateway-api.sigs.k8s.io/guides/http-timeouts/
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Failed to apply my-ns.my-ingress.metadata.annotations."nginx.ingress.kubernetes.io/proxy-body-size" from my-ns/my-ingress: Most Gateway API implementations have reasonable body size and buffering defaults
│  source: STANDARD_EMITTER
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Gateway API does not support configuring URL normalization (RFC 3986, Section 6). Please check if this matters for your use case and consult implementation-specific details.
│  source: STANDARD_EMITTER
└─

یک هشدار وجود دارد که Ingress2Gateway از annotation نوع nginx.ingress.kubernetes.io/configuration-snippet پشتیبانی نمی‌کند. برای دیدن اینکه آیا راهی برای دستیابی به رفتار معادل وجود دارد، باید مستندات پیاده‌سازی Gateway API خود را بررسی کنید.

این ابزار همچنین به ما اطلاع داد که تطابق‌های ریجکس Ingress-NGINX تطابق‌های پیشوندی غیر حساس به حروف کوچک و بزرگ هستند. به همین دلیل یک الگوی تطابق (?i)/users/(\d+).* وجود دارد. بیشتر سازمان‌ها می‌خواهند این رفتار را با حذف (?i) ابتدایی و .* انتهایی از الگوی مسیر به یک تطابق دقیق و حساس به حروف کوچک و بزرگ تغییر دهند.

Ingress2Gateway ترجمه‌ای با بهترین تلاش از annotationهای nginx.ingress.kubernetes.io/proxy-{send,read}-timeout به یک زمان انتظار درخواست ۱۰ ثانیه در مسیر HTTP ما انجام داد. اگر درخواست‌های این سرویس باید بسیار کوتاه‌تر باشد (مثلا ۳ ثانیه)، می‌توانید تغییرات مربوطه را در مانیفست‌های Gateway API خود اعمال کنید.

همچنین، nginx.ingress.kubernetes.io/proxy-body-size معادل Gateway API ندارد، بنابراین ترجمه نشده است. البته با این حال، بیشتر پیاده‌سازی‌های Gateway API، پیش‌فرض‌های معقولی برای حداکثر اندازه بدنه و بافرینگ دارند، بنابراین این موضوع، ممکن است در عمل مشکلی ایجاد نکند.

علاوه بر این، برخی emitterها ممکن است پشتیبانی از این annotation را از طریق پسوندهای خاص پیاده‌سازی ارائه دهند. به عنوان مثال، افزودن فلگ --emitter agentgateway یا --emitter envoy-gateway یا --emitter kgateway به دستور ingress2gateway print قبلی منجر به پیکربندی خاص پیاده‌سازی اضافی در مانیفست‌های Gateway API تولید شده می‌شد که سعی در ثبت پیکربندی اندازه بدنه (body size) داشت.

همچنین یک هشدار در مورد نرمالایز کردن URL می‌بینیم. پیاده‌سازی‌های Gateway API مانند Agentgateway ،Envoy Gateway ،Kgateway و Istio دارای سطحی از عادی‌سازی URL هستند؛ اما رفتار در پیاده‌سازی‌ها متفاوت است و از طریق Gateway API استاندارد قابل تنظیم نیست. شما باید رفتار عادی‌سازی URL پیاده‌سازی Gateway API خود را بررسی و آزمایش کنید تا مطمئن شوید با مورد استفاده شما سازگار است.

همچنین برای مطابقت با رفتار پیش‌فرض Ingress-NGINX، ابزار Ingress2Gateway یک شنونده در پورت ۸۰ و یک فیلتر تغییر مسیر درخواست HTTP برای هدایت ترافیک HTTP به HTTPS اضافه کرد. ممکن است اصلا نخواهید به ترافیک HTTP سرویس بدهید و شنونده پورت ۸۰ و HTTPRoute مربوطه را حذف کنید.

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

پس از اعمال دستی این تغییرات، مانیفست‌های Gateway API ممکن است به شکل زیر باشد:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        ...
        allowMethods:
        - GET
        ...
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: /users/(\d+)
    name: rule-0
    timeouts:
      request: 3s

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        ...
        allowMethods:
        - GET
        ...
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: /users/(\d+)
    name: rule-0
    timeouts:
      request: 3s

مرحله چهارم: بازبینی (Verify)

اکنون که مانیفست‌های Gateway API را دارید، باید آنها را به طور کامل در یک کلاستر توسعه آزمایش کنید. در این مورد، حداقل باید بررسی کنید که پیش‌فرض‌های حداکثر اندازه بدنه پیاده‌سازی Gateway API برای شما مناسب است و تأیید کنید که زمان انتظار ۳ ثانیه کافی است.

پس از تایید رفتار در یک کلاستر توسعه، پیکربندی Gateway API خود را در کنار Ingress موجود خود مستقر کنید. پیشنهاد می‌کنیم که ترافیک را با استفاده از DNS وزن‌دار، لود بالانسر ابری خود یا ویژگی‌های تقسیم ترافیک پلتفرم خود به تدریج تغییر دهید. به این ترتیب، می‌توانید به سرعت، هرگونه پیکربندی اشتباهی را که از تست‌های شما عبور کرده است، بازیابی کنید.

در نهایت، پس از انتقال کامل ترافیک به کنترلر Gateway API، ابتدا منابع Ingress را حذف و سپس کنترلر Ingress قدیمی را uninstall کنید.

جمع‌بندی

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

گزینه‌های جایگزین شامل Traefik ،Envoy Gateway ،Kong Gateway و NGINX Gateway Fabric هستند و مسیر آینده اکوسیستم، Gateway API است. با برنامه‌ریزی درست، بررسی زیرساخت، اصلاح مانیفست‌ها و تست در محیط توسعه، می‌توانید مهاجرت تدریجی و امن را انجام دهید و بدون اختلال سرویس‌ها، به معماری مدرن کوبرنتیز برسید.

The post بازنشستگی Ingress NGINX؛ ریسک‌ها، جایگزین‌ها و مسیر مهاجرت appeared first on بلاگ هم‌روش.

RBAC در کوبرنتیز چیست؟

RBAC مخفف Role-Based Access Control یا «کنترل دسترسی مبتنی بر نقش» است. این مکانیزم امنیتی در کوبرنتیز مشخص می‌کند که هر کاربر، سرویس یا برنامه چه عملیاتی را روی کدام منابع کلاستر می‌تواند انجام دهد.

در کوبرنتیز، تمام درخواست‌ها از طریق API Server پردازش می‌شوند و سیستم RBAC کوبرنتیز وظیفه دارد سطح دسترسی این درخواست‌ها را کنترل کند. به‌کمک این مکانیزم می‌توان تعیین کرد که یک هویت مشخص چه منابعی را مشاهده کند، چه عملیاتی انجام دهد و این دسترسی در کدام Namespace یا در سطح کل کلاستر معتبر باشد. برای مثال، با استفاده از RBAC در کوبرنتیز می‌توان به یک توسعه‌دهنده فقط اجازه مشاهده Podها در Namespace توسعه (Dev) را داد؛ بدون اینکه به منابع محیط Production دسترسی داشته باشد.

سیستم RBAC کوبرنتیز فقط برای کاربران انسانی استفاده نمی‌شود و برنامه‌ها و Podهای داخل کلاستر نیز از طریق Service Accountها با همین مکانیزم احراز دسترسی می‌شوند.

به‌طور کلی، RBAC استانداردترین روش مدیریت دسترسی کاربران در کوبرنتیز است و نقش مهمی در پیاده‌سازی اصل Least Privilege یا «حداقل سطح دسترسی» دارد.

تفاوت Authentication و Authorization در Kubernetes

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

مرحله اول، Authentication: کوبرنتیز مشخص می‌کند درخواست از طرف چه کاربری، سرویس یا برنامه‌ای ارسال شده است. این فرایند معمولاً با استفاده از توکن‌ها، Client Certificateها یا سرویس‌های هویت خارجی انجام می‌شود. اگر هویت فرستنده تأیید نشود، درخواست با خطای HTTP 401 Unauthorized رد خواهد شد.

مرحله دوم، Authorization: پس از تأیید هویت، مرحله Authorization یا آغاز می‌شود. در این مرحله، کوبرنتیز بررسی می‌کند که آیا این هویت، اجازه انجام عملیات موردنظر را دارد یا خیر. اینجاست که RBAC کوبرنتیز وارد عمل می‌شود و بر اساس Roleها و Bindingهای تعریف‌شده، مجوز دسترسی را صادر یا رد می‌کند. در صورت نداشتن مجوز کافی، درخواست با خطای HTTP 403 Forbidden مواجه می‌شود.

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

اجزای اصلی RBAC در کوبرنتیز

سیستم RBAC در کوبرنتیز از چند جزء اصلی تشکیل شده است که در کنار هم مشخص می‌کنند چه هویتی چه عملیاتی را روی کدام منابع می‌تواند انجام دهد. این اجزا عبارت‌اند از:

Role

Role مجموعه‌ای از مجوزهاست که دسترسی به منابع را در یک Namespace در کوبرنتیز تعریف می‌کند. با استفاده از Role می‌توان مشخص کرد که یک کاربر یا Service Account چه عملیاتی را روی منابع کوبرنتیز انجام دهد.

ClusterRole

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

RoleBinding

RoleBinding یک Role را به یک کاربر، گروه یا Service Account متصل می‌کند. این اتصال فقط در همان Namespace معتبر است و مشخص می‌کند چه هویتی از مجوزهای تعریف‌شده در Role استفاده کند.

ClusterRoleBinding

ClusterRoleBinding یک ClusterRole را در سطح کل کلاستر به کاربران، گروه‌ها یا Service Accountها متصل می‌کند. این نوع Binding معمولاً برای دسترسی‌های سراسری استفاده می‌شود.

Subjects

Subjects همان هویت‌هایی هستند که مجوزها به آن‌ها اختصاص داده می‌شود. این هویت‌ها می‌توانند کاربران، گروه‌ها یا Service Accountهای داخل کلاستر باشند.

در تنظیمات RBAC کوبرنتیز، هر Role یا ClusterRole معمولاً شامل فیلدهایی برای تعیین منابع و نوع دسترسی است. برای مثال، فیلد verbs مشخص می‌کند یک هویت چه عملیاتی مانند get ،list ،create یا delete را می‌تواند انجام دهد.

همچنین فیلد apiGroups برای تعیین گروه API مربوط به هر منبع استفاده می‌شود. در منابع اصلی کوبرنتیز مانند Pod و Service معمولاً مقدار آن به‌صورت رشته خالی "" نوشته می‌شود، اما برای منابعی مانند Deployment در کوبرنتیز از گروه‌هایی مانند apps استفاده می‌شود.

تفاوت Role و ClusterRole؛ مرز میان Namespace و کلاستر

اصلی‌ترین تفاوت Role و ClusterRole در Kubernetes، محدوده دسترسی یا Scope آن‌هاست. Role فقط در یک Namespace مشخص معتبر است و مجوزهای تعریف‌شده در آن خارج از همان Namespace اعمال نمی‌شوند. برای مثال، اگر کاربری در Namespace مربوط به محیط توسعه (dev) اجازه مشاهده پادها را داشته باشد، این دسترسی در Namespace محیط Production معتبر نخواهد بود.

در مقابل، ClusterRole در سطح کل کلاستر عمل می‌کند و به یک Namespace محدود نیست. این نوع Role معمولاً برای منابعی استفاده می‌شود که وابسته به Namespace نیستند؛ مانند نودها یا PersistentVolumeها. همچنین می‌توان از ClusterRole برای تعریف دسترسی‌های یکسان در چند Namespace مختلف استفاده کرد.

در عمل، Role و RoleBinding بیشتر برای مدیریت دسترسی‌های محدود در یک Namespace استفاده می‌شوند، درحالی‌که ClusterRole و ClusterRoleBinding برای دسترسی‌های سراسری در سطح کلاستر کاربرد دارند.

نحوه عملکرد RBAC در Kubernetes

سیستم RBAC در کوبرنتیز برای بررسی دسترسی‌ها، هر درخواست را به‌صورت مرحله‌به‌مرحله ارزیابی می‌کند. زمانی که یک کاربر، Service Account یا برنامه درخواستی را به API Server ارسال می‌کند، کوبرنتیز مراحل زیر را برای تصمیم‌گیری طی می‌کند:

گام ۱: شناسایی هویت درخواست‌کننده

در ابتدا کوبرنتیز مشخص می‌کند درخواست از طرف چه هویتی ارسال شده است. این هویت می‌تواند یک کاربر، گروه یا Service Account باشد.

گام ۲: بررسی Rol‍eها و ClusterRoleها

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

گام ۳: بررسی Bindingها

در ادامه، کوبرنتیز بررسی می‌کند که آیا Role یا ClusterRole موردنظر از طریق RoleBinding یا ClusterRoleBinding به آن کاربر یا Service Account متصل شده است یا خیر.

گام ۴: تطبیق درخواست با مجوزها

در این مرحله، کوبرنتیز نوع عملیات درخواستی (مانند get ،list یا delete) و منبع هدف (مانند Pod یا Service) را با قوانین تعریف‌شده در RBAC تطبیق می‌دهد.

گام ۵: صدور نتیجه نهایی

اگر مجوز لازم وجود داشته باشد، درخواست تأیید می‌شود و کاربر به منبع موردنظر دسترسی پیدا می‌کند. در غیر این صورت، کوبرنتیز درخواست را با خطای 403 Forbidden رد می‌کند.

آموزش عملی پیاده‌سازی RBAC در کوبرنتیز (به همراه کد)

در این مثال، یک Service Account ایجاد می‌کنیم که فقط اجازه مشاهده Serviceها و ConfigMapها را در یک Namespace مشخص داشته باشد.

گام ۱: ایجاد Namespace و Service Account

ابتدا یک Namespace و سپس یک Service Account اختصاصی ایجاد می‌کنیم:

kubectl create namespace random-numbers
kubectl create sa random-numbers-sa -n random-numbers

kubectl create namespace random-numbers
kubectl create sa random-numbers-sa -n random-numbers

گام ۲: تعریف Role

در این مرحله، یک Role در فایلی به نام فایل به نام role.yaml می‌سازیم که فقط دسترسی get و list را روی Serviceها و ConfigMapها داشته باشد.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: random-numbers
  name: client-access-role
rules:
- apiGroups: [""]
  resources:
    - configmaps
    - services
  verbs:
    - get
    - list

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: random-numbers
  name: client-access-role
rules:
- apiGroups: [""]
  resources:
    - configmaps
    - services
  verbs:
    - get
    - list

برای اعمال این Role روی کلاستر، دستور زیر را اجرا کنید:

kubectl apply -f role.yaml

kubectl apply -f role.yaml

گام ۳: ایجاد RoleBinding

اکنون باید Role تعریف‌شده را به Service Account متصل کنیم. فایل yaml زیر با نام rolebinding.yaml را ایجاد کنید:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: client-access-role-binding
  namespace: random-numbers
subjects:
- kind: ServiceAccount
  name: random-numbers-sa
  namespace: random-numbers
roleRef:
  kind: Role
  name: client-access-role
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: client-access-role-binding
  namespace: random-numbers
subjects:
- kind: ServiceAccount
  name: random-numbers-sa
  namespace: random-numbers
roleRef:
  kind: Role
  name: client-access-role
  apiGroup: rbac.authorization.k8s.io

برای اعمال RoleBinding دستور زیر را اجرا کنید:

kubectl apply -f rolebinding.yaml

kubectl apply -f rolebinding.yaml

گام ۴: راه‌اندازی پاد تست با سرویس‌اکانت اختصاصی

در ادامه یک پاد می‌سازیم تا بتوانیم درخواست‌های امنیتی را از داخل کلاستر تست کنیم. برای انجام این کار فایلی به نام pod-test.yaml بسازید و کد زیر را در آن قرار دهید:

apiVersion: v1
kind: Pod
metadata:
  name: curlo
  namespace: random-numbers
spec:
  serviceAccountName: random-numbers-sa
  containers:
  - name: curlo
    image: curlimages/curl
    command: ["sleep","999999"]

apiVersion: v1
kind: Pod
metadata:
  name: curlo
  namespace: random-numbers
spec:
  serviceAccountName: random-numbers-sa
  containers:
  - name: curlo
    image: curlimages/curl
    command: ["sleep","999999"]

پاد را اجرا کنید:

kubectl apply -f pod-test.yaml

kubectl apply -f pod-test.yaml

گام ۵: بررسی سطح دسترسی

ابتدا وارد Pod شوید:

kubectl exec -it curlo -n random-numbers -- /bin/sh

kubectl exec -it curlo -n random-numbers -- /bin/sh

سپس توکن Service Account را برای ارسال درخواست به API Server تنظیم کنید:

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

آزمایش اول: بررسی دسترسی مجاز (مشاهده سرویس‌ها)

یک درخواست به آدرس API سرویس‌های این Namespace می‌فرستیم:

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/services

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/services

در صورت موفقیت، Kubernetes اطلاعات Serviceها را با پاسخ 200 OK برمی‌گرداند.

آزمایش دوم: بررسی دسترسی غیرمجاز

اکنون درخواست مشاهده Podها را ارسال می‌کنیم:

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/pods

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/pods

چون در Role تعریف‌شده مجوز دسترسی به Podها وجود ندارد، Kubernetes پاسخ 403 Forbidden را برمی‌گرداند:

{
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:random-numbers:random-numbers-sa\" cannot list resource \"pods\" in the namespace \"random-numbers\"",
  "reason": "Forbidden",
  "code": 403
}

{
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:random-numbers:random-numbers-sa\" cannot list resource \"pods\" in the namespace \"random-numbers\"",
  "reason": "Forbidden",
  "code": 403
}

بهترین روش‌ها (Best Practices) برای پیاده‌سازی RBAC

پیاده‌سازی صحیح RBAC در کوبرنتیز نقش مهمی در کاهش ریسک‌های امنیتی و کنترل دسترسی کاربران دارد. مهم‌ترین راهکارهای این حوزه عبارت‌اند از:

اصل حداقل دسترسی (Least Privilege)

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

استفاده از Role و RoleBinding در سطح Namespace

در بیشتر سناریوها، بهتر است دسترسی‌ها در سطح Namespace مدیریت شوند. استفاده از Role و RoleBinding باعث می‌شود دامنه دسترسی محدود بماند و ایزوله‌سازی بین محیط‌هایی مانند dev و prod حفظ شود.

محدود کردن استفاده از ClusterRole و ClusterRoleBinding

ClusterRole و ClusterRoleBinding فقط باید برای دسترسی‌های سراسری یا منابع cluster-scoped استفاده شوند. استفاده غیرضروری از آن‌ها می‌تواند سطح دسترسی کاربران را بیش از حد افزایش دهد.

استفاده از Service Account اختصاصی

بهتر است هر Pod یا برنامه از Service Account اختصاصی خود استفاده کند و به Service Account پیش‌فرض Namespace وابسته نباشد. این کار باعث می‌شود دسترسی سرویس‌ها از یکدیگر جدا شود.

همچنین در صورت عدم نیاز، می‌توان قابلیت mount خودکار توکن Service Account را با تنظیم automountServiceAccountToken: false غیرفعال کرد.

بازبینی و حساب‌رسی دوره‌ای

تنظیمات RBAC باید به‌صورت دوره‌ای بررسی شوند تا دسترسی‌های قدیمی، RoleBindingهای بلااستفاده یا مجوزهای غیرضروری حذف شوند. همچنین دسترسی‌های حساس، به‌ویژه اعضای گروه system:masters، باید به‌صورت مستمر کنترل شوند.

اشتباهات رایج در مدیریت RBAC کوبرنتیز

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

استفاده از ClusterRoleBinding به‌جای RoleBinding

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

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

دادن دسترسی * در منابع یا عملیات‌ها عملاً تمام محدودیت‌های RBAC را از بین می‌برد و باعث ایجاد دسترسی‌های غیرقابل‌کنترل می‌شود.

استفاده از حساب cluster-admin برای کارهای روزمره

حساب cluster-admin دسترسی کامل به کل کلاستر دارد. استفاده روزمره از آن ریسک خطای انسانی را به‌شدت افزایش می‌دهد و می‌تواند منجر به تغییرات مخرب در کل سیستم شود.

اضافه کردن کاربران به گروه system:masters

عضویت در این گروه باعث دور زدن کامل RBAC می‌شود. این سطح دسترسی عملاً معادل دسترسی روت در کل کلاستر است و باید به‌شدت محدود شود.

استفاده از Service Account پیش‌فرض

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

فعال‌سازی تنظیمات ناامن در API Server

فعال کردن گزینه‌هایی مانند --insecure-port یا --anonymous-auth می‌تواند لایه احراز هویت و کنترل دسترسی را عملاً بی‌اثر کند.

عدم بازبینی دوره‌ای دسترسی‌ها

اگر Roleها و RoleBindingها به‌صورت دوره‌ای بررسی نشوند، دسترسی‌های قدیمی و غیرضروری باقی می‌مانند و به مرور زمان سطح حمله (Attack Surface) را افزایش می‌دهند.

نادیده گرفتن تغییرات سازمانی

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

محدودیت‌های سیستم RBAC در کوبرنتیز

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

۱. عدم کنترل روی محتوای منابع

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

۲. عدم جلوگیری از Privilege Escalation در سطح Pod

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

۳. محدودیت در کنترل منابع زیرساختی

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

۴. عدم کنترل روی عملیات‌های حساس خاص

برخی عملیات مانند impersonate ،bind و escalate می‌توانند منجر به دور زدن سیاست‌های دسترسی شوند. RBAC این عملیات‌ها را در سطح منطقی کنترل می‌کند، اما سوءاستفاده از آن‌ها در صورت داشتن مجوز، همچنان امکان‌پذیر است.

۵. محدودیت در برابر حملات سطح کلاستر

RBAC توانایی محدود کردن رفتارهایی مانند ایجاد حجم بالای resource و مصرف بیش از حد etcd یا CPU را ندارد. برای این موارد باید از مکانیزم‌های مکمل مانند ResourceQuota و LimitRange استفاده شود.

جمع‌بندی

RBAC در کوبرنتیز یکی از مهم‌ترین لایه‌های امنیتی برای مدیریت دسترسی کاربران و سرویس‌ها در کلاستر است. این مکانیزم بر پایه تعریف نقش‌ها (Role و ClusterRole)، اتصال آن‌ها به هویت‌ها (RoleBinding و ClusterRoleBinding) و اعمال سیاست‌های دسترسی در سطح API Server عمل می‌کند.

در سطح عملی، RBAC به شما اجازه می‌دهد دسترسی‌ها را به‌صورت دقیق و محدود در سطح Namespace یا کل کلاستر کنترل کنید و اصل Least Privilege را پیاده‌سازی کنید. با این حال، این سیستم به‌تنهایی کافی نیست و باید در کنار سایر مکانیزم‌های امنیتی مانند ResourceQuota، LimitRange و سیاست‌های امنیتی تکمیلی استفاده شود.

همچنین بیشترین خطاها در پیاده‌سازی RBAC معمولاً ناشی از استفاده بیش از حد از دسترسی‌های سراسری، بی‌توجهی به Service Accountها و عدم بازبینی دوره‌ای مجوزهاست. در نهایت، RBAC یک ابزار پایه و ضروری برای امنیت Kubernetes است، اما ارزش واقعی آن زمانی مشخص می‌شود که به‌درستی طراحی، محدود و در کنار سایر لایه‌های امنیتی استفاده شود.

The post RBAC در کوبرنتیز چیست؟ آشنایی با اجزا و روش‌های پیاده‌سازی appeared first on بلاگ هم‌روش.

Gateway API چیست؟

Gateway API در کوبرنتیز مجموعه‌ای از resourceها و APIهای استاندارد برای مدیریت ترافیک شبکه در کوبرنتیز است. این API با هدف رفع محدودیت‌های Ingress طراحی شد و امکان مدیریت پیشرفته‌تر ترافیک HTTP ،HTTPS ،TCP ،TLS و gRPC را فراهم می‌کند.

Gateway API در کوبرنتیز از چند مؤلفه اصلی تشکیل شده است که هرکدام نقش مشخصی در مدیریت ترافیک دارند:

• GatewayClass مشخص می‌کند که کدام کنترلر مسئول پیاده‌سازی Gateway است.
• Gateway نقطه ورود ترافیک به کلاستر را تعریف می‌کند.
• Routeها مانند HTTPRoute قوانین مسیریابی درخواست‌ها را مشخص می‌کنند.

یکی از ویژگی‌های اصلی Gateway API در کوبرنتیز مدل نقش‌محور آن است. در این مدل، مسئولیت‌ها بین نقش‌های مختلف مانند تیم زیرساخت، امنیت و توسعه تفکیک می‌شود تا هر تیم بتواند بخش مربوط به خود را مستقل مدیریت کند.

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

امروزه پروژه‌هایی مانند Envoy Gateway ،Istio ،Kong و NGINX Gateway Fabric از Gateway API پشتیبانی می‌کنند و این API به یکی از بخش‌های مهم اکوسیستم networking در کوبرنتیز تبدیل شده است.

چرا Ingress دیگر کافی نیست؟

Ingress سال‌ها روش استاندارد مدیریت ترافیک HTTP و HTTPS در کوبرنتیز بود، اما با پیچیده‌تر شدن معماری‌های cloud-native دیگر پاسخگوی نیازهای جدید نبود.

Ingress در ابتدا برای سناریوهای ساده routing طراحی شده بود و بسیاری از قابلیت‌های پیشرفته networking را به‌صورت استاندارد ارائه نمی‌داد. به همین دلیل، Ingress Controllerها برای افزودن قابلیت‌های بیشتر به annotationهای اختصاصی وابسته شدند. annotationها نوعی متادیتا هستند که به منابع کوبرنتیز اضافه می‌شوند تا تنظیمات یا رفتارهای اضافی را برای کنترلرها تعریف کنند.

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

مجموعه این محدودیت‌ها باعث شد Ingress به‌مرور برای بسیاری از سناریوهای جدید cloud-native کافی نباشد؛ مخصوصاً در معماری‌های بزرگ، محیط‌های چندتیمی و زیرساخت‌هایی که به مدیریت پیشرفته‌تر ترافیک نیاز داشتند. به همین دلیل جامعه توسعه‌دهندگان کوبرنتیز به‌سمت طراحی API جدیدی حرکت کرد که بتواند مدیریت ترافیک شبکه را انعطاف‌پذیرتر، استانداردتر و قابل گسترش‌تر کند. نتیجه این تلاش، Gateway API بود.

تفاوت Ingress و Gateway API

تفاوت اصلی Ingress و Gateway API در کوبرنتیز در مدل طراحی و سطح انتزاع (abstraction level) آن‌ها است. Ingress یک API ساده و متمرکز برای مدیریت ترافیک HTTP/HTTPS است، در حالی که Gateway API یک مدل نقش‌محور و چندلایه برای مدیریت پیشرفته‌تر ترافیک در کوبرنتیز ارائه می‌دهد.

در Ingress، تمام منطق مسیریابی در یک resource واحد تعریف می‌شود که باعث سادگی، اما محدودیت در سناریوهای پیچیده می‌شود. در مقابل، Gateway API این مسئولیت‌ها را بین چند resource مستقل تقسیم می‌کند تا مدیریت شبکه قابل توسعه‌تر و منعطف‌تر شود.

از نظر مدل مدیریت، تفاوت مهم دیگر در نحوه تقسیم مسئولیت‌ها بین تیم‌ها است. در Ingress معمولاً یک تیم باید هم زیرساخت و هم قوانین routing را مدیریت کند. اما در Gateway API این مسئولیت‌ها قابل تفکیک هستند و هر تیم می‌تواند بخش مشخصی از شبکه را مدیریت کند.

از نظر قابلیت‌ها نیز تفاوت قابل توجهی وجود دارد. Ingress عمدتاً برای HTTP و HTTPS طراحی شده است، در حالی که Gateway API از پروتکل‌های بیشتری از جمله موارد زیر پشتیبانی می‌کند:

• HTTP و HTTPS
• TCP
• TLS
• gRPC

همچنین Gateway API در کوبرنتیز امکان تعریف قابلیت‌های پیشرفته‌تری را به‌صورت استاندارد و قابل توسعه فراهم می‌کند؛ از جمله مسیریابی مبتنی بر هدر، تقسیم ترافیک بین سرویس‌ها و مسیریابی بین چند فضای نام کوبرنتیز مختلف (Namespaceها). در حالی که در Ingress این نوع قابلیت‌ها معمولاً وابسته به پیاده‌سازی هر کنترلر کوبرنتیز هستند و استاندارد واحدی برای آن‌ها وجود ندارد.

در نتیجه، تفاوت اصلی این دو مدل در این است که Ingress یک راهکار ساده و محدود برای سناریوهای پایه است، در حالی که Gateway API یک چارچوب استاندارد و قابل توسعه برای مدیریت پیچیده‌تر ترافیک در کوبرنتیز محسوب می‌شود.

معماری و اجزای اصلی Gateway API

Gateway API در کوبرنتیز بر پایه یک مدل معماری نقش‌محور طراحی شده است که در آن مسئولیت مدیریت ترافیک بین چند resource مستقل تقسیم می‌شود. این طراحی برای کاهش پیچیدگی Ingress و ایجاد ساختاری قابل توسعه در سناریوهای پیشرفته شبکه شکل گرفته است.

در این معماری، به‌جای اینکه تمام منطق routing و پیکربندی شبکه در یک resource واحد متمرکز شود، اجزای مختلفی تعریف شده‌اند که هرکدام نقش مشخصی دارند و در کنار هم سیستم مدیریت ترافیک را تشکیل می‌دهند. در معماری Gateway API، سه مؤلفه اصلی نقش کلیدی دارند.

GatewayClass

GatewayClass مشخص می‌کند که کدام کنترلر مسئول پیاده‌سازی و مدیریت Gatewayها در کلاستر است. این بخش در واقع نقش template یا کلاس رفتاری برای Gatewayها را دارد و تعیین می‌کند که کل سیستم از چه نوع پیاده‌سازی networking استفاده کند.

Gateway

Gateway نقطه ورود ترافیک به کلاستر است. این resource مشخص می‌کند که ترافیک از چه مسیرهایی وارد می‌شود و چه listenerهایی برای دریافت درخواست‌ها فعال هستند. به عبارت دیگر Gateway نقطه اتصال بین دنیای بیرونی و سرویس‌های داخل کوبرنتیز است.

Routeها

Routeها مسئول تعریف قوانین مسیریابی در Gateway API هستند. این resourceها مشخص می‌کنند درخواست‌ها بر اساس چه معیارهایی به سرویس‌های داخلی هدایت شوند. این معیارها می‌توانند شامل مسیر URL، هدرها یا سایر ویژگی‌های درخواست باشند.

HTTPRoute یکی از مهم‌ترین انواع Route است که امکان مسیریابی بر اساس ویژگی‌های HTTP مانند مسیر درخواست، هدرها و سایر مشخصه‌ها را فراهم می‌کند. علاوه بر آن، Routeهای دیگری نیز برای پروتکل‌هایی مانند TCP ،TLS و gRPC وجود دارند.

یکی از نکات مهم در معماری Gateway API در کوبرنتیز این است که این سه بخش به‌صورت مستقل از هم طراحی شده‌اند. این جداسازی باعث می‌شود مدیریت شبکه در کوبرنتیز انعطاف‌پذیرتر شود و امکان تقسیم مسئولیت بین تیم‌های مختلف فراهم شود. در این مدل، تیم زیرساخت معمولاً GatewayClass و Gateway را مدیریت می‌کند، در حالی که تیم‌های توسعه می‌توانند Routeهای مربوط به سرویس‌های خود را به‌صورت مستقل تعریف و کنترل کنند.

یک مثال ساده

مثال زیر یک Gateway ساده را نشان می‌دهد که ترافیک HTTP را روی پورت ۸۰ دریافت می‌کند:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80

در این تعریف:

• Gateway به یک GatewayClass متصل است که تعیین می‌کند کدام کنترلر آن را مدیریت کند
• یک نقطه ورود ترافیک روی پورت ۸۰ ایجاد شده است
• پروتکل HTTP برای دریافت درخواست‌ها مشخص شده است

در مثال زیر برای تشریح HTTPRoute (تعریف قوانین مسیریابی)، مشخص شده که درخواست‌ها باید به کدام سرویس داخلی ارسال شوند:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: example-service
          port: 8080

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: example-service
          port: 8080

در اینجا:

• این Route به Gateway قبلی متصل شده است
• تمام درخواست‌های شروع شده با مسیر / تطبیق داده می‌شوند.
• ترافیک به سرویس example-service روی پورت ۸۰۸۰ هدایت می‌شود

مزایای Gateway API

Gateway API در کوبرنتیز در سناریوهای واقعی چند مزیت کلیدی نسبت به مدل Ingress دارد:

تفکیک مسئولیت‌ها در معماری شبکه

در Gateway API، وظایف مربوط به زیرساخت، نقطه ورود ترافیک و قوانین مسیریابی از هم جدا شده‌اند و هر بخش می‌تواند به‌صورت مستقل مدیریت شود.

کاهش وابستگی به annotationهای اختصاصی

بسیاری از قابلیت‌هایی که در Ingress وابسته به پیاده‌سازی کنترلر بودند، در Gateway API به‌صورت استاندارد و قابل پیش‌بینی تعریف می‌شوند.

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

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

پشتیبانی گسترده‌تر از پروتکل‌ها
Gateway API در کوبرنتیز علاوه بر HTTP و HTTPS، از پروتکل‌هایی مانند TCP ،TLS و gRPC به‌صورت استاندارد پشتیبانی می‌کند.

چالش‌ها و محدودیت‌های Gateway API

با وجود مزایای معماری Gateway API، این مدل هنوز بدون چالش نیست و در بسیاری از سناریوهای عملی محدودیت‌هایی دارد:

ناهمگونی در پیاده‌سازی کنترلرها
همه کنترلرها هنوز سطح یکسانی از پشتیبانی از Gateway API ندارند و برخی قابلیت‌ها ممکن است در همه پیاده‌سازی‌ها در دسترس نباشند.

پیچیدگی بیشتر نسبت به Ingress
مدل Gateway API در کوبرنتیز به‌جای یک resource واحد، از چند resource جدا استفاده می‌کند. این موضوع اگرچه از نظر معماری مزیت است، اما در عمل باعث افزایش پیچیدگی مفهومی و یادگیری می‌شود.

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

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

هم‌زیستی با Ingress در بسیاری از محیط‌ها
در عمل، بسیاری از سازمان‌ها هنوز به‌طور کامل به Gateway API مهاجرت نکرده‌اند و استفاده هم‌زمان از Ingress و Gateway API در یک کلاستر رایج است.

مهاجرت از Ingress به Gateway API در کوبرنتیز

مهاجرت از Ingress به Gateway API یک تغییر تدریجی در معماری شبکه است، نه یک جایگزینی ساده. چون این دو مدل ساختار متفاوتی دارند، مهاجرت معمولاً نیازمند بازطراحی بخشی از منابع شبکه در کلاستر است.

در مدل Ingress، تمام تنظیمات routing در یک resource واحد تعریف می‌شود. اما در Gateway API این مسئولیت بین چند resource جدا مانند GatewayClass ،Gateway و Routeها تقسیم شده است. به همین دلیل، اولین گام در مهاجرت، درک و بازنویسی این تفکیک مسئولیت‌ها است.

در فرایند مهاجرت، معمولاً ابتدا یک Gateway جدید در کنار Ingressهای موجود ایجاد می‌شود. این Gateway به یک کنترلر سازگار متصل می‌شود و به‌صورت تدریجی بخشی از ترافیک را از Ingress به سمت Routeهای جدید هدایت می‌کند.

در این مرحله، یکی از چالش‌های اصلی، بازنویسی تنظیمات Ingress است. بسیاری از قابلیت‌هایی که قبلاً از طریق annotationها تعریف می‌شدند، باید در قالب resourceهای استاندارد Gateway API بازتعریف شوند. این موضوع نیازمند بررسی دقیق رفتار Ingressهای موجود و تبدیل آن‌ها به معادل‌های Gateway API است.

همچنین در مهاجرت باید توجه شود که همه قابلیت‌های Ingress ممکن است معادل مستقیم در Gateway API نداشته باشند یا پیاده‌سازی آن‌ها وابسته به کنترلر انتخاب‌شده باشد. بنابراین انتخاب کنترلر سازگار با نیازهای پروژه نقش مهمی در موفقیت مهاجرت دارد.

در نهایت، مهاجرت معمولاً به‌صورت مرحله‌ای انجام می‌شود؛ به‌طوری که Ingress و Gateway API برای مدتی در کنار هم در کلاستر وجود دارند تا انتقال ترافیک بدون اختلال انجام شود.

سخن پایانی

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

The post آشنایی با Gateway API در کوبرنتیز؛ بررسی معماری و مقایسه با Ingress appeared first on بلاگ هم‌روش.

Namespace در کوبرنتیز چیست؟

Namespace در کوبرنتیز یک مکانیزم برای تقسیم‌بندی منطقی منابع داخل یک کلاستر است که برای کاهش پیچیدگی مدیریت منابع در محیط‌های چندکاربره و چندپروژه‌ای طراحی شده است. این قابلیت اجازه می‌دهد منابعی مانند Pod ،Service و Deployment در محدوده‌های جداگانه سازمان‌دهی شوند، بدون اینکه نیاز به ایجاد چند کلاستر مستقل باشد.

در یک کلاستر کوبرنتیز، زمانی که چند تیم، پروژه یا محیط (مانند dev ،staging و production) به‌صورت همزمان کار می‌کنند، قرار گرفتن همه منابع در یک فضای مشترک می‌تواند باعث پیچیدگی در مدیریت، افزایش احتمال خطا در دسترسی‌ها و دشواری در تفکیک منابع شود. Namespace این مشکل را با ایجاد محدوده‌های منطقی برای منابع حل می‌کند.

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

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

Namespaceهای پیش‌فرض در کوبرنتیز

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

default: اگر هنگام ایجاد منابع، Namespace مشخصی تعیین نشده باشد. منابع به‌صورت خودکار در این فضا قرار می‌گیرند.

kube-system: شامل منابع و اجزای داخلی کوبرنتیز است. کامپوننت‌هایی که برای عملکرد کلاستر ضروری هستند (مانند برخی سرویس‌های سیستمی از جمله kube-dns ،kube-proxy و …)، در این بخش قرار دارند.

kube-public: به‌گونه‌ای تنظیم شده است که به‌صورت عمومی قابل خواندن باشد. این فضا برای منابعی استفاده می‌شود که نیاز به دسترسی عمومی دارند.

kube-node-lease: این فضای نام کوبرنتیز به مدیریت وضعیت نودها در کلاستر کمک می‌کند و کوبرنتیز به کمک آن می‌تواند بدون ایجاد بار بیش از حد روی سیستم، از زنده‌بودن نودها مطمئن شود.

Namespace و RBAC در کوبرنتیز

در کوبرنتیز، کنترل دسترسی به منابع از طریق مکانیزم RBAC (مخفف Role-Based Access Control) انجام می‌شود. این سیستم امکان تعریف سطح دسترسی کاربران و سرویس‌ها را فراهم می‌کند.

در RBAC، دو مفهوم اصلی وجود دارد:

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

برای اعمال دسترسی در سطح کل کلاستر، از ClusterRole و ClusterRoleBinding استفاده می‌شود که خارج از محدوده Namespace عمل می‌کنند.

به این ترتیب، Namespace نقش مهمی در محدود کردن دامنه دسترسی‌ها در ساختار RBAC دارد و امکان جداسازی سطح دسترسی بین تیم‌ها و پروژه‌ها را فراهم می‌کند.

Namespace و مدیریت منابع (ResourceQuota و LimitRange)

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

با استفاده از مکانیزم ResourceQuota می‌توان میزان کل منابع قابل استفاده در یک Namespace را محدود کرد. این محدودیت می‌تواند شامل CPU، حافظه، تعداد پادها و سایر منابع قابل شمارش باشد. این مکانیزم باعث می‌شود مصرف منابع در یک Namespace از حد مشخصی فراتر نرود.

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

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

نحوه ارتباط بین Namespaceها

در کوبرنتیز، Namespaceها در سطح نام‌گذاری و سازمان‌دهی منابع از هم جدا هستند، اما این جداسازی به‌تنهایی به معنای جداسازی شبکه‌ای نیست.

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

در زمینه DNS، کوبرنتیز برای سرویس‌ها در هر Namespace یک نام دامنه داخلی ایجاد می‌کند. ساختار نام‌گذاری سرویس‌ها به‌گونه‌ای است که شامل نام سرویس و Namespace آن می‌شود و از طریق DNS داخلی کلاستر قابل دسترسی است.

به این ترتیب، ارتباط بین Namespaceها هم از طریق شبکه و هم از طریق DNS امکان‌پذیر است، مگر اینکه به‌صورت مشخص با سیاست‌های شبکه محدود شده باشد.

چگونه در کوبرنتیز Namespace جدید ایجاد کنیم؟

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

روش اول: ایجاد Namespace از طریق فایل YAML

در مرحله اول نیاز است که یک فایل YAML ایجاد کنید. نام آن را my-namespace.yaml قرار داده و اطلاعات زیر را در آن قرار دهید:

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1

یکی از بخش‌های مهم فایل مقدار kind است که آن را Namespace قرار داده‌ایم.

همچنین نام Namespace جدید را namespace1 قرار داده‌ایم. برای نام‌گذاری مطمئن شوید که در کلاستر مورد نظر، قبلا فضای نام دیگری را با این عنوان ندارید.

در قدم بعدی با استفاده از دستور زیر namespace مورد نظر را ایجاد کنید:

kubectl create -f ./my-namespace.yaml

kubectl create -f ./my-namespace.yaml

برای مشاهده Namespace ساخته شده می‌توانید دستور زیر را وارد کنید:

kubectl get namespace namespace1

kubectl get namespace namespace1

همچنین برای مشاهده جزئیات بیشتر Namespace ساخته شده، دستور زیر را وارد کنید:

kubectl describe namespace namespace1

kubectl describe namespace namespace1

روش دوم: ایجاد Namespace بدون فایل YAML

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

kubectl create namespace namespace1

kubectl create namespace namespace1

اشتباهات رایج در استفاده از Namespace کوبرنتیز

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

یکی از اشتباهات رایج این است که از Namespace به‌عنوان مرز کامل امنیتی استفاده می‌شود. در حالی که Namespace به‌تنهایی تضمین‌کننده ایزوله‌سازی کامل نیست و برای کنترل امنیت باید از مکانیزم‌هایی مانند Network Policy و RBAC استفاده شود.

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

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

همچنین استفاده نکردن از استاندارد مشخص برای نام‌گذاری Namespaceها باعث سردرگمی در محیط‌های چند تیمی و چند پروژه‌ای می‌شود.

جمع‌بندی

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

Namespaceها همچنین نقش مهمی در کنترل دسترسی و مدیریت سیاست‌ها دارند. با استفاده از آن‌ها می‌توان محدوده اعمال RBAC را مشخص کرد و همچنین از طریق ResourceQuota و LimitRange مصرف منابع را در هر محدوده کنترل کرد.

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

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

The post آشنایی با مفهوم Namespace در کوبرنتیز؛ آموزش نحوه ساخت appeared first on بلاگ هم‌روش.

Workload در کوبرنتیز چیست؟

Workload در کوبرنتیز برنامه یا سرویسی است که روی کلاستر اجرا می‌شود و نحوه استقرار، اجرا و مقیاس‌دهی آن بر اساس وضعیت مورد انتظار (desired state) مشخص می‌شود. کوبرنتیز این وضعیت را دریافت کرده و با استفاده از مکانیزم‌های خود، اجرای برنامه را مدیریت می‌کند تا وضعیت واقعی (actual state) با وضعیت مورد انتظار مطابقت داشته باشد.

Workloadها معمولاً در قالب مجموعه‌ای از پادها اجرا می‌شوند (هر پاد شامل یک یا چند کانتینر است). به‌جای اینکه کاربر مستقیماً پادها را مدیریت کند، کوبرنتیز از منابعی مانند Deployment ،StatefulSet و Job استفاده می‌کند تا این وضعیت را به‌صورت خودکار اعمال و کنترل کند.

انواع Workload در کوبرنتیز

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

Pod

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

کاربردهای Pod

• اجرای چند کانتینر که باید با هم و همزمان کار کنند، مانند یک وب‌سرور و یک کانتینر لاگ‌گیری مرتبط
• اجرای یک کانتینر ساده که نیازی به مقیاس‌پذیری ندارد

Deployment

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

کاربردهای Deployment

• اجرای برنامه‌هایی که نیاز به مقیاس‌پذیری دارند
• مدیریت به‌روزرسانی تدریجی نسخه‌ها (Rolling Update) و امکان بازگشت (Rollback)
• توزیع بار کاری بین چندین پاد مشابه برای افزایش دسترس‌پذیری

StatefulSet

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

کاربردهای StatefulSet

• اجرای برنامه‌های stateful مانند پایگاه‌های داده (مثلاً MySQL یا PostgreSQL)
• سرویس‌هایی که نیاز به شناسه و ترتیب خاص برای پادها دارند، مانند Zookeeper یا Cassandra
• هنگامی که نیاز است داده‌های هر Pod پس از حذف یا بازسازی حفظ شود

DaemonSet

DaemonSet نوعی Workload در کوبرنتیز است که تضمین می‌کند یک Pod روی همه یا گروه خاصی از نودها اجرا شود. این نوع ورک لود معمولاً برای وظایف سیستمی یا پس‌زمینه که باید روی تمام نودها فعال باشند، استفاده می‌شود.

کاربردهای DaemonSet

• جمع‌آوری لاگ‌ها و متریک‌ها از تمام نودها
• اجرای ابزارهای مانیتورینگ یا امنیتی روی همه نودها
• نصب و مدیریت نرم‌افزارهایی که باید در تمام نودها اجرا شوند

Job

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

کاربردهای Job

• پردازش دسته‌ای داده‌ها (batch processing)
• اجرای اسکریپت یا فرایندهای موقتی مثل بکاپ‌گیری
• عملیات‌هایی که فقط یک‌بار و تا تکمیل شدن لازم است اجرا شوند

CronJob

CronJob در کوبرنتیز نسخه زمان‌بندی‌شده Job است که مشابه cron در لینوکس امکان اجرای وظایف به صورت دوره‌ای و با زمان‌بندی قبلی را فراهم می‌کند. CronJob زمانی کاربرد دارد که نیاز باشد یک وظیفه به صورت منظم و خودکار تکرار شود.

کاربردهای CronJob

• اجرای وظایف دوره‌ای مانند ارسال گزارش‌های ایمیل
• پاکسازی دوره‌ای داده‌ها یا maintenanceهای زمان‌بندی شده
• هر وظیفه‌ای که باید در فواصل زمانی مشخص تکرار شود

کاربردهای Workload در کوبرنتیز

Workloadها نقش کلیدی در اجرای برنامه‌ها و سرویس‌ها روی کوبرنتیز دارند و به مدیریت مؤثر برنامه‌ها در یک محیط مقیاس‌پذیر کمک می‌کنند. برخی از کاربردهای اصلی ورک لود عبارت‌اند از:

1. اجرای برنامه‌های وب و سرویس‌ها
   با استفاده از Deployment و ReplicaSet می‌توان برنامه‌های وب و سرویس‌ها را به‌صورت مداوم و مقیاس‌پذیر اجرا کرد. این Workloadها همچنین به‌روزرسانی نسخه‌ها و مقیاس‌دهی پویا را تسهیل می‌کنند.
2. مدیریت وظایف موقت و یک‌باره
   Job برای اجرای وظایف موقت و تک‌مرحله‌ای مناسب است و CronJob همان وظایف را به صورت زمان‌بندی‌شده اجرا می‌کند. برای مثال، می‌توان از Job برای پردازش داده‌ها و از CronJob برای پاکسازی یا بکاپ‌گیری دوره‌ای استفاده کرد.
3. اجرای برنامه‌های Stateful
   StatefulSet برای برنامه‌هایی مانند پایگاه‌های داده و سیستم‌های ذخیره‌سازی کاربرد دارد؛ زیرا ترتیب و هویت یکتا برای هر پاد را حفظ می‌کند.
4. اجرای وظایف سیستمی و سرویس‌های پس‌زمینه
   DaemonSet برای اجرای ابزارهای مانیتورینگ، جمع‌آوری لاگ‌ها و وظایف امنیتی روی هر نود استفاده می‌شود و تضمین می‌کند که این پادها روی تمام نودهای هدف اجرا شوند.
5. مدیریت بار کاری توزیع‌شده
   کوبرنتیز می‌تواند با استفاده از مقیاس‌دهی خودکار (Auto-Scaling) تعداد پادها را بر اساس میزان بار کاری و معیارهای تعریف‌شده افزایش یا کاهش دهد. این ویژگی بهره‌وری منابع را بهبود می‌بخشد و هزینه‌ها را کاهش می‌دهد.
6. اجرای برنامه‌های مایکروسرویس و پشتیبانی از CI/CD
   با ترکیب Deployment برای مدیریت نسخه‌ها و مقیاس‌دهی، Service برای دسترسی و load balancing داخلی و Gateway یا Ingress برای مدیریت ترافیک ورودی، می‌توان برنامه‌های مایکروسرویس را به صورت مقیاس‌پذیر و قابل مدیریت اجرا کرد. کوبرنتیز همچنین با ابزارهای CI/CD یکپارچه می‌شود تا فرایند توسعه، تست و انتشار نرم‌افزار به‌صورت خودکار انجام شود.
7. بهبود دسترس‌پذیری و تاب‌آوری
   با توزیع بارکاری بین نودهای مختلف و استفاده از مکانیزم‌های بازسازی خودکار، کوبرنتیز به افزایش دسترس‌پذیری و تاب‌آوری برنامه‌ها کمک می‌کند.

مقایسه کلی انواع Workload در کوبرنتیز

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

سخن پایانی

Workload در کوبرنتیز هسته اصلی اجرای برنامه‌ها روی کلاستر است و تعیین می‌کند که هر برنامه چگونه اجرا، مقیاس‌دهی و مدیریت شود. همان‌طور که دیدیم، انواع مختلفی از Workloadها وجود دارند که هرکدام برای سناریوهای مشخصی طراحی شده‌اند. انتخاب درست Workload تأثیر مستقیمی بر عملکرد، پایداری و مقیاس‌پذیری برنامه دارد. برای مثال، Deployment برای برنامه‌های Stateless و StatefulSet برای برنامه‌های دارای داده پایدار و Job یا CronJob برای وظایف موقت و زمان‌بندی‌شده مناسب هستند. در نهایت، درک دقیق مفهوم Workload در کوبرنتیز و شناخت تفاوت بین انواع آن، به شما کمک می‌کند تصمیم‌های بهتری در طراحی و اجرای برنامه‌ها بگیرید و از امکانات Kubernetes به‌صورت مؤثرتر استفاده کنید.

اگر قصد دارید از این مفاهیم در عمل استفاده کنید، پلتفرم‌‌‌های ابری می‌توانند این مسیر را ساده‌تر کنند. برای مثال پلتفرم ابری دارکوب هم‌روش این امکان را فراهم می‌کند که تنها با یک داکرفایل، برنامه خود را بر بستر کوبرنتیز اجرا کنید. علاوه بر این کوبرنتیز مدیریت‌شده هم‌روش به صورت اختصاصی (کلاستر ابری یا on-premises) به سازمان‌ها ارائه می‌شود.

The post آشنایی با Workload در کوبرنتیز؛ انواع و کاربردها appeared first on بلاگ هم‌روش.

خود ترمیمی یا Self-healing در کوبرنتیز چیست؟

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

عملکرد خود ترمیمی در سطوح مختلفی انجام می‌شود:

• سطح پاد:
  • در صورت پیکربندی Liveness Probe، وضعیت کانتینرها به‌صورت دوره‌ای بررسی می‌شود.
  • اگر کانتینر از کار بیفتد یا پاسخ ندهد، کوبرنتیز آن را دوباره راه‌اندازی می‌کند.
  • این مکانیزم اطمینان می‌دهد که پاد در کوبرنتیز همیشه در وضعیت سالم باقی بماند.
• سطح نود:
  • اگر یک نود از دسترس خارج شود، کنترلر نود، پادهای آن نود را روی نودهای سالم مجدداً زمان‌بندی (reschedule) و اجرا می‌کند.
  • این فرایند وضعیت مطلوب (Desired State) را برای کل کلاستر حفظ می‌کند.
• سطح StatefulSet:
  • پادها با حفظ هویت و اتصال به داده‌های ماندگار (Persistent Storage) مجدداً اجرا می‌شوند.
  • این امکان را می‌دهد که سرویس‌ها حتی پس از کرش کردن یا ری‌استارت پادها، به حالت پایدار خود بازگردند.

خود ترمیمی کوبرنتیز چگونه کار می‌کند؟

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

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

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

ابزارهای اصلی خود ترمیمی

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

• Liveness Probe: بررسی وضعیت زنده بودن کانتینر و راه‌اندازی مجدد خودکار در صورت از کار افتادن
• Readiness Probe: تشخیص آماده بودن پاد برای دریافت ترافیک و حذف پادهای غیرفعال از مسیرهای ترافیک
• کنترلرها (Controllers): مدیریت وضعیت فعلی پادها و نودها و اجرای اقدامات اصلاحی خودکار بر اساس وضعیت مطلوب. به عنوان مثال، کنترلرها با استفاده از ReplicaSets تعداد مشخصی از پادها را حفظ و در صورت نیاز پادهای جدید ایجاد می‌کنند.

مزایای خود ترمیمی در کوبرنتیز

قابلیت خود ترمیمی، مدیریت برنامه‌های کانتینری را قابل اعتمادتر و کارآمدتر می‌کند و مزایای زیر را به همراه دارد:

• افزایش دسترس‌پذیری و پایداری: مشکلات پادها و کانتینرها به‌طور خودکار شناسایی و رفع می‌شوند، بنابراین برنامه‌ها با کمترین downtime در دسترس باقی می‌مانند.
• کاهش نیاز به دخالت انسانی: با خود ترمیمی، تیم‌های عملیات و مهندسی، کمتر درگیر رفع مشکلات جزئی یا پیش‌بینی‌نشده می‌شوند و در نتیجه می‌توانند تمرکز خود را روی توسعه و بهینه‌سازی نرم‌افزار بگذارند.
• سرعت بالا در رفع مشکلات: اقدامات اصلاحی به‌صورت خودکار و بلادرنگ انجام می‌شوند.
• مدیریت بهتر محیط‌های گذرا (Ephemeral Environments): محیط‌های کانتینری ماهیت موقتی دارند و ممکن است کانتینرها بارها و بارها حذف یا راه‌اندازی مجدد شوند. خودترمیمی کوبرنتیز تضمین می‌کند که حتی در صورت حذف یا راه‌اندازی مجدد مکرر پادها، پایداری سرویس حفظ شود.

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

خود ترمیمی کوبرنتیز هم مانند هر فناوری دیگری، محدودیت‌هایی دارد که باید در نظر گرفته شوند:

• نیاز به تعریف وضعیت مطلوب: خود ترمیمی بر اساس وضعیت مطلوب (Desired State) عمل می‌کند که باید توسط تیم مدیریت کوبرنتیز تعریف شود.
• محدودیت در لایه اپلیکیشن: خود ترمیمی عمدتاً در سطح پاد و کانتینر عمل می‌کند و شناسایی و رفع مشکلات زیرساختی یا سخت‌افزاری (مانند خرابی سرور یا شبکه) نیاز به ابزارهای اضافی دارند.
• نیاز به نظارت مداوم: تیم‌ها باید همچنان سیستم را زیر نظر داشته باشند تا از عملکرد صحیح خود ترمیمی اطمینان حاصل شود.
• پیچیدگی پیکربندی: تنظیم دقیق Liveness Probe ،Readiness Probe و ReplicaSet می‌تواند چالش‌برانگیز باشد و خطا در آن‌ها منجر به راه‌اندازی مجدد غیرضروری یا تشخیص اشتباه شود.
• ابزارهای مکمل برای زیرساخت: برای مدیریت خطاهای نود یا سخت‌افزار، نیازمند استفاده از ابزارهای نظارتی اضافی شامل پرومتئوس و گرافانا است.

سخن پایانی

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

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

در چنین شرایطی، استفاده از یک پلتفرم مدیریت کوبرنتیز می‌تواند پیچیدگی‌های مرتبط با پیاده‌سازی و نظارت بر Self-Healing را کاهش دهد. برای مثال، پلتفرم ابری دارکوب تجربه زیرساخت مبتنی بر کوبرنتیز را به ساده‌ترین شکل ممکن فراهم می‌کند و به تیم‌ها امکان می‌دهد برنامه‌های خود را بر بستر کوبرنتیز اجرا کرده و اپلیکیشن‌های پرکاربرد را با تنظیمات دلخواه بسازند.

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

The post خود ترمیمی کوبرنتیز چیست؟ بررسی مکانیزم Self-Healing در کوبرنتیز appeared first on بلاگ هم‌روش.

کنترلر کوبرنتیز چیست؟

کنترلرها اجزای بنیادی کوبرنتیز هستند که برای مدیریت و نگهداری وضعیت منابع طراحی شده‌اند. این اجزا با بررسی مداوم وضعیت فعلی منابع و مقایسه آن با وضعیت مطلوب (Desired State)، اطمینان حاصل می‌کنند که کلاستر همیشه در شرایط پایدار باقی بماند. به عبارت دیگر، کنترلرها به صورت حلقه‌های کنترلی (Control Loops) عمل می‌کنند تا به صورت خودکار وضعیت منابع را اصلاح و هماهنگ کنند.

کنترلر کوبرنتیز چگونه کار می‌کنند؟

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

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

کنترلر کوبرنتیز چه منابعی را مدیریت می‌کند؟

در کوبرنتیز، هر کنترلر مسئول مدیریت یک نوع مشخص از منابع است. این منابع به‌صورت آبجکت‌هایی در Kubernetes API تعریف می‌شوند و کنترلرها وضعیت آن‌ها را به‌صورت مداوم بررسی و اصلاح می‌کنند.

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

نکته مهم این است که در کوبرنتیز، این منابع از طریق API تعریف و ذخیره می‌شوند و کنترلرها نیز از همین طریق وضعیت آن‌ها را مشاهده کرده (Watch) و در صورت نیاز تغییرات لازم را اعمال می‌کنند (Update). به همین دلیل، تعامل بین کنترلر کوبرنتیز و Kubernetes API نقش کلیدی در مدیریت کلاستر دارد.

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

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

در ادامه با مهم‌ترین انواع کنترلر کوبرنتیز آشنا می‌شویم.

ReplicaSet

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

Deployment

کنترلر دیپلویمنت در کوبرنتیز یکی از رایج‌ترین راهکارها برای استقرار اپلیکیشن‌ها در کوبرنتیز است. این کنترلر مدیریت ReplicaSetها را برعهده دارد و امکان به‌روزرسانی تدریجی (rolling update) و بازگشت به نسخه‌های قبلی (rollback) را فراهم می‌کند. به بیان دیگر، Deployment یک لایه بالاتر از ReplicaSet است و فرایند به‌روزرسانی و مدیریت نسخه‌های مختلف اپلیکیشن را ساده‌تر می‌کند.

StatefulSet

کنترلر StatefulSet برای مدیریت اپلیکیشن‌هایی استفاده می‌شود که به هویت پایدار و ذخیره‌سازی دائمی نیاز دارند (برای مثال سرویس‌های داده‌های احراز هویت کاربران). در این نوع از workloadها، هر پاد دارای یک شناسه منحصربه‌فرد است و این شناسه حتی در صورت جابه‌جایی یا راه‌اندازی مجدد پاد نیز حفظ می‌شود. برخلاف سایر workloadها، این پادها قابل جایگزینی ساده با یکدیگر نیستند و هر کدام هویت مستقل خود را دارند. این ویژگی باعث می‌شود StatefulSet گزینه مناسبی برای اجرای سیستم‌هایی باشد که به ذخیره‌سازی پایدار وابسته هستند.

زمانی که از دیتابیس‌های PostgreSQL ،MySQL ،MongoDB ،Cassandra و به‌صورت کلی از هر حالت Persistent Storage استفاده می‌شود، StatefulSets راهکار مناسبی است.

Job

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

CronJob

کنترلر CronJob برای اجرای Jobها در زمان‌بندی‌های مشخص استفاده می‌شود. کاربران می‌توانند با استفاده از الگوی زمان‌بندی (cron)، مشخص کنند که یک Job در چه زمان‌هایی اجرا شود و CronJob به‌صورت خودکار در همان زمان‌ها Jobهای موردنظر را ایجاد می‌کند.

DaemonSet

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

تفاوت کنترلر کوبرنتیز و اپراتور کوبرنتیز

در کوبرنتیز، کنترلرها و اپراتورها هر دو مسئول مدیریت وضعیت منابع هستند، اما از نظر دامنه و سطح پیچیدگی تفاوت دارند.

• کنترلر کوبرنتیز: وظیفه اصلی آن حفظ وضعیت مطلوب (Desired State) برای یک یا چند نوع مشخص از منابع است. این کنترلرها معمولاً برای workloadهای استاندارد و عمومی مثل پادها، ReplicaSetها، Deploymentها و Jobها استفاده می‌شوند. همان‌طور که در بخش قبل توضیح دادیم، کنترلرها از حلقه‌های کنترلی (Control Loops) استفاده می‌کنند تا وضعیت فعلی را با وضعیت مطلوب مقایسه کرده و در صورت نیاز اصلاح کنند.
• اپراتور کوبرنتیز: اپراتورها لایه‌ای بالاتر از کنترلرها هستند و برای مدیریت اپلیکیشن‌های stateful یا پیچیده طراحی شده‌اند. یک اپراتور علاوه بر حفظ وضعیت مطلوب منابع، می‌تواند منطق اختصاصی برنامه را نیز پیاده‌سازی کند؛ مثلاً مدیریت نصب، پیکربندی، به‌روزرسانی، بکاپ و بازیابی یک دیتابیس. به‌عبارتی اپراتورها کنترلرهایی هستند که با دانش برنامه (application-specific logic) ترکیب شده‌اند تا مدیریت خودکار اپلیکیشن‌های پیچیده را ممکن سازند.

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

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

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

• پایداری وضعیت منابع: کنترلرها تضمین می‌کنند که وضعیت فعلی منابع همواره با وضعیت مطلوب (Desired State) هماهنگ باشد.
• خودکارسازی وظایف ساده و تکراری: کنترلرها وظایف مدیریت تعداد پادها، راه‌اندازی مجدد آنها و نگهداری وضعیت را بدون دخالت دستی انجام می‌دهند.
• حلقه کنترل مستمر: کنترلرها به صورت مداوم منابع را پایش می‌کنند و در صورت اختلاف با وضعیت مطلوب، تغییرات لازم را اعمال می‌کنند.

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

مزایای اپراتور کوبرنتیز شامل موارد زیر است:

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

در پایان

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

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

The post آشنایی با کنترلر کوبرنتیز؛ مقایسه با اپراتور کوبرنتیز appeared first on بلاگ هم‌روش.

Kubernetes Deployment چیست؟

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

چرا به دیپلویمنت در کوبرنتیز نیاز داریم؟

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

Deployment در چند سناریوی کلیدی کاربرد دارد:

• ایجاد خودکار پادها و ReplicaSetها: با استفاده از فایل‌های YAML که پیکربندی وضعیت مطلوب را مشخص می‌کنند، کوبرنتیز می‌تواند پادها و ReplicaSetهای جدید ایجاد کند.
• تعیین وضعیت مطلوب پادها: فایل YAML به شما اجازه می‌دهد تعریف کاملی از وضعیت ایده‌آل برای پادها و ReplicaSetها داشته باشید تا کوبرنتیز بر اساس آن عمل کند.
• بازگشت سریع به نسخه پایدار (Rollback): اگر وضعیت کلاستر ناپایدار شود، Deployment تاریخچه‌ای از نسخه‌های قبلی را نگه می‌دارد تا بتوان به راحتی به آخرین وضعیت پایدار بازگشت.
• مقیاس‌گذاری پادها (Scaling): زمانی که اپلیکیشن به منابع بیشتری نیاز داشته باشد، می‌توان تعداد پادهای تعریف‌شده در Deployment را افزایش داد. Deployment با به‌روزرسانی مقدار replicas، از طریق ReplicaSet، پادهای جدید ایجاد می‌کند تا تعداد پادهای در حال اجرا، با وضعیت مطلوب تعریف‌شده هماهنگ باقی بماند. این فرایند می‌تواند به صورت دستی انجام شود یا با استفاده از ابزارهایی مانند Horizontal Pod Autoscaler (به اختصار HPA) به شکل خودکار مدیریت شود.

اجزا و کامپوننت‌های دیپلویمنت در کوبرنتیز

قبل از ایجاد یک Deployment، شناخت اجزا و کامپوننت‌های آن ضروری است. هر جزء نقش مشخصی در مدیریت پادها، ReplicaSetها و وضعیت کلاستر دارد و همکاری این اجزا تضمین می‌کند که اپلیکیشن‌ها همیشه در وضعیت مطلوب اجرا شوند.

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

• فایل YAML: فایل YAML فرمت متداول برای تعریف منابع در کوبرنتیز است و در آن می‌توان پیکربندی Deployment، تعداد پادها، مشخصات کانتینرها و سایر تنظیمات اجرای اپلیکیشن را مشخص کرد.
• پاد (Pod): کوچک‌ترین واحد اجرایی در کوبرنتیز است که شامل یک یا چند کانتینر، پیکربندی‌ها و محیط‌های اجرای اپلیکیشن می‌شود. پادها پایه‌ای‌ترین بخش اجرای Deployment هستند و مدیریت صحیح آن‌ها برای عملکرد مطلوب سیستم ضروری است. برای مطالعه بیشتر در مورد پاد می‌توانید مقاله «پاد در کوبرنتیز» را مطالعه کنید.
• ReplicaSet: گروهی از پادهای همسان است که تضمین می‌کند تعداد پادهای در حال اجرا مطابق با تعریف فایل YAML باشد. اگر یک پاد با مشکل مواجه شود، ReplicaSet مسئول ایجاد پاد جایگزین است.
• kube-scheduler: این کامپوننت بخشی از Control Plane است و تصمیم می‌گیرد که پادها و ReplicaSetها روی کدام نودهای کارگر (Worker Nodes) اجرا شوند.
• kube-controller-manager: مجموعه‌ای از کنترلرهای مختلف را اجرا می‌کند که وظیفه آن‌ها تطبیق وضعیت فعلی کلاستر با وضعیت مطلوب تعریف شده در YAML است. این کنترلرها ایجاد، حذف یا به‌روزرسانی منابعی مانند ReplicaSetها و پادها را مدیریت می‌کنند.

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

با استفاده از کوبرنتیز دیپلویمنت، می‌توانید پایداری (Stability) و نرخ در دسترس بودن (Availability) کانتینرها را افزایش دهید. برای مثال، اگر یک نود در کلاستر با مشکل مواجه شود، Deployment با کمک اجزای کنترلر و ReplicaSet به‌طور خودکار یک پاد جایگزین ایجاد می‌کند. این فرایند تماماً خودکار انجام می‌شود و نیاز به مداخله دستی را حذف می‌کند.

اگر پادها بدون استفاده از کنترلرهایی مانند Deployment ،ReplicaSet یا StatefulSet ایجاد شوند، به آن‌ها Naked Pod گفته می‌شود. در این حالت اگر پاد با مشکل مواجه شود، کوبرنتیز به صورت خودکار نمونه جایگزین ایجاد نمی‌کند.

اصلی‌ترین مزایای دیپلویمنت در کوبرنتیز عبارتند از:

• خودکارسازی دیپلوی، بروزرسانی و مقیاس‌دهی: Deployment فرایند ایجاد و مدیریت پادها و ReplicaSetها را به صورت خودکار انجام می‌دهد.
• افزایش پایداری و کاهش خطاها: مدیریت خودکار پادها باعث کاهش خطاهای انسانی و حفظ عملکرد مطلوب سیستم می‌شود.
• کاهش نرخ Downtime: با جایگزینی مرحله‌ای پادها و Rollout هوشمند، اپلیکیشن‌ها همیشه در دسترس باقی می‌مانند.
• استفاده بهینه از منابع: Kubernetes Deployment منابع کلاستر را به شکل هوشمند مدیریت می‌کند و از اضافه‌کاری یا کمبود منابع جلوگیری می‌کند.

استراتژی‌های مختلف دیپلویمنت در کوبرنتیز

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

دو استراتژی اصلی برای دیپلویمنت در کوبرنتیز وجود دارد.

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

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

علاوه بر استراتژی‌های رسمی Deployment، روش‌های پیشرفته‌ای مانند Canary ،A/B Testing و Blue/Green وجود دارند که برای کنترل دقیق انتشار نسخه جدید در محیط‌های حساس یا با حجم بالای کاربران استفاده می‌شوند. این روش‌ها معمولاً با کمک Service، Ingress یا Service Mesh پیاده‌سازی می‌شوند و فراتر از قابلیت‌های داخلی Deployment هستند.

ایجاد و پیاده‌سازی دیپلویمنت در کوبرنتیز با YAML و kubectl

در این بخش قصد داریم با شیوه ایجاد Kubernetes Deployment آشنا شویم. برای انجام اینکار از دستور kubectl در محیط CLI استفاده می‌کنیم. البته برای انجام این‌ کار نیاز است که ابتدا از نصب بودن Kubectl و minikube روی سیستم‌عامل‌تان مطمئن باشید.

۱- ایجاد دایرکتوری و فایل YAML

یک دایرکتوری جدید بسازید و فایل YAML خود را ایجاد کنید. برای مثال: nginx-deployment.yaml. این فایل شامل پیکربندی‌های اولیه مانند تعداد پادها، کانتینرها، ایمیج‌‌هاو پورت‌ها است:

apiVersion: apps/v1
kind: Deployment

metadata:
  name: nginx-deployment
  labels:
    app: nginx

spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest # name of image deployed to DockerHub
        ports:
        - containerPort: 80

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

• apiVersion: نسخه API مربوط به این منبع در کوبرنتیز را مشخص می‌کند.
• kind: برای مشخص کردن نوع فایل که در این مثال Deployment است.
• metadata: اطلاعات مربوط به دیپلویمنت، از جمله نام آن.
• «روش‌های پیشرفته‌ای مثل Canary و A/B نیز برای انتشار کنترل‌شده نسخه‌ها وجود دارد که معمولاً در محیط‌های Production بزرگ یا با ابزارهای Service Mesh استفاده می‌شوند.»: شامل مواردی که پیکربندی‌های دیپلویمنت و Replicaها را تعریف می‌کند.

۲- اعمال فایل YAML با kubectl

برای ایجاد دیپلویمنت مورد نظر، دستور زیر را اجرا کنید:

kubectl apply -f nginx-deployment.yaml

در صورت موفقیت، خروجی مشابه زیر را مشاهده خواهید کرد.

deployment.apps/nginx-deployment created

۳- بررسی وضعیت Deployment

برای مشاهده وضعیت Deployment، از دستور زیر استفاده کنید.

kubectl get deployments

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

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           6s

۴- بررسی پادهای در حال اجرا

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

kubectl get pods

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

NAME                                     READY   STATUS    RESTARTS   AGE   LABELS
nginx-deployment-9456bbbf9-fr8mc         1/1     Running   0          20s   app=nginx,pod-template-hash=75675f5897
nginx-deployment-9456bbbf9-lpn89         1/1     Running   0          20s   app=nginx,pod-template-hash=75675f5897
nginx-deployment-9456bbbf9-wq76m         1/1     Running   0          20s   app=nginx,pod-template-hash=75675f5897
nginx-deployment-9456bbbf9-xxczh         1/1     Running   0          20s   app=nginx,pod-template-hash=75675f5897

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

در پایان

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

The post آشنایی با Deployment در کوبرنتیز؛ ابزار مدیریت پادها و ReplicaSetها appeared first on بلاگ هم‌روش.

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

برنامه‌ریزی و استراتژی برای مهاجرت به کوبرنتیز

در این بخش، به نکات مهمی خواهیم پرداخت که به شما کمک می‌کند مهاجرت به کوبرنتیز را به شکلی کارآمد و کم‌ریسک انجام دهید:

ارزیابی نیازها و اهداف سازمان

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

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

تحلیل زیرساخت فعلی

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

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

تدوین استراتژی مهاجرت

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

ابتدا باید نوع استراتژی مهاجرت خود را انتخاب کنید. استراتژی‌های متداول شامل مهاجرت مرحله‌ای (Phased Migration) و مهاجرت یکپارچه (Big Bang) هستند. اگر زیرساخت شما بسیار پیچیده است یا نمی‌خواهید ریسک اختلالات زیاد را بپذیرید، استراتژی مرحله‌ای مناسب‌تر خواهد بود. در این روش، برنامه‌ها به صورت تدریجی به کوبرنتیز منتقل می‌شوند، که این امکان را می‌دهد هر مرحله را به صورت جداگانه آزمایش و ارزیابی کنید. اما اگر زیرساخت فعلی قدیمی یا ناکارآمد است و به تغییر سریع نیاز دارید، مهاجرت یکپارچه می‌تواند انتخاب مناسبی باشد.

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

انتخاب ابزارها و تکنولوژی‌ها

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

برای مدیریت چرخه حیات برنامه‌ها در کوبرنتیز، ابزارهایی مانند Helm نقش کلیدی ایفا می‌کنند. Helm به شما امکان می‌دهد تا تنظیمات پیچیده را به صورت چارت‌های ساده و قابل مدیریت انجام دهید و فرآیند استقرار را استانداردسازی کنید. برای خودکارسازی فرآیندهای توسعه و استقرار، سیستم‌های CI/CD مانند Jenkins ،GitLab CI و ArgoCD انتخاب‌های محبوبی هستند که می‌توانند به کاهش زمان استقرار کمک کنند.

در حوزه مانیتورینگ و نظارت، ابزارهایی نظیر Prometheus و Grafana برای پایش سلامت و عملکرد سیستم بسیار ضروری هستند. این ابزارها اطلاعات لحظه‌ای از وضعیت کانتینرها، نودها و سرویس‌های مختلف را فراهم می‌کنند و به شما کمک می‌کنند تا مشکلات را به سرعت شناسایی و رفع کنید. همچنین برای مدیریت لاگ‌ها، استفاده از ابزارهایی مانند ELK Stack (Elasticsearch, Logstash, Kibana) یا Loki بسیار موثر است.

آموزش و توانمندسازی تیم

آموزش و توانمندسازی تیم برای مهاجرت به کوبرنتیز امری ضروری است. ابتدا باید سطح آگاهی تیم از مفاهیم پایه‌ای مانند کانتینرها، Docker و کوبرنتیز را ارزیابی کرده و آن‌ها را با ابزارهایی مثل Helm، پرمتئوس و CI/CD آشنا کنید. برگزاری کارگاه‌های عملی و شبیه‌سازی سناریوهای واقعی به تیم کمک می‌کند تا مهارت‌های عملی را به‌طور مؤثر یاد بگیرند.

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

اجرای آزمایشی و تست مداوم

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

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

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

۴ نکته کلیدی برای مهاجرت به کوبرنتیز

۱. شروع با رویکرد مرحله‌ای

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

۲. بهره‌گیری از چند ابر (Multi-Cloud) برای انعطاف‌پذیری

استفاده از استراتژی چند ابری (Multi-Cloud) یکی از راهکارهای کلیدی در مهاجرت به کوبرنتیز است. این رویکرد به شما امکان می‌دهد تا از مزایای زیر بهره‌مند شوید:

• انعطاف‌پذیری بیشتر: با توزیع بار کاری میان چندین ارائه‌دهنده ابری، می‌توانید زیرساخت خود را به شکلی طراحی کنید که وابسته به یک پلتفرم خاص نباشید.
• کاهش ریسک وابستگی: Multi-Cloud از قفل شدن در یک ارائه‌دهنده (Vendor Lock-In) جلوگیری می‌کند و به شما آزادی عمل بیشتری برای تغییر ارائه‌دهنده یا استفاده همزمان از چند سرویس را می‌دهد.
• بهینه‌سازی هزینه‌ها: با مقایسه و استفاده از خدمات مقرون‌به‌صرفه‌تر هر ارائه‌دهنده، می‌توانید هزینه‌های زیرساخت خود را کاهش دهید.
• افزایش دسترس‌پذیری: توزیع سرویس‌ها در چندین ابر، احتمال خرابی یا وقفه در سرویس‌دهی را کاهش داده و باعث افزایش پایداری می‌شود.

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

۳. استفاده از ابزارهای خودکارسازی

ابزارهای خودکارسازی نقش حیاتی در موفقیت مهاجرت به کوبرنتیز دارند و می‌توانند فرآیندهای پیچیده را ساده و کارآمد کنند. برخی از مزایای استفاده از این ابزارها عبارتند از:

• کاهش خطاهای انسانی: ابزارهایی مانند Helm و Kustomize امکان مدیریت خودکار تنظیمات و استقرار برنامه‌ها را فراهم می‌کنند، که به کاهش اشتباهات دستی کمک می‌کند.
• خودکارسازی فرآیندهای CI/CD: با استفاده از ابزارهایی مانند Jenkins, GitLab CI/CD، یا ArgoCD می‌توانید استقرارها را سریع‌تر و با اطمینان بیشتری انجام دهید.
• مدیریت منابع: ابزارهای خودکارسازی به شما کمک می‌کنند منابع را بهینه تخصیص دهید و اطمینان حاصل کنید که کانتینرها تنها از منابع مورد نیاز استفاده می‌کنند.
• استانداردسازی محیط‌ها: این ابزارها محیط‌های توسعه، آزمایش و تولید را یکپارچه و استاندارد می‌کنند، که به تیم‌ها اجازه می‌دهد در محیط‌های مشابه کار کنند.
• تسریع فرآیند مهاجرت: خودکارسازی فعالیت‌های تکراری و وقت‌گیر، زمان و تلاش مورد نیاز برای مهاجرت را کاهش می‌دهد.

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

۴. تدوین برنامه بازگشت (Rollback Plan)

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

ویژگی‌های کلیدی یک برنامه بازگشت مؤثر شامل موارد زیر است:

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

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

در پایان

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

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

با حرکت گام‌به‌گام و آمادگی کامل، مهاجرت به کوبرنتیز می‌تواند به یکی از ارزشمندترین تصمیمات استراتژیک شما تبدیل شود.

The post مهاجرت به کوبرنتیز: نکات و بهترین رویکردها appeared first on بلاگ هم‌روش.