باید ابتدا مشخص شود که با ری‌استارت کانتینر در همان پاد روبه‌رو هستیم یا ایجاد مجدد پاد در کوبرنتیز اتفاق افتاده است. معیارهایی مانند 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 بلاگ هم‌روش.

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

اختلال در عملکرد کنسول هم‌روش

در بازه ذکر شده وضعیت کنسول هم‌روش به شرح زیر خواهد بود:

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

اختلال در مدیریت پلتفرم دارکوب، بازارچه و دیتابیس

در طول بازه عملیات نگهداری، قابلیت‌های زیر موقتاً غیرفعال خواهند شد:

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

داده‌های ذخیره‌شده پیش از آغاز عملیات در تمام سرویس‌های بالا حفظ خواهند شد و در دسترس خواهند بود.

عدم کارکرد سرویس‌های سنتری و هم‌گیت

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

• هم‌گیت: دسترسی به مخزن‌ها و انجام عملیات مرتبط با Git امکان‌پذیر نخواهد بود. اجرای پایپ‌لاین‌ها و GitLab Runnerهای تحت تأثیر نیز تا پایان عملیات متوقف خواهد شد. داده‌های ذخیره‌شده پیش از آغاز عملیات حفظ می‌شوند.
• سنتری: دسترسی به سرویس امکان‌پذیر نخواهد بود. داده‌های ذخیره‌شده پیش از آغاز عملیات حفظ می‌شوند؛ اما ثبت رخدادها در سنتری، در طول این بازه انجام نمی‌شود.

اختلال در عملکرد سرویس بکاپ

در این بازه، وضعیت سرویس بکاپ به شرح زیر خواهد بود:

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

عدم کارکرد کانتینر رجیستری

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

موارد مالی تحت تاثیر اختلال

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

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

وضعیت سایر سرویس‌ها

سایر سرویس‌های هم‌روش که در این اطلاعیه به آن‌ها اشاره نشده است، تحت تأثیر مستقیم این عملیات قرار نمی‌گیرند.

خلاصه وضعیت سرویس‌ها

وضعیت اجرای عملیات و پایان آن از طریق صفحه «وضعیت سرویس‌های هم‌روش» اطلاع‌رسانی خواهد شد.

پیشاپیش از همراهی و شکیبایی شما در طول این عملیات سپاسگزاریم.

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 بلاگ هم‌روش.

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

Sentry چیست؟

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

نرم‌افزار Sentry فعالیت خود را به‌عنوان ابزاری برای پایش خطا آغاز کرد، اما در سال‌های اخیر قابلیت‌هایی مانند Logs ،Tracing ،Profiling و Session Replay هم به آن اضافه شدند.

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

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

فرایند کار Sentry را می‌توان در چهار مرحله بررسی کرد:

۱. اتصال اپلیکیشن به Sentry از طریق SDK

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

۲. جمع‌آوری خطا و اطلاعات زمینه‌ای

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

۳. ارتباط خطاها و لاگ‌ها با Trace و Span

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

تفاوت Error و Span چیست؟

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

۴. تحلیل عملکرد در سطح Trace و تابع

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

قابلیت‌های اصلی Sentry چیست؟

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

پایش و تحلیل خطاها

یکی از مهم‌ترین کاربردهای Sentry، پایش خطای اپلیکیشن در محیط عملیاتی است. زمانی که یک خطای مدیریت‌نشده در محیط عملیاتی رخ می‌دهد، این پلتفرم علاوه بر ثبت پیام خطا، اطلاعاتی مانند Stack Trace، نسخه اپلیکیشن، محیط اجرا و زمان وقوع را هم ثبت می‌کند. همچنین در صورت پیکربندی پروژه، می‌توان اطلاعات زمینه‌ای و Tagهای موردنیاز را همراه هر رخداد ارسال کرد تا بررسی علت مشکل با جزئیات بیشتری انجام شود.

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

پایش عملکرد و Distributed Tracing

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

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

بررسی عملکرد در سطح کد با Profiling

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

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

مشاهده لاگ‌های ساختاریافته

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

لاگ‌های ساختاریافته را می‌توان به Trace و Span مربوط به همان درخواست متصل کرد. به این ترتیب، هنگام بررسی یک خطا یا مشکل عملکردی، می‌توان لاگ‌های مرتبط با همان درخواست را در کنار سایر شواهد مشاهده کرد و مسیر رسیدن به علت اصلی را سریع‌تر دنبال کرد. Sentry همچنین امکان مشاهده زنده لاگ‌ها (Live Tail) و ساخت Alert و Dashboard بر اساس الگوهای ثبت‌شده را فراهم می‌کند.

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

بازسازی مسیر کاربر با Session Replay

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

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

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

تحلیل نسخه‌های منتشرشده

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

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

یک سناریوی عملی: عیب‌یابی اختلال در فرایند پرداخت

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

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

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

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

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

مزایای استفاده از Sentry برای تیم‌های فنی

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

کاهش زمان رسیدن به علت مشکل

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

کاهش نیاز به بازتولید دستی تمام خطاها

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

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

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

ایجاد دید مشترک میان تیم‌ها

اطلاعات یکپارچه می‌تواند همکاری میان توسعه‌دهندگان، تیم‌های DevOps، تضمین کیفیت (QA) و پشتیبانی را ساده‌تر کند. زمانی که همه این تیم‌ها به داده‌های مشترکی مانند خطاها، Traceها، لاگ‌ها و اطلاعات عملکردی دسترسی داشته باشند، بررسی مشکلات با برداشت یکسان‌تری انجام می‌شود و هماهنگی میان اعضای تیم افزایش پیدا می‌کند.

محدودیت‌ها و ملاحظات استفاده از Sentry

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

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

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

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

جمع‌آوری داده بیشتر، همیشه به عیب‌یابی بهتر منجر نمی‌شود

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

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

هزینه استفاده با حجم داده افزایش پیدا می‌کند

در مدل‌های قیمت‌گذاری مبتنی بر مصرف، حجم داده‌های ثبت‌شده می‌تواند بر هزینه استفاده اثر بگذارد. افزایش تعداد Errorها، Spanها، Replayها یا حجم Logها ممکن است مصرف را افزایش دهد؛ به‌ویژه اگر افزایش ناگهانی خطا یا ارسال بی‌ضابطه داده رخ دهد. مشخص‌کردن داده‌های ضروری و کنترل نحوه ارسال آن‌ها می‌تواند به مدیریت مصرف کمک کند.

راه‌اندازی موثر به پیکربندی مناسب نیاز دارد

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

گستردگی قابلیت‌ها می‌تواند برای برخی تیم‌ها بیش از نیاز باشد

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

استقرار شخصی Sentry چیست؟

در مدل Self-hosted یا استقرار شخصی، سازمان، Sentry را روی زیرساخت خود مستقر می‌کند و مدیریت همه اجزای آن را بر عهده می‌گیرد. در این روش، کنترل محل نگهداری داده‌ها، منابع زیرساختی و تنظیمات استقرار در اختیار خود سازمان است و علاوه بر این، مسئولیت نصب، نگهداری، به‌روزرسانی، پایش و بهره‌برداری از سرویس هم بر عهده همان تیم خواهد بود.

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

چالش‌های راه‌اندازی و نگهداری استقرار شخصی Sentry

در بسیاری از سازمان‌ها، استفاده از مدل Self-hosted تنها به نصب Sentry محدود نمی‌شود و مدیریت زیرساخت، نگهداری سرویس و برنامه‌ریزی برای توسعه آینده بخشی از مسئولیت تیم فنی خواهد بود. در ادامه مهم‌ترین چالش‌های راه‌اندازی و نگهداری مدل Self-hosted را بررسی می‌کنیم.

معماری چندجزئی Sentry

استقرار شخصی Sentry به چند سرویس زیرساختی وابسته است که از جمله آن‌ها می‌توان به PostgreSQL ،Redis ،Kafka ،ClickHouse و Relay اشاره کرد.

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

چندجزئی‌بودن این معماری باعث می‌شود تیم داخلی علاوه بر خود Sentry، مسئولیت عملیاتی سرویس‌های وابسته را هم بر عهده داشته باشد.

نیاز به منابع زیرساختی

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

ارتقای نسخه و مدیریت سازگاری

در مدل Self-hosted، مسئولیت برنامه‌ریزی و اجرای ارتقای Sentry بر عهده سازمان است. تیم فنی باید برای بررسی تغییرات نسخه، اجرای به‌روزرسانی و اطمینان از ادامه کار سرویس‌های وابسته زمان در نظر بگیرد. بنابراین، ارتقای نسخه را باید بخشی از هزینه و مسئولیت عملیاتی Self-hosting دانست، نه فعالیتی که پس از نصب اولیه خودبه‌خود انجام می‌شود.

پشتیبان‌گیری و بازیابی

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

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

پایش خود Sentry

