In real projects, knowing Kubernetes isn't just about creating Deployments and Services.

The real skill is:

When something breaks, can you quickly identify where the problem is and fix it?

We'll build a systematic troubleshooting method instead of randomly running commands.

1. The Kubernetes Troubleshooting Mindset#

When something doesn't work, don't immediately change YAML.

First ask:

What exactly is broken?
        ↓
Which layer is broken?
        ↓
Can I reproduce it?
        ↓
What evidence do I have?
        ↓
What is the smallest fix?

Think in layers:

┌───────────────────────────────┐
│        Application            │
│   Node.js / Next.js / etc.    │
├───────────────────────────────┤
│       Container / Pod         │
├───────────────────────────────┤
│       Deployment / Job        │
├───────────────────────────────┤
│          Service              │
├───────────────────────────────┤
│        Ingress / DNS          │
├───────────────────────────────┤
│       Node / Cluster          │
├───────────────────────────────┤
│      Cloud / Infrastructure   │
└───────────────────────────────┘

Find the broken layer first.

2. The Golden Troubleshooting Workflow#

Memorize this:

1. kubectl get
       ↓
2. kubectl describe
       ↓
3. kubectl logs
       ↓
4. kubectl logs --previous
       ↓
5. Check Events
       ↓
6. Check Service
       ↓
7. Check Endpoints
       ↓
8. Check DNS / Network
       ↓
9. Check Node / Resources

The three commands you should instinctively remember are:

kubectl get
kubectl describe
kubectl logs

3. First Command: kubectl get#

Suppose your application isn't working.

Start with:

kubectl get pods

Example:

NAME                         READY   STATUS             RESTARTS
node-api-7d9f8c6b-x2k4m      1/1     Running            0
node-api-7d9f8c6b-q8m2p      0/1     CrashLoopBackOff   7

Immediately you know:

One Pod is healthy and another is repeatedly crashing.

Don't modify anything yet.

Investigate.

4. Check Everything#

Useful command:

kubectl get all

You'll see resources such as:

NAME                            READY
pod/node-api-xxx                1/1
 
NAME                    TYPE        CLUSTER-IP
service/node-api        ClusterIP   10.96.20.10
 
NAME                         READY
deployment.apps/node-api     2/2

For production, namespace matters:

kubectl get all -n production

5. Check Pod Details#

Run:

kubectl describe pod <pod-name>

Example:

kubectl describe pod node-api-xxx

The most important section is usually:

Events:

Example:

Warning  FailedScheduling
0/3 nodes are available:
2 Insufficient memory
1 node has untolerated taint

Now you have evidence.

6. Kubernetes Events#

Events are extremely useful.

Run:

kubectl get events

For a namespace:

kubectl get events -n production

Sort by time:

kubectl get events \
  --sort-by=.lastTimestamp

Events can reveal:

FailedScheduling
FailedMount
Failed
BackOff
Unhealthy
Pulling
Pulled
Created
Started
Killing

For beginners:

When something unexpected happens in Kubernetes, check Events.

7. Problem #1 — CrashLoopBackOff 💥#

One of the most common Kubernetes errors.

You see:

NAME       READY   STATUS
node-api   0/1     CrashLoopBackOff

What does it mean?

It means roughly:

The container starts, crashes, Kubernetes restarts it, it crashes again, and Kubernetes increasingly backs off between restart attempts.

It does not itself tell you the root cause.

8. Debug CrashLoopBackOff#

First:

kubectl logs <pod>

Then:

kubectl logs <pod> --previous

Then:

kubectl describe pod <pod>

Look for:

Last State:
  Terminated
  Reason:
  Exit Code:

9. Example: Node.js Crash#

Logs:

Error: Cannot connect to database
    at connectDatabase (/app/db.js:42:11)

Now you know:

Kubernetes isn't necessarily the root problem.
 
Your application is crashing because DB connection failed.

Potential causes:

