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

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

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