مدل Self-hosted پس از راه‌اندازی به پایش و رسیدگی عملیاتی نیاز دارد. تیم داخلی باید سلامت سرویس و اجزای وابسته را بررسی کند و در صورت بروز اختلال، مسئولیت تشخیص و رفع مشکل را بر عهده بگیرد. در نتیجه، سازمان علاوه بر استفاده از Sentry برای عیب‌یابی اپلیکیشن، باید زمانی را به نگهداری خود این سامانه اختصاص دهد.

هزینه پنهان نیروی فنی

هزینه استقرار مدل Self-hosted فقط به تهیه سرور و منابع زیرساختی محدود نمی‌شود. تیم‌های DevOps یا Platform باید برای نگهداری Sentry، رسیدگی به رخدادهای خود سرویس، ارتقای نسخه‌ها، پشتیبان‌گیری، ظرفیت‌سنجی و مدیریت امنیت و دسترسی‌ها زمان صرف کنند.

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

چه زمانی استقرار شخصی Sentry انتخاب مناسبی است؟

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

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

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

سرویس مدیریت‌شده Sentry چه تفاوتی با Self-hosted دارد؟

تفاوت اصلی این دو مدل در نحوه تقسیم مسئولیت‌های عملیاتی است. در مدل Self-hosted، سازمان مسئول راه‌اندازی، نگهداری و ارتقای سرویس است؛ اما در سرویس سنتری مدیریت شده، این فعالیت‌ها توسط میزبان ارائه دهنده سنتری، مدیریت می‌شوند.

در مدل Self-hosted، سازمان علاوه بر استفاده از قابلیت‌های Sentry، مدیریت زیرساخت، ارتقای نسخه، پایش سرویس و سایر فعالیت‌های عملیاتی را هم بر عهده می‌گیرد. در مقابل، در سنتری مدیریت شده (از جمله سنتری مدیریت‌شده هم‌روش)، این مسئولیت‌ها توسط ارائه‌دهنده انجام می‌شوند تا تیم فنی بتواند زمان بیشتری را صرف توسعه محصول و عیب‌یابی اپلیکیشن کند. جدول زیر تفاوت کلی استقرار Self-hosted و سرویس سنتری مدیریت‌شده هم‌روش را نشان می‌دهد.

سرویس سنتری هم‌روش چه مسئله‌ای را حل می‌کند؟

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

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

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

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

جمع‌بندی

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

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

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

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 بلاگ هم‌روش.

راکت چت چیست؟

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

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

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

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

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

قابلیت‌های اصلی راکت چت

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

ارتباطات و همکاری تیمی

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

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

مدیریت دسترسی و کنترل کاربران

راکت چت از قابلیت‌هایی مانند مدیریت دسترسی مبتنی بر نقش و اتصال به سامانه‌های هویت سازمانی مانند LDAP ،Active Directory و راهکارهای ورود یکپارچه (SSO) پشتیبانی می‌کند. بعضی از روش‌های احراز هویت و کنترل دسترسی پیشرفته ممکن است تنها در پلن‌های مشخص در دسترس باشند.

یکپارچه‌سازی و توسعه‌پذیری

این پیام‌رسان سازمانی امکان اتصال به ابزارها و سرویس‌های دیگر را فراهم می‌کند. سازمان‌ها می‌توانند از اپلیکیشن‌های آماده Marketplace استفاده کنند یا با کمک Apps Engine، برنامه‌ها، بات‌ها و گردش‌کارهای اختصاصی خود را توسعه دهند. راکت چت همچنین API و SDKهایی برای اتصال به سامانه‌های دیگر ارائه می‌دهد. قابلیت‌هایی مانند Matrix Federation و پل‌های ارتباطی Microsoft Teams و XMPP نیز در پلن‌های سازمانی این پلتفرم ارائه شده‌اند.

قابلیت‌های مبتنی بر هوش مصنوعی

راکت چت مجموعه‌ای از قابلیت‌های مبتنی بر هوش مصنوعی را با عنوان Sovereign AI ارائه می‌دهد. این قابلیت‌ها شامل استفاده از مدل‌های زبانی خودمیزبان (Self-hosted LLM)، خلاصه‌سازی گفتگوهای کانال‌ها و رشته‌ها، پرسش‌وپاسخ و جست‌وجوی هوشمند در محتوای سازمانی است. براساس صفحه پلن‌ها، Sovereign AI به‌صورت افزونه ارائه می‌شود و نباید آن را قابلیت پیش‌فرض تمام نسخه‌های Rocket Chat در نظر گرفت.

سفارشی‌سازی و شخصی‌سازی

Rocket Chat امکاناتی برای سفارشی‌سازی ظاهر و عملکرد محیط کاری ارائه می‌دهد. این امکانات شامل تغییر قالب و چیدمان، استفاده از CSS و JavaScript سفارشی، تغییر برند، تعریف Emoji، صدا و وضعیت‌های اختصاصی و توسعه اپلیکیشن‌ها و گردش‌کارهای سفارشی با Apps Engine است. دسترسی به هر یک از این امکانات باید براساس پلن مورد استفاده بررسی شود.

اپلیکیشن موبایل

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

امنیت در راکت چت

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

مدل امنیتی Zero-Trust

Rocket Chat از قابلیت‌های مدل امنیتی Zero-Trust (اعتماد صفر) پشتیبانی می‌کند. از جمله این قابلیت‌ها می‌توان به کنترل دسترسی مبتنی بر ویژگی و به‌روزرسانی پویای دسترسی براساس اطلاعات هویتی اشاره کرد. این امکانات در پلن‌های سازمانی و دفاعی ارائه می‌شوند و سطح دسترسی به آن‌ها در همه پلن‌ها یکسان نیست.

کنترل بر محل نگهداری داده‌ها

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

استقرار در محیط‌های ایزوله

Rocket Chat علاوه بر استقرار روی سرورهای داخلی، از اجرای Self-Hosted و محیط‌های کاملا ایزوله از اینترنت (Air-gapped) هم پشتیبانی می‌کند. این روش استقرار برای سازمان‌هایی که نیازمند سطح بالاتری از حفاظت داده‌ها هستند، در نسخه‌های سازمانی در دسترس است.

رمزنگاری ارتباطات

این پیام‌رسان سازمانی از رمزنگاری سرتاسری (End-to-End Encryption) برای محافظت از محرمانگی ارتباطات پشتیبانی می‌کند. همچنین مکالمات به‌صورت رمزگذاری‌شده منتقل می‌شوند تا امنیت تبادل اطلاعات افزایش پیدا کند.

مدیریت هویت و کنترل دسترسی

Rocket Chat قابلیت‌هایی مانند کنترل دسترسی مبتنی بر نقش، ورود یکپارچه، احراز هویت چندعاملی و اتصال به Active Directory و LDAP را برای مدیریت هویت و دسترسی ارائه می‌دهد. در پلن‌های پیشرفته‌تر، کنترل دسترسی مبتنی بر ویژگی و اتصال به Policy Decision Point نیز در دسترس است (Policy Decision Point یا PDP بخشی از سامانه کنترل دسترسی است که براساس ویژگی‌های کاربر و سیاست‌های امنیتی سازمان، درباره مجاز یا غیرمجاز بودن دسترسی تصمیم می‌گیرد).

حسابرسی و مدیریت داده‌ها

راکت چت برای نظارت بر فعالیت‌های کاربران، امکان ثبت لاگ‌های حسابرسی (Audit Logs) را فراهم می‌کند. همچنین مدیران می‌توانند سیاست‌های نگهداری داده (Data Retention Policies) را تعریف  کرده و از قابلیت‌هایی مانند جلوگیری از نشت اطلاعات (Data Loss Prevention) و ابزارهای پایش محتوا استفاده کنند.

پشتیبانی از الزامات انطباق

براساس صفحه پلن‌های Rocket Chat، این شرکت دارای گواهی ISO 27001 (استاندارد بین‌المللی مدیریت امنیت اطلاعات) است و ارزیابی SOC 2 Type 2 (گزارش ارزیابی اثربخشی کنترل‌های امنیتی یک شرکت در یک دوره زمانی مشخص) را تکمیل کرده است. راکت چت همچنین خود را HIPAA-supportive (پشتیبانی از الزامات قانونی آمریکا برای حفاظت از اطلاعات سلامت) معرفی می‌کند و امکان ارائه Business Associate Agreement (قراردادی که مسئولیت‌های راکت چت و سازمان را درباره نگهداری و حفاظت از اطلاعات سلامت مشخص می‌کند) را دارد. برای GDPR (مقررات حفاظت از داده‌های شخصی در اتحادیه اروپا) نیز قابلیت‌هایی در زمینه مدیریت، نگهداری و محل پردازش داده ارائه می‌دهد. سطح این امکانات و شرایط استفاده از آن‌ها به پلن و مدل استقرار بستگی دارد.

روش‌های استقرار راکت چت

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

استقرار روی زیرساخت اختصاصی (On-Premises)

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

استقرار در محیط‌های ابری

«Rocket Chat امکان استقرار در محیط‌های ابری را نیز فراهم می‌کند. گزینه‌های سازمانی آن شامل Sovereign Cloud و میزبانی اختصاصی مدیریت‌شده است. در مدل Dedicated Cloud Hosting، زیرساخت اختصاصی همراه با کمک تخصصی برای استقرار در اختیار سازمان قرار می‌گیرد.