Wrong DATABASE_URL
Wrong Secret
Database unavailable
DNS failure
NetworkPolicy
Credentials invalid

10. Another CrashLoopBackOff Example#

Suppose:

Error: listen EADDRINUSE: address already in use

This is an application/container problem.

Don't immediately blame Kubernetes.

Check:

Application
↓
Port configuration
↓
Container configuration

11. Problem #2 — OOMKilled 💾#

You see:

Last State:
  Terminated
  Reason: OOMKilled

OOM means:

Out Of Memory.

Suppose your Deployment has:

resources:
  limits:
    memory: "512Mi"

But the application needs more memory.

The container can be terminated when it exceeds its memory limit.

12. Debug OOMKilled#

Run:

kubectl describe pod <pod>

Look for:

Reason: OOMKilled

Then:

kubectl top pod <pod>

if metrics are available.

Check:

resources:
  requests:
    memory: "256Mi"
 
  limits:
    memory: "512Mi"

Questions to ask:

Is the memory limit too low?
Is the application leaking memory?
Did traffic increase?
Is Node.js heap growing?
Are large files/models being loaded?

13. Node.js + OOMKilled#

This is especially relevant for Node.js applications.

Suppose:

Node.js API
↓
512Mi memory limit
↓
Large JSON processing
↓
Memory usage increases
↓
Container exceeds limit
↓
OOMKilled

You may need to investigate:

• memory leak
• large request payloads
• large database result sets
• caching
• inefficient data processing
• Node.js heap configuration
• concurrency
• application architecture

Don't blindly increase memory.

First understand why memory increased.

14. Problem #3 — ImagePullBackOff#

Suppose:

kubectl get pods

shows:

node-api   0/1   ImagePullBackOff

This usually means Kubernetes cannot successfully pull the container image.

Check:

kubectl describe pod <pod>

Look at Events.

You might see:

Failed to pull image

15. Common Image Problems#

Wrong image name#

image: my-node-appp:1.0

instead of:

image: my-node-app:1.0

Wrong tag#

image: my-node-api:999

when tag doesn't exist.

Private registry#

The cluster doesn't have permission to pull it.

Registry authentication#

You may need:

imagePullSecrets

or cloud workload/node identity depending on your environment.

16. Debug ImagePullBackOff#

Run:

kubectl describe pod <pod>

Find:

Events:

Example:

Failed to pull image "myrepo/node-api:5.0"
manifest unknown

Now the issue is clear:

Image/tag doesn't exist.

17. ErrImagePull vs ImagePullBackOff#

You may see:

ErrImagePull

This means image pulling failed.

Then Kubernetes retries.

Eventually you may see:

ImagePullBackOff

Think:

Image pull fails
      ↓
ErrImagePull
      ↓
Retry
      ↓
Backoff
      ↓
ImagePullBackOff

18. Problem #4 — Pending Pod#

Example:

NAME       READY   STATUS
node-api   0/1     Pending

A Pending Pod hasn't been successfully scheduled and started.

Run:

kubectl describe pod <pod>

Look at Events.

You might see:

0/3 nodes are available:
3 Insufficient cpu

19. Common Causes of Pending#

Insufficient CPU#

Insufficient cpu

Insufficient memory#

Insufficient memory

Node affinity#

Pod requires:

workload=gpu

but no node has that label.

Taint#

Node has:

workload=gpu:NoSchedule

and Pod doesn't have the appropriate toleration.

PVC issue#

Pod requires storage that isn't available.

Topology constraints#

Pod cannot be placed according to topology rules.

20. Pending Pod Debugging#

Use:

kubectl describe pod <pod>

Then ask:

Is there enough CPU?
Is there enough memory?
Are nodeSelector/affinity rules valid?
Are there taints?
Does the Pod tolerate them?
Is PVC available?
Are topology constraints too strict?

21. Pending + Cluster Autoscaler#

Remember Chapter 16.

Suppose:

HPA
 ↓
