‏kubectl debug و داده‌هایی که بعد از پایان session ناپدید می‌شن

وقتی مهندس on-call با kubectl debug وارد یه pod می‌شه تا مشکلی رو بررسی کنه، اون session ممکنه تنها فرصت مستقیم برای دیدن وضعیت سیستم در اون لحظه باشه. اما به‌محض اینکه session تموم می‌شه، Kubernetes هیچ اطلاعاتی از اون رو در API نگه نمی‌داره — exit code، مدت session، یا حتی اینکه کدوم کانتینر هدف بوده.

این مشکل از یه تفاوت ساختاری توی API نشأت می‌گیره. نوع ContainerStatus برای کانتینرهای معمولی یه فیلد lastState داره که آخرین وضعیت پایان (exit code، زمان شروع و پایان، دلیل) رو حتی بعد از ریستارت نگه می‌داره. اما EphemeralContainerStatus این فیلد رو نداره — نه به‌اشتباه، بلکه چون ephemeral containerها اصلاً ریستارت نمی‌شن و مکانیزم ردیابی ریستارت براشون اعمال نمی‌شه.

عملاً چه اتفاقی می‌افته؟ تا زمانی که هیچ رویداد دیگه‌ای pod رو تغییر نده، فیلد state.terminated با exit code قابل مشاهده‌ست. اما به‌محض اینکه کانتینر دیگه‌ای ریستارت بشه، session دیباگ دومی attach بشه، یا pod reschedule بشه، اون اطلاعات جایگزین می‌شن و دیگه از طریق API قابل دسترس نیستن. درخواست logs هم همین نتیجه رو داره:

kubectl logs debug-target -c debugger-xxxxx -n default
# Error from server (NotFound): container "debugger-xxxxx" not found

این محدودیت در handoffهای تیمی به مشکل جدی تبدیل می‌شه. مثلاً مهندس اول ۱۲ دقیقه داخل کانتینر بررسی می‌کنه، با exit code 42 خارج می‌شه، و یادداشت می‌نویسه «connection pool exhaustion پیدا کردم». مهندس بعدی می‌خواد تأیید کنه — اما هیچ‌کدام از این اطلاعات دیگه از API قابل بازیابی نیستن. همه چیز به کامل بودن یادداشت‌های مهندس اول بستگی داره که در شرایط incident همیشه تضمین‌شده نیست.

در محیط‌های regulated هم این مسئله چالش compliance ایجاد می‌کنه؛ چارچوب‌هایی مثل PCI-DSS (requirement 10.3 درباره audit logging) یا SOC 2 که نیاز به ردیابی عملیات دارن، از طریق Kubernetes API به‌تنهایی نمی‌تونن این نیاز رو برآورده کنن.

برای دور زدن این محدودیت چند راه وجود داره: لاگ کردن یافته‌ها روی یه shared volume قبل از خروج، استفاده از kubectl logs -f موازی برای ضبط real-time، یا پیاده‌سازی یه watch روی pod API که لحظه Terminated شدن ephemeral container رو capture کنه. نمونه پیاده‌سازی این رویکرد در مخزن github.com/opscart/k8s-causal-memory موجوده و یه رکورد کامل مثل این رو ذخیره می‌کنه:

نویسنده پیشنهاد می‌ده که این موضوع می‌تونه دستمایه یه KEP (Kubernetes Enhancement Proposal) بشه — اضافه کردن یه فیلد lastState محدود به EphemeralContainerStatus، بدون breaking change، تا حداقل آخرین رکورد پایان session رو نگه داره. SIG Node و SIG Instrumentation کاندیداهای طبیعی برای ownership چنین پروپوزالی هستن.

نکات کلیدی:

• EphemeralContainerStatus برخلاف ContainerStatus فاقد فیلد lastState است — این یک تصمیم طراحی عمدی است، نه باگ
• exit code، مدت session، و کانتینر هدف به‌محض هر تغییر در وضعیت pod از API ناپدید می‌شن
• این محدودیت در handoff تیمی و محیط‌های نیازمند audit log مشکل‌ساز است
• راه‌حل‌های موقت شامل لاگ به shared volume، capture real-time، یا watch روی pod API می‌شن
• پیشنهاد بلندمدت: اضافه کردن lastState به EphemeralContainerStatus از طریق یک KEP