استقرار در شبکه‌های ایزوله (Air-gapped)

راکت چت از استقرار در شبکه‌های Air-gapped و محیط‌های بدون اتصال به اینترنت پشتیبانی می‌کند. این گزینه برای محیط‌های ایزوله و شبکه‌های دارای محدودیت ارتباطی طراحی شده و در پلن‌های سازمانی مشخص، ارائه می‌شود.

استفاده از اپلیکیشن‌های آماده (One-Click)

برخی ارائه‌دهندگان زیرساخت ابری، Rocket Chat را برای راه‌اندازی سریع‌تر به‌صورت اپلیکیشن آماده نصب (One-Click App) ارائه می‌کنند. هم‌روش هم در نسخه‌های رایگان و پریمیوم این پلتفرم را به همین شکل در اختیار کاربران قرار می‌دهد.

قابلیت‌های مرتبط با استقرار در نسخه‌های سازمانی

Rocket Chat در پلن‌های سازمانی قابلیت‌هایی مانند معماری دسترسی‌پذیری بالا با Failover خودکار را ارائه می‌دهد. بازیابی از فاجعه نیز در صفحه پلن‌ها برای Workspaceهای ابری ذکر شده است. دسترسی به این قابلیت‌ها در پلن‌های مختلف یکسان نیست و باید پیش از انتخاب پلن بررسی شود.

راکت چت برای چه تیم‌ها و سازمان‌هایی مناسب است؟

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

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

مهم‌ترین مزایای راکت چت چیست؟

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

• کنترل محل میزبانی داده‌ها: امکان استقرار روی زیرساخت سازمان، مراکز داده ملی و محیط‌های Sovereign Cloud به سازمان‌ها اجازه می‌دهد محل میزبانی داده را متناسب با الزامات خود انتخاب کنند.
• انعطاف در استقرار: Rocket Chat گزینه‌هایی مانند On-premises، ابر خصوصی، میزبانی اختصاصی و در پلن‌های مشخص، استقرار Air-gapped را ارائه می‌دهد.
• توسعه‌پذیری: سازمان‌ها می‌توانند از اپلیکیشن‌های آماده، API و SDK یا Apps Engine برای اتصال Rocket Chat به ابزارها و فرایندهای داخلی استفاده کنند.
• قابلیت‌های امنیتی و مدیریتی: امکاناتی مانند کنترل دسترسی، SSO ،MFA ،LDAP، سیاست نگهداری داده و گزارش‌های حسابرسی در پلن‌های مختلف ارائه می‌شوند.
• پشتیبانی از معماری‌های سازمانی: High Availability ،Failover خودکار، Launchpad Deployment و در Workspaceهای ابری، Disaster Recovery در میان قابلیت‌های سازمانی راکت چت قرار دارند.
• سادگی استفاده و ساختار منظم: کاربران از رابط کاربری ساده و سازمان‌دهی منظم کانال‌ها به‌عنوان نقاط قوت این پلتفرم یاد کرده‌اند.

محدودیت‌ها و چالش‌های راکت چت چیست؟

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

• پیچیدگی راه‌اندازی و نگهداری: برخی کاربران معتقدند نصب، پیکربندی و سفارشی‌سازی راکت چت (مخصوصا در حالت Self-hosted)، نسبت به ابزارهای ساده‌تر به دانش فنی بیشتری نیاز دارد و نگهداری آن برای تیم‌های بدون نیروی متخصص IT یا DevOps، ممکن است زمان‌بر باشد.
• رابط کاربری نه‌چندان مدرن: تعدادی از کاربران عنوان کرده‌اند که طراحی رابط کاربری در مقایسه با برخی پیام‌رسان‌های سازمانی دیگر، کاملا مدرن یا شهودی نیست و وجود منوها و تنظیمات متعدد ممکن است یادگیری اولیه را برای کاربران جدید کمی دشوار کند.
• افت عملکرد در برخی شرایط: برخی کاربران به تاخیر (Lag) در نمایش پیام‌ها، افت عملکرد در استقرارهای بزرگ یا هنگام استفاده از یکپارچه‌سازی‌های متعدد و کندی نسبی اپلیکیشن موبایل در بارگذاری کانال‌ها یا فایل‌های حجیم اشاره کرده‌اند.
• نیاز به تنظیمات دستی در یکپارچه‌سازی‌ها: به گفته برخی کاربران، راه‌اندازی بعضی اتصال‌ها و افزونه‌ها به تنظیمات بیشتری نیاز دارد و مستندات موجود در برخی موارد کاملا شفاف نیست.
• تغییرات مدل قیمت‌گذاری: برخی کاربران گفته‌اند بخشی از قابلیت‌های پیشرفته تنها در پلن‌های غیر رایگان در دسترس است و در دوره‌هایی، تغییرات قیمت یا سیاست‌های لایسنس برایشان رضایت‌بخش نبوده است.
• محدودیت در تماس صوتی و تصویری داخلی: عده‌ای از کاربران به محدودیت‌هایی در قابلیت تماس صوتی و تصویری داخلی این پلتفرم اشاره کرده‌اند.
• قابلیت تماس صوتی در صفحه پلن‌ها به‌عنوان Add-on معرفی شده است. ویدئوکنفرانس نیز از طریق یکپارچه‌سازی با سرویس‌هایی مانند Jitsi،Google Meet ،Zoom و Pexip ارائه می‌شود.

مقایسه Rocket Chat با Slack و Mattermost

RocketChat ،Slack و Mattermost تمرکز و مدل استقرار یکسانی ندارند. Slack خود را یک پلتفرم متمرکز برای گردآوری افراد، فرایندها، داده‌ها، ابزارها و قابلیت‌های هوش مصنوعی در یک رابط گفت‌وگومحور معرفی می‌کند Mattermost نیز یک پلتفرم Open Core با تمرکز بر عملیات‌های حیاتی، DevSecOps، پاسخ به رخداد و استقرار روی زیرساخت اختصاصی یا ابر خصوصی است Rocket Chat بر ارتباطات سازمانی، حاکمیت داده و امکان استقرار در زیرساخت اختصاصی، محیط‌های ابری و شبکه‌های ایزوله تمرکز دارد.

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

پلن‌های Rocket Chat چه تفاوتی دارند؟

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

پلن‌های Citizen Engagement

پلن‌های Citizen Engagement برای سازمان‌ها و نهادهایی ارائه شده‌اند که می‌خواهند پیام‌های شهروندان یا دیگر مخاطبان بیرونی را از کانال‌هایی مانند Live Chat، ایمیل، SMS و WhatsApp دریافت و در یک محیط واحد مدیریت کنند. البته در Citizen Engagement، قابلیت همکاری تیمی نیز وجود دارد؛ بنابراین کاربران Workspace می‌توانند در کنار رسیدگی به پیام‌های بیرونی، با همکاران خود همکاری کنند یا درخواست‌ها را در همان پلتفرم به بخش‌های دیگر ارجاع دهند.

این دسته شامل دو پلن است:

• Starter
• Enterprise

پلن Starter به‌صورت رایگان و Self-managed ارائه می‌شود و حداکثر ۱۰۰ مخاطب فعال ماهانه را پوشش می‌دهد. منظور از مخاطب فعال ماهانه یا MAC، مخاطب ثبت‌نام‌نشده‌ای است که از یک کانال بیرونی مانند Live Chat ،WhatsApp، ایمیل یا SMS پیام می‌فرستد و یکی از کاربران Workspace به پیام او پاسخ می‌دهد یا آن را ارجاع می‌دهد. این پلن قابلیت‌هایی مانند اتصال کانال‌های ارتباطی، تعریف دپارتمان و واحد سازمانی، مسیریابی هوشمند مکالمات، انتقال درخواست‌ها، تعیین ساعات کاری، پاسخ‌های آماده و گزارش‌های تحلیلی را ارائه می‌دهد.

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

پلن‌های Secure CommsOS Enterprise

Rocket Chat پلن‌های Secure CommsOS Enterprise را برای سازمان‌هایی معرفی می‌کند که حاکمیت داده، انطباق و تداوم عملیات برایشان اهمیت دارد. این دسته شامل سه پلن است:

• Commercial
• Government
• Defense

پلن Commercial برای سازمان‌های تجاری ارائه شده است. از امکانات شاخص آن می‌توان به استقرار روی زیرساخت داخلی، ابر خصوصی یا شبکه‌های VPC و VPN ایزوله، میزبانی ابری اختصاصی، High Availability ،Disaster Recovery، پیام‌رسانی، تماس، اشتراک‌گذاری صفحه‌نمایش، همکاری با مجموعه‌های بیرونی، اپلیکیشن موبایل و APIهای باز اشاره کرد.