Pods increase
 ↓
No node has enough capacity
 ↓
Pods Pending
 ↓
Cluster Autoscaler
 ↓
New node
 ↓
Scheduler
 ↓
Pod Running

If your cloud cluster has a Cluster Autoscaler configured, a Pending Pod caused by insufficient capacity may trigger node scaling.

But:

Not every Pending Pod is a Cluster Autoscaler problem.

If the reason is:

untolerated taint

adding another generic node may not solve it.

22. Problem #5 — ContainerCreating#

You may see:

STATUS
ContainerCreating

for a long time.

This means Kubernetes is still trying to prepare/start the container.

Potential causes:

Image pulling
Volume mounting
Secret/ConfigMap issues
CNI/network setup
Container runtime issues

Run:

kubectl describe pod <pod>

Again:

Events are your friend.

23. Problem #6 — CreateContainerConfigError#

Example:

CreateContainerConfigError

Often indicates a configuration dependency problem.

For example, your Deployment says:

envFrom:
  - secretRef:
      name: database-secret

But:

database-secret

doesn't exist.

Check:

kubectl get secrets

and:

kubectl describe pod <pod>

You may find:

secret "database-secret" not found

24. ConfigMap Problems#

Suppose:

envFrom:
  - configMapRef:
      name: node-api-config

but ConfigMap doesn't exist.

Check:

kubectl get configmaps

or:

kubectl get cm

Then:

kubectl describe pod <pod>

25. Problem #7 — Readiness Probe Failed#

Suppose:

NAME       READY   STATUS
node-api   0/1     Running

This is an important situation.

The container is running.

But:

READY = 0

means the Pod isn't currently ready to receive normal Service traffic.

Check:

kubectl describe pod <pod>

You may see:

Readiness probe failed:
HTTP probe failed with statuscode: 503

26. Why Readiness Matters#

Remember Chapter 14.

Container running
       ↓
Readiness probe
       ↓
Success?
   ┌───┴───┐
  Yes      No
   ↓        ↓
Traffic   No normal
allowed   Service traffic

So:

Running ≠ Ready

This is one of the most important Kubernetes concepts.

27. Common Readiness Probe Problems#

Wrong port#

Application:

3000

Probe:

port: 8080

Wrong path#

Application:

/health

Probe:

path: /healthz

Application binds only to localhost#

For container networking, your server generally needs to listen on:

0.0.0.0

rather than only:

127.0.0.1

Application starts slowly#

Use an appropriate:

startupProbe

28. Problem #8 — Service Not Working#

Suppose:

Frontend
   ↓
backend-service
   ↓
No response

First:

kubectl get svc

Then:

kubectl describe svc backend-service

Check:

Selector
Port
TargetPort
Endpoints

29. The Classic Service Problem#

Service:

selector:
  app: backend

Pod:

labels:
  app: node-api

They don't match.

Therefore:

Service
  ↓
selector app=backend
  ↓
No matching Pods
  ↓
No endpoints

Check:

kubectl get pods --show-labels

and:

kubectl describe svc backend-service

30. Check EndpointSlices#

Modern Kubernetes uses EndpointSlices.

Run:

kubectl get endpointslices

Or:

kubectl get endpointslices \
  -l kubernetes.io/service-name=backend-service

If your Service has no ready backend endpoints, investigate:

Selector
Pod labels
Pod readiness
Port configuration

31. Service Port vs TargetPort#

Suppose your Node.js app listens on:

3000

Service:

ports:
  - port: 80
    targetPort: 3000

Correct.

Traffic:

Client
  ↓
Service :80
  ↓
Pod :3000

But if you accidentally write:

targetPort: 8080

your Service may route traffic to the wrong port.

Result:

Connection refused

32. Problem #9 — DNS Failure#

Suppose backend should be reachable at:

http://backend-service

but your frontend gets:

getaddrinfo ENOTFOUND backend-service

First verify:

kubectl get svc

