آقا kubectl که فقط get pods نیست 😄

یه زمانی Debug کردن یعنی “یه بار ریستارت کن، درست میشه”…
الان تو Kubernetes؟
ریستارت می‌کنی، دوباره همون آش، همون کاسه… فقط با downtime بیشتر 😅

اول یه سری سؤال سریع (تا ذهن‌مون قفل نکنه)

• Pod چرا CrashLoopBackOff شده؟

• چرا Pending مونده و بالا نمیاد؟

• چرا سرویس 5xx می‌ده ولی Podها “Running” هستن؟

• چرا یه Node خاص همه‌چی رو خراب می‌کنه؟

• چرا “هیچی تو log نیست” ولی کار نمی‌کنه؟

خب… اینجا kubectl get pods فقط در حد تابلو ورودی ساختمونه.
اصل داستان تو سه‌تا چیزه: logs / describe / events.

1) Logs: اون‌جایی که حقیقت لو می‌ره

سریع‌ترین حالت

kubectl logs <pod>

اگه چندتا container داره

kubectl logs <pod> -c <container>

اگه Crash کرده و Restart شده (شاه‌کلید!)

kubectl logs <pod> -c <container> --previous

دنبال کردن لحظه‌ای (مثل tail)

kubectl logs -f <pod> -c <container>

نکته‌ی بازار/واقعیت: خیلی وقتا “مشکل Kubernetes نیست”، مشکل اپلیکیشنه که تو startup می‌ترکه.
--previous دقیقاً همون لحظه‌ی ترکیدن رو می‌ده.

2) Describe: اتوپسی کامل، با “آخرش چی شد؟”

اگه فقط یه چیز رو حفظ کنی، اینه:

kubectl describe pod <pod>

اینجا دنبال اینا بگرد:

• Status / Reason (مثلاً OOMKilled، ImagePullBackOff)

• Readiness/Liveness probe (خیلی وقتا خودت با probe داری می‌زنیش زمین)

• Node که روش schedule شده

• Events پایین خروجی (طلای خالص)

برای Deployment هم:

kubectl describe deploy <name>

و ReplicaSet:

kubectl describe rs <name>

متافور ساده: get می‌گه “ماشین روشنه یا نه”،
describe می‌گه “چرا چراغ چک موتور روشنه” 🚗💡

3) Events: تایم‌لاین اتفاقات (همون گزارش پلیس)

وقتی همه‌چی گیج‌کننده‌ست، Events کمک می‌کنه بفهمی آخرین حرکت چی بوده.

دیدن eventها در namespace

kubectl get events --sort-by=.metadata.creationTimestamp

فقط eventهای یه Pod

(دو روش)

روش 1: از describe پایینش

kubectl describe pod <pod>

روش 2: با field selector

kubectl get events --field-selector involvedObject.name=<pod> \ 
--sort-by=.metadata.creationTimestamp

چیزایی که زیاد می‌بینی:

• FailedScheduling (کمبود resource، taint/toleration، affinity…)

• FailedMount (PVC/secret/configmap)

• Back-off pulling image (registry/credentials/tag)

• Killing (probe fail، OOM، eviction)

4) Exec: وقتی می‌خوای “داخلش” رو ببینی

وقتی Pod بالا میاد ولی سرویس خرابه، می‌ری داخلش.

kubectl exec -it <pod> -c <container> -- sh

یا اگه bash داره:

kubectl exec -it <pod> -c <container> -- bash

چک‌های کلاسیک داخل container:

• DNS:

nslookup <service>

• شبکه/HTTP:

curl -v http://<service>:<port>/health

• env vars:

printenv | sort

واقعیت تلخ ولی مهم: خیلی از imageهای production “distroless” هستن و shell ندارن.
اونجاست که می‌رسی به مرحله‌ی بعد…

5) Ephemeral Debug Container (اگه خواستی حرفه‌ای‌تر )

وقتی container اصلی ابزار نداره (نه curl، نه sh)، یه debug container موقت می‌چسبونی به همون Pod.

نیاز به Kubernetes نسخه/کانفیگ مناسب داره (اکثراً الان اوکیه)، ولی اگه نداشتی، حداقل بدون مفهومش چیه

kubectl debug -it <pod> --image=busybox \
 --target=<container> -- sh

یا با image قوی‌تر:

kubectl debug -it <pod> --image=nicolaka/netshoot --target=<container>

چرا این خوبه؟
چون بدون دست زدن به image اصلی، ابزار دیباگ داری: curl, dig, tcpdump, …

چک‌لیست ۵ دقیقه‌ای ✅

دقیقه 1: وضعیت کلی

kubectl get pods -o wide

• کدوم Podها مشکل دارن؟

• روی کدوم Node افتادن؟

دقیقه 2: دلیل رسمی مشکل

kubectl describe pod <pod>

• Reason چیه؟ (ImagePull? OOM? Scheduling?)

• پایینش Events چی می‌گه؟

دقیقه 3: Log لحظه‌ی سقوط

kubectl logs <pod> -c <container> --previous

• exception؟

• config missing؟

• connection refused به یه dependency؟

دقیقه 4: Event تایم‌لاین

kubectl get events --sort-by=.metadata.creationTimestamp | tail -n 30

• FailedMount؟

• FailedScheduling؟

• probe failing؟

دقیقه 5: تست سریع از داخل (یا debug container)

kubectl exec -it <pod> -c <container> -- sh

یا اگر نشد:

kubectl debug -it <pod> --image=nicolaka/netshoot --target=<container>

• curl به dependencyها

• nslookup سرویس‌ها

• چک env vars / config

آخرش چی؟

kubectl یه “get pods machine” نیست.
یه جعبه‌ابزار دیباگه که اگه درست استفاده‌اش کنی، ۵ دقیقه‌ای از تاریکی می‌آی بیرون.

اگه دوست داری، تو کامنت بگو بیشتر با CrashLoop درگیری یا Pending یا Network/Ingress؟