پلن Government برای سازمان‌ها و نهادهای بخش عمومی طراحی شده و بر حاکمیت داده، کنترل حوزه قضایی، حسابرسی و مدیریت دسترسی تمرکز دارد. از قابلیت‌های معرفی‌شده برای آن می‌توان به استقرار On-premises یا Sovereign Cloud، کنترل دسترسی مبتنی بر نقش، رمزنگاری سرتاسری، اتصال به SSO ،LDAP ،SAML 2.0 و Active Directory، لاگ‌های حسابرسی، سیاست‌های نگهداری داده، Matrix Federation و قابلیت‌های Sovereign AI اشاره کرد.

پلن Defense برای سازمان‌های دفاعی و اطلاعاتی و استقرار در محیط‌های ایزوله طراحی شده است. راکت چت برای این پلن قابلیت‌هایی مانند استقرار Air-gapped، استقرار در محیط‌های SCIF، کنترل دسترسی مبتنی بر ویژگی، رمزنگاری FIPS 140-3، ارتباط میان شبکه‌های دفاعی و سازگاری با بعضی الزامات امنیتی و عملیاتی وزارت دفاع آمریکا را معرفی کرده است. بعضی از قابلیت‌های درج‌شده برای این پلن هنوز برای ارائه در آینده برنامه‌ریزی‌شده‌اند و در صفحه رسمی با علامت ستاره مشخص شده‌اند.

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

در جدول زیر مقایسه‌ای بین مهم‌ترین امکانات پلن راکت چت پریمویم هم‌روش با نسخه Starter و Enterprise را مشاهده می‌کنید.

جمع‌بندی

راکت چت (Rocket Chat) یک پیام‌رسان سازمانی متن‌باز است که با تمرکز بر امنیت، حاکمیت داده و انعطاف‌پذیری در استقرار، نیازهای طیف گسترده‌ای از سازمان‌ها را پوشش می‌دهد. این ویژگی‌ها آن را برای سازمان‌هایی که کنترل کامل بر داده‌ها و زیرساخت ارتباطی برایشان اهمیت دارد، به یک گزینه مناسب و کاربردی تبدیل می‌کند.

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

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

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

جیتسی چیست؟

جیتسی (Jitsi) مجموعه‌ای از پروژه‌های متن‌باز است که برای ایجاد و استقرار راهکارهای ارتباط تصویری و ویدئوکنفرانس توسعه یافته‌اند. جیتسی میت شناخته‌شده‌ترین پروژه این مجموعه است و امکان برگزاری جلسه‌های صوتی و تصویری را از طریق مرورگر، اپلیکیشن‌های اندروید و iOS و همچنین نمایش و اجرا در وب‌سایت‌ها و برنامه‌های دیگر فراهم می‌کند. 

نکته مهمی که گاهی باعث سردرگمی می‌شود، سرویس عمومی meet.jit.si است. این سرویس، خودِ جیتسی یا جیتسی میت نیست؛ بلکه یکی از نمونه‌های اجراشده جیتسی میت به شمار می‌آید که تیم توسعه جیتسی آن را به‌صورت عمومی و رایگان در اختیار کاربران قرار داده است. سازمان‌ها نیز می‌توانند به‌جای استفاده از این سرویس عمومی، نمونه اختصاصی خودشان از جیتسی میت را روی دامنه دلخواه راه‌اندازی و مدیریت کنند.

تفاوت Jitsi و Jitsi Meet چیست؟

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

جیتسی میت برای برگزاری جلسه از مؤلفه‌هایی مانند Jitsi Videobridge ،Jicofo (یا به اختصار JVB) و Prosody استفاده می‌کند. مؤلفه‌های Jibri و Jigasi نیز در صورت نیاز به ضبط، پخش زنده یا اتصال تماس‌های SIP به این معماری اضافه می‌شوند.

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

وقتی کاربر از طریق مرورگر یا اپلیکیشن جیتسی میت وارد جلسه می‌شود، ارتباط رسانه‌ای با استفاده از فناوری WebRTC برقرار می‌شود. مولفه Prosody به‌عنوان سرور XMPP (پروتکلی برای تبادل پیام و سیگنالینگ میان اجزای جیتسی) سیگنالینگ لازم برای ارتباط میان اجزای جیتسی را انجام می‌دهد. پیام‌های سیگنالینگ برای هماهنگی جلسه استفاده می‌شوند و حامل جریان‌های صوتی و تصویری نیستند.

مولفه Jicofo نشست‌های رسانه‌ای را مدیریت می‌کند و برای هر کنفرانس یک Jitsi Videobridge در نظر می‌گیرد. Jitsi Videobridge نیز جریان‌های صوتی و تصویری را میان شرکت‌کنندگان جلسه مسیریابی می‌کند. در صورت نیاز، Jibri برای ضبط یا پخش زنده و Jigasi برای اتصال تماس‌های مبتنی بر پروتکل SIP به این معماری اضافه می‌شوند.

نقش Jitsi Videobridge و معماری SFU

Jitsi Videobridge یکی از مهم‌ترین اجزای جیتسی است. در این معماری، Videobridge به‌جای ترکیب و تولید مجدد همه جریان‌های ویدئویی، آن‌ها را به‌صورت انتخابی میان شرکت‌کنندگان مسیریابی می‌کند. در استقرار تک‌سروری نیز Videobridge معمولاً نخستین عامل محدودکننده ظرفیت است؛ زیرا ترافیک صوتی و تصویری را مدیریت می‌کند.

اجزای اصلی معماری جیتسی

در جدول زیر می‌توانید اجزای اصلی معماری جیتسی را به همراه نقش هریک از آن‌ها مشاهده کنید: 

مهم‌ترین قابلیت‌های Jitsi Meet

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

ارتباط صوتی و تصویری

مهم‌ترین قابلیت جیتسی میت، برقراری تماس‌های صوتی و تصویری است. کاربران می‌توانند از طریق بیشتر مرورگرهای رایج به جلسه ملحق شوند و حتی از اپلیکیشن‌های اختصاصی اندروید و iOS هم برای استفاده از این پلتفرم استفاده کنند. همچنین در صورت نیاز، امکان استفاده از حالت فقط صوت (Audio-only) وجود دارد.

ابزارهای همکاری در جلسه

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

ضبط، پخش زنده و اتصال تلفنی

جیتسی میت از ضبط جلسه، پخش زنده و اتصال تماس‌های تلفنی مبتنی بر SIP پشتیبانی می‌کند، اما این قابلیت‌ها در همه استقرارها به‌صورت پیش‌فرض فعال نیستند. برای ضبط یا پخش زنده (مانند YouTube Live)، باید Jibri راه‌اندازی و پیکربندی شود. همچنین اگر بخواهید کاربران از طریق خطوط تلفن مبتنی بر SIP به جلسه بپیوندند یا از داخل جلسه با آن‌ها تماس بگیرید، به Jigasi نیاز دارید.

یکپارچه‌سازی جیتسی با سایت و اپلیکیشن

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

روش‌های استفاده از جیتسی

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

استفاده از سرویس عمومی meet.jit.si

اگر هدفتان راه‌اندازی سریع یک جلسه باشد، meet.jit.si ساده‌ترین گزینه است. این سرویس توسط پروژه جیتسی میزبانی می‌شود و کاربران می‌توانند بدون راه‌اندازی سرور اختصاصی از آن استفاده کنند. البته از سال ۲۰۲۳، ایجادکننده جلسه برای شروع یک اتاق جدید باید حساب کاربری داشته باشد. هرچند سایر شرکت‌کنندگان همچنان می‌توانند بدون حساب به جلسه بپیوندند. توجه داشته باشید که در این مدل، کنترل زیرساخت و پیکربندی‌های سمت سرور در اختیار کاربر نیست.

استقرار جیتسی روی زیرساخت اختصاصی

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

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

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

امنیت و حریم خصوصی در جیتسی چگونه است؟

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

رمزنگاری تماس‌ها

در جیتسی، صدا و تصویر هنگام انتقال در شبکه با پروتکل DTLS-SRTP رمزنگاری می‌شوند تا از شنود اطلاعات در مسیر ارتباط جلوگیری شود. البته ترافیک جلسه از طریق سرور هدایت می‌شود، به همین دلیل نباید تصور کرد که همه جلسه‌ها به‌صورت پیش‌فرض از رمزنگاری سرتاسری (End-to-End Encryption یا E2EE) استفاده می‌کنند.

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

میزبانی اختصاصی چه تاثیری بر حریم خصوصی دارد؟

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

محدودیت‌های امنیتی که باید بدانید

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

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

آیا جیتسی مقیاس‌پذیر است؟

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

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

در زیرساخت‌های ابری هم می‌توان باتوجه‌به میزان بار، تعداد Videobridgeها را افزایش یا کاهش داد. البته ظرفیت واقعی ویدئوکنفرانس جیتسی فقط به تعداد این مولفه‌ها وابسته نیست و عواملی مانند توان پردازشی (CPU و RAM)، پهنای باند شبکه، تعداد جلسه‌های هم‌زمان، تعداد شرکت‌کنندگان هر جلسه، کیفیت ویدئو و تنظیمات مقیاس‌دهی بر عملکرد نهایی تاثیر می‌گذارند.

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

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

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