Then test DNS from inside the cluster.

For example:

kubectl run dns-test \
  --image=busybox:1.36 \
  -it --rm \
  --restart=Never \
  -- nslookup backend-service

Depending on the image, nslookup may not be available; you can use an image with DNS tools such as busybox or dnsutils.

33. Fully Qualified Service Name#

Suppose Service:

backend-service

exists in:

production

You can use:

backend-service.production

or:

backend-service.production.svc.cluster.local

The standard pattern is:

<service>.<namespace>.svc.cluster.local

34. Problem #10 — Ingress Not Working#

Suppose:

https://example.com

returns:

404

or:

502 Bad Gateway

Don't immediately blame the application.

Debug layer by layer:

DNS
 ↓
Load Balancer
 ↓
Ingress Controller
 ↓
Ingress
 ↓
Service
 ↓
EndpointSlices
 ↓
Pods

35. Ingress Debugging#

First:

kubectl get ingress

Then:

kubectl describe ingress <ingress-name>

Check:

Host
Path
Backend Service
Backend Port
Events

Then:

kubectl get svc

Then:

kubectl get endpointslices

Then:

kubectl get pods

36. 404 vs 502#

These can give clues, although exact behavior depends on your Ingress Controller.

404#

Potentially:

Wrong host
Wrong path
Ingress routing rule
Controller configuration

502/503#

Potentially:

Service has no healthy endpoints
Backend unreachable
Wrong targetPort
Application unavailable

Use actual controller logs and events to confirm.

37. Check Ingress Controller#

For example, if using an NGINX-based controller:

kubectl get pods -A

Find the controller Pods.

Then:

kubectl logs <ingress-controller-pod> -n <namespace>

The exact namespace and controller depend on your installation.

38. Problem #11 — PVC Pending#

Suppose:

kubectl get pvc

shows:

NAME           STATUS
postgres-pvc   Pending

Your Pod may also remain Pending.

Run:

kubectl describe pvc postgres-pvc

Look for Events.

Possible causes:

No StorageClass
No suitable provisioner
Invalid access mode
Insufficient storage
Cloud storage problem
Zone/topology constraints

39. Check StorageClass#

Run:

kubectl get storageclass

Then:

kubectl describe storageclass <name>

Remember:

PVC
 ↓
StorageClass
 ↓
Provisioner
 ↓
PV
 ↓
Actual storage

40. Problem #12 — Node NotReady#

Check:

kubectl get nodes

Example:

NAME     STATUS
node-1   Ready
node-2   NotReady

Investigate:

kubectl describe node node-2

Look for:

Conditions
Events
Taints
Allocatable resources
Capacity

41. Node Conditions#

You may see conditions such as:

Ready
MemoryPressure
DiskPressure
PIDPressure
NetworkUnavailable

For example:

DiskPressure=True

could indicate a disk-space issue.

This can affect Pods and scheduling.

42. Node Resource Investigation#

Use:

kubectl top nodes

if metrics are available.

Look at:

CPU
Memory

Then:

kubectl describe node <node>

to understand:

Capacity
Allocatable
Allocated resources
Conditions
Taints
Pods

43. Problem #13 — Deployment Not Updating#

Suppose you changed:

image: node-api:2.0

but Pods still appear to run the old version.

Check:

kubectl rollout status deployment/node-api

Then:

kubectl get deployment node-api

and:

kubectl get rs

Then:

kubectl get pods

44. Check Deployment Image#

Run:

kubectl describe deployment node-api

Look for:

Image:

You can also inspect:

kubectl get deployment node-api \
  -o=jsonpath='{.spec.template.spec.containers[*].image}'

45. Image Tag Problem#

Suppose you use:

image: node-api:latest

You build a new image with the same tag.

Kubernetes may not necessarily pull the new image in the way you expect, depending on image pull policy and node cache.

For production deployments, immutable versioned tags are much safer:

node-api:1.0.0
node-api:1.0.1
node-api:1.0.2

