Dunia K2: Dulang & Pesanan

Keadaan pod dan ralatnya

Anda akan belajar: maksud Pending, CrashLoopBackOff, ImagePullBackOff dan OOMKilled, dan di mana nak semak dulu.

Teks BM belum disemak oleh penutur asli.

Disemak dengan Kubernetes 1.37 pada 31 Okt 2026

Masalahnya

Anda di sini: kluster kind-dev namespace default

~/shop $ kubectl get podsNAME     READY   STATUS             RESTARTS      AGEbig      0/1     Pending            0             45shungry   0/1     CrashLoopBackOff   3 (4s ago)    45soops     0/1     CrashLoopBackOff   3 (12s ago)   45stypo     0/1     ImagePullBackOff   0             45s

Empat dulang, empat jenis masalah. Perkataannya nampak menakutkan. Setiap satu ada maksud mudah, dan tempat pertama untuk disemak.

Tengok

Ralat sebenar: . Maksudnya: aplikasi mula, crash, dan Kubernetes tunggu lebih lama sebelum cuba lagi. Tekan setiap langkah.

Ketik setiap titik pada garis masa.

Cuba

Kenapa oops crash? Kubernetes tak boleh baiki aplikasi anda. Tanya dulang itu: baca lognya.

Anda di sini: kluster kind-dev namespace default

dev-control-planeBukaPengurus

Tiada dulang di sini.

dev-workerBuka

oops·ht8mq↻3CrashLoopBackOff

dev-worker2Buka

Tiada dulang di sini.

Masa: +0s (dipercepat)

Petunjuk

kubectl logs deployment/oops tunjuk apa yang aplikasi cetak.

Tengok

Anda di sini: kluster kind-dev namespace default

~/shop $ kubectl get pod bigNAME   READY   STATUS    RESTARTS   AGEbig    0/1     Pending   0          45s~/shop $ kubectl get events --field-selector reason=FailedScheduling -o jsonpath={.items[0].message}0/3 nodes are available: 1 node(s) had untolerated taint(s), 2 Insufficient cpu. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

Ralat sebenar: dengan Insufficient cpu. Maksudnya: tiada gerai yang ada ruang untuk dulang ini. Ia minta 64 CPU.

Teka

hungry boleh guna 64Mi memori. Aplikasinya asyik makan lebih. Apa jadi?

Tengok

Anda di sini: kluster kind-dev namespace default

~/shop $ kubectl get pod hungry -o jsonpath={.status.containerStatuses[0].lastState.terminated.reason}OOMKilled~/shop $ kubectl get pod hungry -o jsonpath={.status.containerStatuses[0].lastState.terminated.exitCode}137

Ralat sebenar: , kod keluar 137. Maksudnya: ia guna memori lebih daripada hadnya. STATUS tunjuk sekejap, kemudian CrashLoopBackOff.

Cuba

Ralat sebenar: . Maksudnya: gerai tak dapat ambil image itu. Di sini tag 1.299 salah taip. Hantar nginx:1.30-alpine.

Anda di sini: kluster kind-dev namespace default

Mahu3tertulis pada pesanan shop

Nampak43 sedia

Buat Buang 1Kekurangan dibaiki: 0

dev-control-planeBukaPengurus

Tiada dulang di sini.

dev-workerBuka

shop·2g4l2
shop·v62jm

dev-worker2Buka

shop·fxdpqImagePullBackOff
shop·57nrg

Masa: +0s (dipercepat)

Petunjuk

kubectl set image deployment/shop web=nginx:1.30-alpine ganti tag yang salah.

Semak

Di mana anda semak dulu? Susun setiap ralat.

Seret kad ke dalam kotak. Atau ketik kad, kemudian ketik kotak.

Anda berjaya!

Kini anda boleh baca empat ralat pod yang biasa dan tahu di mana nak semak.

Nak tahu lebih (pilihan)

kubectl describe pod <nama> cerita semuanya: Last State, Reason, Exit Code dan Events di hujung. Larian terakhir aplikasi yang crash ada dalam kubectl logs <pod> --previous, kalau kubelet masih simpan. Dunia K5 ajar tangga nyahpepijat penuh.

Latihan sebenar (pilihan): dalam kluster yang boleh dibuang, jalankan pod dengan tag yang salah. Kemudian baca describe.