مزایا و محدودیت‌های جیتسی

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

مزایای جیتسی

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

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

محدودیت‌های جیتسی

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

• پیچیدگی در راه‌اندازی نسخه آماده تولید (محیط عملیاتی واقعی): استقرار حرفه‌ای (مخصوصا در مقیاس بالا)، به دانش فنی و طراحی مناسب زیرساخت نیاز دارد.
• مقیاس‌پذیری بر اساس زیرساخت: مقیاس‌پذیری، به طراحی مناسب و مدیریت زیرساخت وابسته است.
• برخی قابلیت‌ها به مؤلفه‌های جداگانه نیاز دارند: امکاناتی مانند ضبط جلسه، پخش زنده و اتصال SIP فقط در صورت راه‌اندازی و پیکربندی Jibri و Jigasi در دسترس خواهند بود.
• کیفیت جلسه به شرایط شبکه و زیرساخت بستگی دارد: منابع سرور، پهنای باند، تعداد جلسات هم‌زمان و کیفیت اتصال کاربران، همگی بر تجربه برگزاری جلسه تاثیر می‌گذارند.
• در استقرار اختصاصی، مسئولیت نگهداری بر عهده سازمان است: به‌روزرسانی، مانیتورینگ، امنیت و مدیریت زیرساخت در مدل استقرار شخصی، باید توسط تیم فنی سازمان انجام شود.
• رمزنگاری سرتاسری همه قابلیت‌ها را پوشش نمی‌دهد: قابلیت E2EE فقط برای صدا، تصویر و اشتراک‌گذاری صفحه در دسترس است و شامل داده‌هایی مانند چت و نظرسنجی نمی‌شود. همچنین فعال بودن این قابلیت به مرورگرهای پشتیبانی‌کننده هم وابسته است. فعال‌سازی E2EE در نسخه وب به استفاده از مرورگری نیاز دارد که از Insertable Streams پشتیبانی کند.

جیتسی برای چه کسب‌وکارهایی مناسب است؟

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

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

جیتسی برای چه مجموعه‌هایی انتخاب مناسبی نیست؟

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

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

جمع‌بندی؛ آیا جیتسی انتخاب مناسبی است؟

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

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

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 بلاگ هم‌روش.

آبجکت استورج چیست؟

آبجکت استورج (Object Storage) یا ذخیره‌سازی آبجکت، یک معماری ذخیره‌سازی داده است که برای ذخیره‌سازی، بایگانی، پشتیبان‌گیری و مدیریت حجم بالای داده‌های بدون‌ساختار (Unstructured Data) طراحی شده است.

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

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

• داده (Data): محتوای اصلی فایل، مانند تصویر، ویدئو، سند یا هر نوع داده دیگر.
• متادیتا (Metadata): اطلاعاتی است که درباره هر آبجکت ذخیره می‌شود و به توصیف، شناسایی و مدیریت آن کمک می‌کند. این اطلاعات می‌تواند شامل مواردی مانند نام فایل، نوع محتوا، اندازه، تاریخ ایجاد یا سایر ویژگی‌های مرتبط با داده شود.
• کلید آبجکت (Object Key): نام یا شناسه‌ای است که برای دسترسی به آبجکت استفاده می‌شود. در سرویس‌هایی مانند S3، هر آبجکت معمولاً با ترکیب نام باکت و Object Key شناسایی می‌شود.

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

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

برای درک بهتر این تفاوت، تصور کنید که در یک سیستم فایل سنتی، برای پیدا کردن یک تصویر باید مسیر مشخصی مانند Photos > Travel > Summer > photo.jpg را دنبال کنید. اما در آبجکت استورج، برنامه با استفاده از نام باکت و Object Key به آبجکت دسترسی پیدا می‌کند. ممکن است کلید آبجکت ظاهری شبیه مسیر پوشه‌ای داشته باشد، اما این ساختار یک دایرکتوری واقعی نیست و معمولاً یک قرارداد نام‌گذاری است.

معمولا دسترسی به آبجکت‌ها از طریق APIهای RESTful انجام می‌شود که بر پایه پروتکل HTTP کار می‌کنند. رایج‌ترین عملیات در این APIها عبارت‌اند از:

• PUT برای بارگذاری و ذخیره یک آبجکت
• GET برای بازیابی آبجکت
• DELETE برای حذف آبجکت

باکت در آبجکت استورج چیست؟

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

باکت برخلاف پوشه‌های فایل استورج، ساختار سلسله‌مراتبی واقعی ندارد. در سرویس‌هایی مانند Amazon S3، آبجکت‌ها درون باکت در ساختاری مسطح نگهداری می‌شوند، اما می‌توان با استفاده از پیشوندها (Prefix) در نام آبجکت‌ها، ظاهری شبیه پوشه ایجاد کرد؛ برای مثال logs/2026/app.log. این ساختار در عمل یک روش نام‌گذاری و سازمان‌دهی منطقی است، نه یک دایرکتوری واقعی

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

متادیتا در آبجکت استورج چیست؟

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

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

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

تفاوت آبجکت استورج با فایل استورج و بلاک استورج

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

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

مزایای آبجکت استورج

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

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

چالش‌های آبجکت استورج

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

• مناسب نبودن برای ویرایش‌های کوچک و مکرر: آبجکت استورج برای ذخیره و بازیابی آبجکت‌های کامل طراحی شده است. پس از ذخیره شدن یک آبجکت، معمولاً امکان ویرایش مستقیم بخشی از آن وجود ندارد و برای اعمال تغییر باید نسخه جدیدی از کل آبجکت نوشته شود. به همین دلیل، این روش برای داده‌هایی که دائماً در بخش‌های کوچک تغییر می‌کنند، گزینه ایده‌آلی نیست. در چنین سناریوهایی، بسته به نوع بار کاری، معماری‌هایی مانند بلاک استورج می‌توانند انتخاب مناسب‌تری باشند.
• هزینه خروج داده (Data Egress): برخی ارائه‌دهندگان سرویس‌های آبجکت استورج برای انتقال داده از فضای ذخیره‌سازی به خارج از سرویس هزینه دریافت می‌کنند. اگر داده‌ها به‌طور مداوم بازیابی شوند، این هزینه می‌تواند زیاد باشد.
• عملکرد پایین‌تر نسبت به Block Storage در برخی سناریوها: آبجکت استورج برای ذخیره‌سازی حجم بالای داده بهینه شده است، اما در بارهای کاری با تاخیر بسیار کم یا عملیات خواندن و نوشتن مکرر، معمولا بلاک استورج عملکرد بهتری ارائه می‌دهد.

S3 چیست؟

سرویس S3 یا Amazon S3 (مخفف Simple Storage Service) سرویس آبجکت استورج آمازون است که از سال ۲۰۰۶ ارائه شد و در حال حاضر به یکی از شناخته‌شده‌ترین نمونه‌های پیاده‌سازی Object Storage تبدیل شده است. 

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

برای مثال، عملیاتی مانند ساخت باکت، بارگذاری آبجکت، دریافت آبجکت و حذف آبجکت در بسیاری از سرویس‌های S3-compatible با همان منطق کلی S3 انجام می‌شود. این سرویس‌ها معمولاً با ابزارهایی مانند AWS CLI، ابزارهای خط فرمان مانند s3cmd و rclone و کلاینت‌هایی مانند MinIO Client قابل استفاده‌اند.

امنیت در ذخیره‌سازی آبجکت

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

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

رمزنگاری نیز نقش مهمی در حفاظت از داده‌ها دارد. بسیاری از سرویس‌های آبجکت استورج از رمزنگاری داده‌ها در زمان انتقال (Encryption in Transit) و رمزنگاری داده‌ها در حالت ذخیره‌شده (Encryption at Rest)، پشتیبانی می‌کنند. Encryption in Transit معمولاً با استفاده از پروتکل‌هایی مانند HTTPS/TLS انجام می‌شود تا داده هنگام انتقال بین کاربر، برنامه و سرویس ذخیره‌سازی محافظت شود. Encryption at Rest نیز برای محافظت از داده‌هایی است که روی زیرساخت ذخیره‌سازی نگهداری می‌شوند.

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

در برخی سرویس‌ها، قابلیت‌هایی مانند Object Lock برای پیاده‌سازی مدل WORM (مخفف Write Once, Read Many) وجود دارد. در این مدل، آبجکت پس از ذخیره شدن تا مدت مشخصی قابل حذف یا تغییر نیست. این قابلیت برای نگهداری داده‌های حساس، آرشیوهای قانونی، لاگ‌های مهم، فایل‌های پشتیبان و داده‌هایی که باید در برابر تغییر یا حذف محافظت شوند کاربرد دارد.

البته سطح پشتیبانی از این قابلیت‌ها در همه سرویس‌های آبجکت استورج یکسان نیست. بنابراین هنگام انتخاب سرویس، باید بررسی شود که امکاناتی مانند کنترل دسترسی، Encryption at Rest ،Encryption in Transit ،Versioning ،Object Lock و WORM تا چه سطحی پشتیبانی می‌شوند.