Even better, deployments can use immutable image digests.

46. Problem #14 — Rollout Stuck#

Check:

kubectl rollout status deployment/node-api

Maybe:

Waiting for deployment "node-api" rollout to finish...

Check:

kubectl get pods

Maybe new Pods are:

0/1 Running

Then:

kubectl describe pod <new-pod>

Maybe readiness probe is failing.

Or:

ImagePullBackOff

Or:

CrashLoopBackOff

This demonstrates an important point:

A Deployment rollout problem often has a lower-level Pod problem underneath it.

47. Rollout History#

Check:

kubectl rollout history deployment/node-api

If a new version is broken:

kubectl rollout undo deployment/node-api

Then:

kubectl rollout status deployment/node-api

We'll study production rollouts and rollback strategies in Chapter 24.

48. Debugging Network Connectivity#

Suppose:

Frontend Pod
      ↓
Backend Service
      ↓
Timeout

Don't immediately modify NetworkPolicy.

Test from inside the cluster.

Run a temporary debugging Pod:

kubectl run network-debug \
  --image=curlimages/curl \
  -it --rm \
  --restart=Never \
  -- sh

Then:

curl http://backend-service

Test a specific port:

curl http://backend-service:80

49. DNS + Connectivity Test#

Inside the debugging container:

nslookup backend-service

Then:

curl http://backend-service

This separates:

DNS problem

from:

Application/network connectivity problem

50. NetworkPolicy Troubleshooting#

Remember Chapter 20.

Suppose:

Frontend → Backend

used to work.

Then you add:

default-deny

and suddenly it fails.

Check:

kubectl get networkpolicy -A

Then:

kubectl describe networkpolicy <policy>

Ask:

Is frontend allowed to talk to backend?
Is backend port allowed?
Is DNS allowed?
Is egress allowed?
Are namespace selectors correct?

NetworkPolicy debugging requires understanding the actual source and destination Pods.

51. Debugging DNS Itself#

If service DNS doesn't work:

kubectl get pods -n kube-system

Look for your cluster DNS components, commonly CoreDNS.

Then inspect:

kubectl logs -n kube-system <coredns-pod>

You can also inspect:

kubectl get svc -n kube-system

Look for the cluster DNS Service.

52. Problem #15 — Secret Is Wrong#

Suppose your app says:

Authentication failed

But the Pod is Running.

Potentially:

Secret value incorrect

Check that the Secret exists:

kubectl get secret

Don't casually print sensitive values into terminal history or logs.

You can inspect metadata:

kubectl describe secret database-secret

Remember:

Kubernetes Secrets are not automatically equivalent to a full external secret-management system.

53. Debugging Environment Variables#

You can inspect environment variables inside a container when appropriate:

kubectl exec -it <pod> -- env

But be careful:

This can expose secrets in your terminal output.

For production secrets, avoid indiscriminate dumping.

Instead, verify configuration through safer targeted checks.

54. kubectl exec#

Sometimes logs aren't enough.

You can enter a running container:

kubectl exec -it <pod> -- /bin/sh

Then:

ls

or:

env

or:

cat /etc/resolv.conf

or:

wget ...

depending on available tools.

55. Important: Minimal Images#

Your production image may be:

node:alpine

or an even smaller hardened image.

It might not contain:

curl
ping
nslookup
bash
netstat

So don't assume every debugging command exists inside your application container.

That's why temporary debug Pods are useful.

56. Ephemeral Debugging Containers#

Modern Kubernetes environments may support ephemeral containers for troubleshooting running Pods.

Conceptually:

Application Pod
 ├── Node.js container
 └── Temporary debug container

This lets you troubleshoot without rebuilding the application image just to add debugging tools.

Availability and permissions depend on your cluster/version/setup.

57. A Complete Troubleshooting Decision Tree#