مدیریت چرخه عمر داده‌ها در آبجکت استورج

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

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

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

کاربردهای آبجکت استورج

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

• پشتیبان‌گیری و بازیابی از فاجعه (Backup & Disaster Recovery): نگهداری نسخه‌های پشتیبان و بازیابی اطلاعات در صورت خرابی سیستم یا از دست رفتن داده‌ها در فرایند بازیابی از فاجعه
• آرشیو داده (Data Archiving): ذخیره‌سازی بلندمدت داده‌هایی که به‌ندرت استفاده می‌شوند، اما نباید حذف شوند
• دریاچه داده (Data Lake): ایجاد مخزنی متمرکز برای نگهداری حجم بسیار زیادی از داده‌های ساخت‌یافته و بدون‌ساختار جهت تحلیل و پردازش
• برنامه‌های ابری (Cloud-Native Applications): ذخیره فایل‌ها و داده‌های موردنیاز برنامه‌های مبتنی بر فضای ابری، کانتینرها و معماری‌های Serverless
• هوش مصنوعی و یادگیری ماشین (AI / ML): نگهداری مجموعه‌داده‌های بزرگ برای آموزش مدل‌ها و ذخیره نتایج پردازش
• فایل‌های رسانه‌ای (Media): ذخیره تصاویر، ویدئوها، فایل‌های صوتی و سایر محتوای حجیم چندرسانه‌ای
• اینترنت اشیا (IoT): جمع‌آوری و ذخیره حجم بالای داده‌های تولیدشده توسط حسگرها و دستگاه‌های متصل برای تحلیل‌های بعدی

جمع‌بندی

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

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

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

کنسول هم‌روش

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

صفحه جدید ترمینال اپلیکیشن‌ها

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

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

قابلیت انتقال مالکیت سازمان به دیگر اعضا

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

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

بهبود زیرساخت صفحه وضعیت سرویس‌ها

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

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

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

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

پلتفرم ابری دارکوب

در پلتفرم ابری دارکوب در این فصل تغییراتی شامل موارد زیر اعمال شد.

امکان دریافت گواهی SSL از طریق DNS Challenge

در گذشته، دریافت گواهی SSL معمولاً از طریق HTTP Challenge انجام می‌شد و در نتیجه مرجع صدور گواهی باید می‌توانست از طریق HTTP به دامنه متصل شود و مالکیت دامنه را اعتبارسنجی کند. اما در دوره‌هایی که دسترسی اینترنت بین‌الملل با اختلال یا محدودیت مواجه بود، این راهکار معمولا با مشکل مواجه می‌شد. با اضافه شدن DNS Challenge، می‌توانید مالکیت دامنه را از طریق رکوردهای DNS تأیید کنید. در این راهکار، اعتبارسنجی مالکیت دامنه از طریق رکوردهای DNS انجام می‌شود و نیازی نیست مرجع صدور گواهی، از مسیر HTTP به اپلیکیشن دسترسی داشته باشد.

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

نمایش تاریخ انقضای گواهی دامنه شخصی

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

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

بازارچه ابری

در فصل بهار، بازارچه ابری با قابلیت جدیدی هم‌راه شد.

اضافه شدن تب مصرف منابع به بازارچه

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

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

سرویس سنتری

در بهار ۱۴۰۵ نسخه سرویس سنتری هم‌روش ارتقا پیدا کرد.

ارتقای سنتری به نسخه 26.2.1

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

The post گزارش تغییرات سرویس‌های هم‌روش؛ بهار ۱۴۰۵ appeared first on بلاگ هم‌روش.

گیت آپس چیست؟

گیت آپس (GitOps) یک چارچوب عملیاتی و مجموعه‌ای از روش‌ها برای مدیریت زیرساخت و استقرار برنامه‌ها است که از Git به‌عنوان تک‌منبع حقیقت (Single Source of Truth) استفاده می‌کند. در این رویکرد، وضعیت مطلوب (Desired State) زیرساخت و برنامه‌ها به‌صورت اعلامی (Declarative) در مخزن Git تعریف و نگهداری می‌شود و Git مرجع اصلی ثبت و مدیریت تغییرات است.

GitOps را می‌توان تکامل IaC (مخفف Infrastructure as Code به معنی زیرساخت به عنوان کد) و یکی از بهترین شیوه‌های DevOps دانست. این رویکرد با استفاده از Git و اتوماسیون، امکان مدیریت زیرساخت و استقرار برنامه‌ها را به‌صورت سازگار، تکرارپذیر و قابل‌ردیابی فراهم می‌کند.

اصول GitOps

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

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

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

در GitOps، تمام تغییرات زیرساخت و استقرار برنامه‌ها ابتدا در مخزن Git ثبت می‌شوند. تیم‌ها تغییرات را در قالب Pull Request (درخواست بررسی و ادغام تغییرات) یا Merge Request (معادل Pull Request در GitLab) ایجاد می‌کنند و پس از بررسی و تأیید، آن‌ها را در شاخه اصلی مخزن ادغام می‌کنند. به این ترتیب، Git به‌عنوان تک‌منبع حقیقت، وضعیت مطلوب (Desired State) زیرساخت و برنامه‌ها را نگهداری می‌کند.

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

به‌طور کلی، گردش کار گیت آپس شامل مراحل زیر است:

• تعریف زیرساخت به‌صورت کد (IaC)
• ثبت تغییرات در مخزن Git
• ایجاد Pull Request یا Merge Request
• بررسی و تأیید تغییرات
• ادغام تغییرات در شاخه اصلی
• اجرای خودکار فرایندهای CI/CD
• همگام‌سازی محیط عملیاتی با وضعیت ثبت‌شده در Git

اجزای اصلی معماری گیت آپس

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

در این معماری، مخزن Git وضعیت مطلوب سیستم را نگهداری می‌کند و GitOps Agent یا Operator به‌طور مداوم آن را با وضعیت واقعی محیط مقایسه می‌کند. هرگاه اختلافی میان این دو وجود داشته باشد، عامل گیت آپس (GitOps Agent) تغییرات لازم را اعمال می‌کند تا محیط عملیاتی دوباره با وضعیت ثبت‌شده در Git همگام شود.

گیت‌آپس در کوبرنتیز

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

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

کاربردهای رایج گیت آپس در کوبرنتیز عبارت‌اند از:

ابزارهای معروف گیت آپس

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

در میان این ابزارها، Argo CD و Flux از رایج‌ترین ابزارهای گیت آپس برای همگام‌سازی وضعیت کوبرنتیز با وضعیت ثبت‌شده در مخزن Git هستند. در محیط‌های مبتنی بر OpenShift نیز Red Hat OpenShift GitOps برای پیاده‌سازی این رویکرد ارائه شده است. علاوه بر این، ابزارهای CI مانند GitLab CI ،Jenkins ،Tekton و CircleCI معمولاً برای ساخت، تست و اعتبارسنجی تغییرات پیش از استقرار در کنار گیت آپس استفاده می‌شوند.

چه زمانی باید از گیت آپس استفاده کنیم؟

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

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

مزایای گیت آپس چیست؟

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

• افزایش سرعت استقرار: خودکارسازی فرایندهای استقرار، زمان اعمال تغییرات را کاهش می‌دهد و انتشار نسخه‌های جدید را سریع‌تر می‌کند.
• قابلیت حسابرسی و ردیابی تغییرات: تمام تغییرات در Git ثبت می‌شوند و تاریخچه کاملی از آن‌ها برای بررسی، بازبینی و ممیزی در دسترس است.
• همکاری بهتر بین تیم‌ها: توسعه‌دهندگان و تیم‌های عملیات از یک مخزن مشترک برای مدیریت زیرساخت و برنامه‌ها استفاده می‌کنند و تغییرات را از طریق گردش کار استاندارد Git بررسی می‌کنند.
• یکپارچگی و سازگاری محیط‌ها: وضعیت مطلوب سیستم در Git تعریف می‌شود و محیط عملیاتی به‌طور مداوم با آن همگام می‌شود؛ در نتیجه احتمال بروز اختلاف میان محیط‌ها کاهش می‌یابد.
• امکان بازگشت به نسخه‌های قبلی: از آنجا که تغییرات در Git نسخه‌بندی می‌شوند، در صورت نیاز می‌توان به نسخه‌های قبلی بازگشت و وضعیت سیستم را بازیابی کرد.
• استفاده از ابزارهای آشنا: گیت آپس بر پایه Git و فرایندهایی مانند Pull Request یا Merge Request بنا شده است؛ بنابراین بسیاری از توسعه‌دهندگان بدون نیاز به یادگیری ابزارها یا گردش کار کاملاً جدید می‌توانند از آن استفاده کنند.

چالش‌های گیت آپس چیست؟

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

• نیاز به تغییر فرایندها و فرهنگ کاری: در گیت آپس تمام تغییرات باید از طریق Git مدیریت شوند. این موضوع ممکن است برای تیم‌هایی که به اعمال مستقیم تغییرات در محیط عملیاتی عادت دارند، نیازمند تغییر در شیوه کار و پذیرش فرایندهای جدید باشد.
• پیچیدگی در راه‌اندازی اولیه: پیاده‌سازی گیت آپس معمولاً به راه‌اندازی مخزن Git، تعریف زیرساخت به‌صورت کد، پیکربندی ابزارهای خودکارسازی و طراحی گردش کار مناسب نیاز دارد که می‌تواند در ابتدای کار زمان‌بر و پیچیده باشد.
• نیاز به همکاری بیشتر بین تیم‌ها: گیت آپس زمانی بیشترین اثربخشی را دارد که تیم‌های توسعه، عملیات و زیرساخت از یک فرایند مشترک برای مدیریت تغییرات و استقرار برنامه‌ها استفاده کنند.
• مدیریت محیط‌ها و مخازن در مقیاس بزرگ: با افزایش تعداد برنامه‌ها، کلاسترهای کوبرنتیز یا مخازن Git، مدیریت ساختار مخازن، هماهنگی میان محیط‌ها و حفظ یکپارچگی استقرارها پیچیده‌تر می‌شود.
• مدیریت اطلاعات حساس (Secrets): از آنجا که Git به‌عنوان تک‌منبع حقیقت برای نگهداری پیکربندی‌ها استفاده می‌شود، نباید اطلاعات حساس به‌صورت مستقیم در مخزن ذخیره شوند. در عمل، معمولاً از راهکارهایی مانند Secret Managerها، Sealed Secrets یا External Secrets برای مدیریت امن این اطلاعات استفاده می‌شود.
• مدیریت وابستگی‌ها و گردش کار CI/CD: در پروژه‌های بزرگ، هماهنگ نگه داشتن وابستگی میان برنامه‌ها، پایپ‌لایت‌های CI و فرایندهای استقرار می‌تواند پیچیدگی گیت آپس را افزایش دهد و نیازمند طراحی دقیق گردش کار باشد.

تفاوت GitOps و DevOps

DevOps مجموعه‌ای از فرهنگ‌ها، اصول و روش‌ها برای افزایش همکاری میان تیم‌های توسعه و عملیات، خودکارسازی فرایندها و تسریع ارائه نرم‌افزار است. در مقابل، GitOps یک مدل عملیاتی و مجموعه‌ای از روش‌ها برای مدیریت زیرساخت و استقرار برنامه‌ها با استفاده از Git به‌عنوان تک‌منبع حقیقت محسوب می‌شود.

به عبارت دیگر، GitOps جایگزین DevOps نیست، بلکه رویکردی برای پیاده‌سازی بخشی از اصول DevOps با تکیه بر Git ،IaC و اتوماسیون است.

تفاوت GitOps و CI/CD

در بررسی تفاوت GitOps و CI/CD باید توجه داشته باشید که GitOps و CI/CD مکمل یکدیگر هستند و معمولاً در کنار هم استفاده می‌شوند، اما وظایف متفاوتی دارند. CI/CD بر خودکارسازی فرایند ساخت، تست و استقرار نرم‌افزار تمرکز دارد، در حالی که GitOps مدیریت استقرار و زیرساخت را بر پایه Git و همگام‌سازی مداوم وضعیت مطلوب با محیط عملیاتی انجام می‌دهد.

در بسیاری از پیاده‌سازی‌ها، ابزارهای CI مسئول ساخت، تست و انتشار Artifactها هستند و پس از آن، GitOps با استفاده از مخزن Git و ابزارهایی مانند Argo CD یا Flux، تغییرات را در محیط عملیاتی اعمال و وضعیت آن را با مخزن Git همگام نگه می‌دارد.

در عمل، بسیاری از سازمان‌ها از GitOps و CI/CD در کنار یکدیگر استفاده می‌کنند. ابزارهای CI مانند GitLab CI ،Jenkins یا Tekton کد را می‌سازند، تست می‌کنند و Artifactها را تولید می‌کنند. سپس ابزارهای GitOps مانند Argo CD یا Flux وضعیت ثبت‌شده در Git را با محیط عملیاتی همگام می‌کنند تا استقرارها به‌صورت خودکار، قابل‌ردیابی و سازگار انجام شوند.

جمع‌بندی

گیت آپس (GitOps) رویکردی برای مدیریت زیرساخت و استقرار برنامه‌ها است که با استفاده از Git، نسخه‌بندی تغییرات و اتوماسیون، مدیریت محیط‌های عملیاتی را ساده‌تر و قابل‌اعتمادتر می‌کند. در این مدل، تمام تغییرات از طریق مخزن Git مدیریت می‌شوند و وضعیت واقعی سیستم به‌طور مداوم با وضعیت مطلوب تعریف‌شده همگام می‌شود.

این رویکرد به‌ویژه در محیط‌های مبتنی بر کوبرنتیز و معماری‌های Cloud-Native کاربرد گسترده‌ای دارد و با افزایش شفافیت، قابلیت ردیابی و تکرارپذیری، به تیم‌ها کمک می‌کند زیرساخت و استقرار برنامه‌ها را با کنترل بیشتری مدیریت کنند.

با این حال، موفقیت گیت آپس تنها به انتخاب ابزارهایی مانند Argo CD یا Flux وابسته نیست؛ بلکه به استفاده صحیح از IaC، طراحی گردش کار مناسب و پایبندی تیم‌ها به مدیریت تغییرات از طریق Git نیز بستگی دارد.

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

HA چیست؟

High Availability (به اختصار HA) یا دسترس‌پذیری بالا، به توانایی یک سیستم، سرویس یا برنامه کاربردی برای در دسترس ماندن و ادامه ارائه خدمات با حداقل وقفه گفته می‌شود. هدف HA این است که در صورت بروز خرابی‌های برنامه‌ریزی‌شده یا غیرمنتظره، زمان ازکارافتادگی (Downtime) به حداقل برسد و سرویس با کمترین نیاز به مداخله انسانی به فعالیت خود ادامه دهد.

معماری‌های High Availability معمولا بر دو اصل کلیدی زیر استوار هستند:

• کاهش زمان ازکارافتادگی از طریق افزونگی (Redundancy)
• تداوم سرویس در صورت خرابی مؤلفه‌ها با استفاده از مکانیزم‌هایی مانند Failover

تفاوت High Availability با Uptime

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

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

معیارهای اندازه‌گیری High Availability (فاکتورهای HA)

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

Five Nines (99.999%) یا سطوح دسترس‌پذیری

یکی از رایج‌ترین معیارهای اندازه‌گیری دسترس‌پذیری بالا، درصد در دسترس بودن سرویس در یک بازه زمانی مشخص است. در این مدل، سطوحی مانند 99.9%، 99.99% و 99.999% برای بیان میزان uptime استفاده می‌شوند که به ترتیب با کاهش زمان ازکارافتادگی همراه هستند. استاندارد 99.999% که با عنوان «پنج ۹» شناخته می‌شود، یکی از اهداف متداول برای سرویس‌های حیاتی است و نشان می‌دهد سیستم در طول سال تنها چند دقیقه از دسترس خارج می‌شود.

میانگین زمان بین خرابی‌ها (MTBF)

MTBF یا Mean Time Between Failures، میانگین مدت زمانی را نشان می‌دهد که یک سیستم یا بخشی از آن، قبل از بروز خرابی به فعالیت خود ادامه می‌دهد. این معیار برای ارزیابی قابلیت اطمینان زیرساخت استفاده می‌شود. هرچه مقدار MTBF بیشتر باشد، فاصله بین خرابی‌ها افزایش پیدا می‌کند و پایداری سیستم بالاتر می‌رود.

میانگین زمان تعمیر (MTTR)

MTTR یا Mean Time to Repair، میانگین مدت زمان موردنیاز برای شناسایی، عیب‌یابی و بازگرداندن سیستم به حالت عملیاتی پس از خرابی را اندازه‌گیری می‌کند. کاهش MTTR نشان می‌دهد سازمان می‌تواند در زمان کوتاه‌تری به رخدادها پاسخ دهد و سرویس را دوباره در اختیار کاربران قرار دهد.

هدف زمان بازیابی (RTO)

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

هدف نقطه بازیابی (RPO)

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

اجزای کلیدی و مفاهیم بنیادین در معماری High Availability

پیاده‌سازی High Availability به مجموعه‌ای از فناوری‌ها و معماری‌ها متکی است که با همکاری یکدیگر، احتمال ازکارافتادگی سرویس را کاهش می‌دهند. این اجزا با حذف نقاط شکست تکی (SPOF مخفف Single Point of Failure)، تشخیص خرابی و بازیابی سریع سرویس، به افزایش دسترس‌پذیری کمک می‌کنند. در ادامه، مهم‌ترین مفاهیم معماری HA را بررسی می‌کنیم.

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

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

توزیع بار (Load Balancing): این بخش ترافیک و درخواست‌های ورودی را میان چند سرور یا نود توزیع می‌کند تا از ایجاد بار بیش از حد روی یک مؤلفه جلوگیری شود. در معماری‌های ابری، توزیع بار علاوه بر بهبود عملکرد، احتمال ایجاد نقطه شکست تکی را کاهش می‌دهد و به پایداری بیشتر سرویس‌ها کمک می‌کند.

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