This is worth saving.

                 Application broken
                        │
                        ↓
                 kubectl get pods
                        │
             ┌──────────┼──────────┐
             ↓          ↓          ↓
           Pending    Running    Failed/Crash
             │          │          │
             ↓          ↓          ↓
         describe    logs       logs
             │          │          │
             ↓          ↓       --previous
       Scheduling?    Ready?        │
       Resources?      │           ↓
       PVC?            │       Exit code?
       Taints?         │       OOMKilled?
                       │       App error?
                       ↓
                  Service check
                       │
                       ↓
                EndpointSlices
                       │
                       ↓
                  DNS / curl
                       │
                       ↓
                 NetworkPolicy
                       │
                       ↓
                Ingress / DNS
                       │
                       ↓
                  Node / Cloud

58. Troubleshooting by Status#

Memorize this table:

59. A Real Production Example#

Imagine your company deploys:

Next.js
   ↓
Ingress
   ↓
Node.js API
   ↓
PostgreSQL

Users report:

"The website is loading, but checkout fails."

You investigate.

Step 1#

kubectl get pods -n production

Everything is:

Running

So don't conclude everything is healthy.

Step 2#

Check API logs:

kubectl logs -n production <api-pod>

You find:

Database connection timeout

Step 3#

Check PostgreSQL Pod:

kubectl get pods -n production

Postgres is:

Running

Step 4#

Check PostgreSQL Service:

kubectl get svc -n production

Exists.

Step 5#

Check endpoints:

kubectl get endpointslices -n production

Postgres has no ready endpoints.

Step 6#

Inspect Postgres:

kubectl describe pod postgres-xxx -n production

You discover:

Readiness probe failed

Step 7#

Inspect logs:

kubectl logs postgres-xxx -n production

You discover:

Database storage is full

Now you have a chain:

Disk full
   ↓
PostgreSQL unhealthy
   ↓
Readiness fails
   ↓
No ready endpoints
   ↓
Node.js cannot connect
   ↓
Checkout fails

This is real troubleshooting.

You didn't randomly change the API.

You followed evidence.

60. The Most Important Rule#

When troubleshooting Kubernetes:

Don't jump directly to the solution. Follow the evidence.

Bad troubleshooting:

Pod broken
↓
Increase CPU
↓
Restart
↓
Delete Pod
↓
Hope it works

Good troubleshooting:

Symptom
 ↓
Status
 ↓
Events
 ↓
Logs
 ↓
Dependencies
 ↓
Metrics
 ↓
Root cause
 ↓
Fix
 ↓
Verify

61. Verification After Fix#

Suppose you fix the problem.

Don't stop at:

"It seems fixed."

Verify.

kubectl get pods

Then:

kubectl rollout status deployment/node-api

Then:

kubectl get svc

Then test:

curl ...

Then inspect logs:

kubectl logs <pod>

And if monitoring exists:

Error rate ↓
Latency ↓
Restarts stable
Pods Ready

A fix isn't complete until you verify the system recovered.

62. Interview Questions 🎯#

Q1. What do you do when a Pod is in CrashLoopBackOff?#

kubectl logs <pod>
kubectl logs <pod> --previous
kubectl describe pod <pod>

Then inspect application errors, exit code, probes, resource limits, and Events.

Q2. How do you troubleshoot Pending Pods?#

kubectl describe pod <pod>

Look for:

• insufficient CPU/memory
• taints
• affinity
• nodeSelector
• topology constraints
• PVC issues

Q3. How do you troubleshoot ImagePullBackOff?#

kubectl describe pod <pod>

Check:

• image name
• tag
• registry
• authentication
• imagePullSecrets
• registry/network access

Q4. What does OOMKilled mean?#

The container was terminated because it exceeded its memory limit or otherwise encountered an out-of-memory condition.

Investigate actual usage, memory limits, application behavior, and node conditions.

Q5. How do you troubleshoot a Service?#

Check:

kubectl get svc
kubectl describe svc <service>
kubectl get endpointslices
kubectl get pods --show-labels