تکثیر داده (Replication): تکثیر داده به فرایند کپی و همگام‌سازی داده‌ها میان چند نود یا حتی چند کلاستر گفته می‌شود. این کار باعث می‌شود در صورت از دسترس خارج شدن یک سرور یا دیتاسنتر، داده‌های موردنیاز همچنان در محل دیگری در دسترس باشند. تکثیر داده می‌تواند به‌صورت همزمان (Synchronous) یا ناهمزمان (Asynchronous) انجام شود که هریک از نظر عملکرد و میزان ریسک از دست رفتن داده ویژگی‌های متفاوتی دارند.

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

بررسی سلامت (Health Checks) و خودترمیمی (Self-healing): سیستم‌های HA به‌طور مداوم وضعیت سرورها، سرویس‌ها و برنامه‌های کاربردی را پایش می‌کنند تا خرابی‌ها در کوتاه‌ترین زمان ممکن شناسایی شوند. در بسیاری از معماری‌های مدرن، پس از تشخیص مشکل، فرایندهایی مانند اجرای Failover یا بازیابی خودکار سرویس بدون دخالت انسان انجام می‌شود که این امر به کاهش زمان ازکارافتادگی کمک می‌کند.

روش‌های پیاده‌سازی High Availability

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

حذف نقاط شکست تکی (SPOF)

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

پیاده‌سازی Failover قابل اعتماد

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

تشخیص خودکار خرابی‌ها

یک معماری HA باید بتواند خرابی‌ها را در کوتاه‌ترین زمان ممکن شناسایی کند و در صورت نیاز، به‌صورت خودکار اقداماتی مانند Failover را اجرا کند. معمولا برای این منظور از ابزارهای مانیتورینگ، Health Check و مکانیزم‌های Heartbeat (مکانیزمی برای بررسی مداوم وضعیت و در دسترس بودن نودها) استفاده می‌شود.

ایجاد راهکار مناسب برای Backup و بازیابی داده

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

استقرار کلاسترهای HA و Load Balancing

کلاسترهای High Availability امکان ادامه فعالیت سرویس را در صورت خرابی یک نود فراهم می‌کنند و Load Balancing هم ترافیک را میان نودهای مختلف توزیع می‌کند. ترکیب این دو راهکار مانع از ایجاد نقطه شکست تکی می‌شود و حتی باعث می‌شود که عملکرد سیستم در زمان افزایش بار حفظ شود.

مانیتورینگ مستمر و تست دوره‌ای

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

مقایسه High Availability با Disaster Recovery

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

تفاوت High Availability با Fault Tolerance

High Availability و Fault Tolerance هر دو با هدف افزایش پایداری و تداوم سرویس طراحی می‌شوند، اما رویکرد آن‌ها متفاوت است. High Availability با استفاده از افزونگی و Failover تلاش می‌کند زمان ازکارافتادگی را به حداقل برساند، در حالی که Fault Tolerance به‌گونه‌ای طراحی می‌شود که سرویس حتی در صورت خرابی برخی مؤلفه‌ها نیز بدون وقفه به کار خود ادامه دهد. به همین دلیل، Fault Tolerance معمولاً به منابع بیشتر و معماری پیچیده‌تری نسبت به HA نیاز دارد. در جدول مقایسه کرده‌ایم که تفاوت‌های Fault Tolerance و HA چیست.

مزایای High Availability

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

• افزایش دسترس‌پذیری سرویس‌ها: HA امکان دسترسی مداوم کاربران و کارکنان به برنامه‌ها و داده‌های حیاتی را فراهم می‌کند و وابستگی به زمان یا مکان را کاهش می‌دهد.
• حفاظت از داده‌ها: استفاده از افزونگی و تکثیر داده باعث می‌شود اطلاعات مهم حتی در زمان بروز خرابی، در دسترس باقی بمانند و ریسک از دست رفتن داده کاهش پیدا کند.
• حفظ اعتبار و اعتماد مشتریان: اختلال‌های مکرر می‌توانند بر تصویر برند تاثیر منفی بگذارند، بنابراین دسترس‌پذیری بالا با کاهش قطعی سرویس‌ها به حفظ اعتماد کاربران کمک می‌کند.
• افزایش بهره‌وری کارکنان: در دسترس بودن سامانه‌های کاری باعث می‌شود فرایندهای سازمانی بدون توقف ادامه پیدا کنند و کارکنان بتوانند به ابزارهای مورد نیاز خود دسترسی داشته باشند.
• پشتیبانی از تعهدات SLA: بسیاری از ارائه‌دهندگان خدمات ابری و سرویس‌های مدیریت‌شده برای رعایت توافق‌نامه‌های سطح سرویس (SLA)، به زیرساخت‌های HA متکی هستند.
• کاهش ریسک از دست رفتن درآمد: در بسیاری از کسب‌وکارها، ازکارافتادگی سرویس می‌تواند باعث اختلال در ارائه خدمات و ایجاد خسارت مالی شود. HA به کاهش این ریسک کمک می‌کند.
• کمک به تداوم کسب‌وکار: High Availability به سازمان کمک می‌کند حتی در زمان خرابی مؤلفه‌ها یا انجام تعمیرات برنامه‌ریزی‌شده، فعالیت سرویس‌های اصلی بدون اختلال جدی ادامه پیدا کند.

چالش‌های High Availability

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

• دستیابی به ۱۰۰٪ Uptime عملاً امکان‌پذیر نیست: هیچ زیرساختی نمی‌تواند همیشه و بدون حتی یک لحظه اختلال فعال بماند. حتی استاندارد پنج ۹ (99.999%) هم چند دقیقه ازکارافتادگی مجاز در سال دارد.
• افزایش پیچیدگی زیرساخت: با اضافه شدن افزونگی، کلاسترینگ و مکانیزم‌های Failover، تعداد اجزای سیستم بیشتر و مدیریت آن دشوارتر می‌شود. این موضوع می‌تواند عیب‌یابی و پیکربندی را هم پیچیده‌تر کند.
• هزینه‌های بالای پیاده‌سازی و نگهداری: راه‌اندازی سرورهای پشتیبان، تجهیزات شبکه اضافی، ابزارهای مانیتورینگ، لایسنس نرم‌افزارها و استفاده از چند دیتاسنتر یا زون ابری، هزینه قابل توجهی به سازمان تحمیل می‌کند.
• مقابله با خرابی‌های هم‌علت (Common-Cause Failures): گاهی یک عامل مشترک مانند قطعی برق، آتش‌سوزی یا خطای نرم‌افزاری می‌تواند چند مؤلفه را به‌طور هم‌زمان از کار بیندازد. کاهش این ریسک معمولاً به افزونگی و توزیع مناسب منابع نیاز دارد.
• تفاوت بین معیارهای فنی و تجربه واقعی کاربران: ممکن است سرویس از نظر فنی در دسترس باشد، اما به دلیل تاخیر زیاد یا افت عملکرد، کاربران آن را غیرقابل استفاده بدانند. به همین دلیل، تنها اندازه‌گیری Uptime برای ارزیابی کیفیت سرویس کافی نیست.
• نیاز به تست و پایش مداوم: پیاده‌سازی HA پایان کار نیست. مکانیزم‌های Failover، نسخه‌های پشتیبان و فرایندهای بازیابی باید به‌صورت منظم آزمایش شوند تا در زمان بروز خرابی، مطابق انتظار عمل کنند.
• مدیریت انتظارات و بودجه: دستیابی به سطوح بسیار بالای دسترس‌پذیری برای همه سازمان‌ها ضروری یا اقتصادی نیست. یکی از مهم‌ترین چالش‌ها، انتخاب سطحی از High Availability است که هم نیازهای کسب‌وکار را پوشش دهد و هم با بودجه و منابع سازمان سازگار باشد.

جمع‌بندی

High Availability (HA) مجموعه‌ای از رویکردها و فناوری‌ها برای کاهش زمان ازکارافتادگی و حفظ دسترس‌پذیری سرویس‌ها است. این هدف معمولاً با استفاده از افزونگی، Failover، توزیع بار، کلاسترینگ و تکثیر داده محقق می‌شود تا سرویس حتی در زمان بروز خرابی نیز با کمترین اختلال در دسترس باقی بماند.

در طراحی معماری‌های HA، شاخص‌هایی مانند Availability، MTBF و MTTR برای ارزیابی عملکرد زیرساخت اهمیت دارند. همچنین، HA با وجود ارتباط نزدیک با مفاهیمی مانند Disaster Recovery و Fault Tolerance، هدف و کاربرد متفاوتی دارد؛ HA بر کاهش اختلال در سرویس تمرکز دارد، در حالی که DR برای بازیابی پس از حوادث گسترده و FT برای ادامه فعالیت بدون وقفه طراحی شده است.

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

The post آشنایی با High Availability؛ بررسی معماری و مقایسه با Disaster Recovery 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 بلاگ هم‌روش.