Verify:

selector
Pod labels
port
targetPort
readiness

Q6. Why can a Pod be Running but not receive traffic?#

Because:

Running ≠ Ready

The readiness probe may be failing.

Q7. How do you troubleshoot Ingress?#

Check:

DNS
Ingress
Ingress Controller
Service
EndpointSlices
Pods

Commands:

kubectl get ingress
kubectl describe ingress <ingress>
kubectl get svc
kubectl get endpointslices
kubectl logs <ingress-controller>

Q8. How do you troubleshoot PVC Pending?#

kubectl describe pvc <pvc>
kubectl get storageclass

Check provisioning, StorageClass, access modes, topology and storage backend.

Q9. How do you troubleshoot a Node NotReady?#

kubectl describe node <node>

Check:

Conditions
Events
DiskPressure
MemoryPressure
PIDPressure
kubelet
networking

Q10. What are the first three Kubernetes debugging commands?#

A very good answer:

kubectl get
kubectl describe
kubectl logs

Then use Events, metrics, Services, EndpointSlices and network debugging depending on the symptom.

63. Your Kubernetes Troubleshooting Cheat Sheet 🧠#

Pod problem#

kubectl get pods
kubectl describe pod <pod>
kubectl logs <pod>
kubectl logs <pod> --previous

Events#

kubectl get events --sort-by=.lastTimestamp

Deployment#

kubectl get deployment
kubectl describe deployment <deployment>
kubectl rollout status deployment/<deployment>
kubectl rollout history deployment/<deployment>

Service#

kubectl get svc
kubectl describe svc <service>
kubectl get endpointslices

Resources#

kubectl top pods
kubectl top nodes

Nodes#

kubectl get nodes
kubectl describe node <node>

Storage#

kubectl get pvc
kubectl describe pvc <pvc>
kubectl get storageclass

Network#

kubectl run network-debug \
  --image=curlimages/curl \
  -it --rm \
  --restart=Never \
  -- sh

Then:

curl http://service-name

🔥 Final Mental Model#

When your Kubernetes application breaks:

                     SOMETHING BROKE
                           │
                           ↓
                    kubectl get
                           │
                           ↓
                    What's wrong?
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       Pod issue       Service issue      Node issue
          │                │                │
          ↓                ↓                ↓
      describe           describe         describe
          │                │                │
          ↓                ↓                ↓
        logs           endpoints        resources
          │                │                │
          ↓                ↓                ↓
      --previous        DNS/curl        kubelet/events
          │                │                │
          └────────────────┼────────────────┘
                           ↓
                       Metrics
                           ↓
                        Root Cause
                           ↓
                          Fix
                           ↓
                        Verify

If you become comfortable with this flow, you'll be able to troubleshoot a surprisingly large percentage of everyday Kubernetes incidents.

🎯 Chapter 23 Key Takeaways#

Remember these 10 rules:

1. kubectl get → understand the current state.
2. kubectl describe → inspect details and Events.
3. kubectl logs → inspect application output.
4. --previous → inspect the previous crashed container.
5. CrashLoopBackOff → find why the application is crashing.
6. Pending → investigate scheduling/resources/storage/constraints.
7. ImagePullBackOff → investigate image/registry/authentication.
8. Running ≠ Ready → check readiness probes.
9. Service problems → check selectors + EndpointSlices + ports.
10. Always verify the fix instead of assuming it worked.

Next → Chapter 24: Rolling Updates & Rollbacks 🚀#

We'll now move from troubleshooting into production deployment strategies.

You'll learn:

• Rolling Updates
• ReplicaSets during deployments
• maxSurge
• maxUnavailable
• Zero-downtime deployments
• Rollout history
• Rollbacks
• Blue-Green deployments
• Canary deployments
• Deployment strategies
• Database migration problems during deployments
• Version compatibility
• Production deployment workflow
• How Kubernetes safely moves from v1 → v2 without taking your application offline.