Why can a Kubernetes app fail while Kubernetes works fine?

Every pod says Running, and users still get errors. This is our shop-api, three pods behind a Service, all healthy on paper. But each pod depends on Postgres, and when that connection is refused, Kubernetes has nothing to restart.

Kubernetes runs a loop. You declare three replicas, it compares that against the pods and nodes that actually exist, and if they differ, it restarts or reschedules. It watches containers and health checks, not whether your shop is behaving correctly.

Say a shop-api container crashes. The process exits, the kubelet notices, and it restarts the container. Now say Node A dies. Heartbeats stop, so the control plane schedules a replacement pod onto Node B. In both cases, a fresh start removes the problem, and the shop keeps serving.

Restarted containers, rescheduled pods, recreated replicas. Kubernetes handles all three on its own, because a fresh container or a healthy node actually removes the cause. The problem lived in the container or the node.

Now Postgres goes down. The health check only sees that the process is fine, so every shop-api pod stays Running, while users get HTTP 500 errors. Restarting a pod just reconnects to the same dead database. Someone has to fix Postgres.

Now the Secret holds an outdated password. Kubelet starts the container, shop-api logs in to Postgres, and authentication fails, so the process exits. Kubelet restarts it with a longer wait, but it reads the same Secret every time. A human has to correct that value.

shop-api is deployed with a typo in its Postgres hostname. What will Kubernetes most likely do?

Keep restarting pods while errors continue. The typo lives in configuration, so every fresh container reads the same wrong hostname and fails again. Moving pods to another node changes nothing either, because the cause travels with the config. Kubernetes can only restart; a human has to fix the value.

Ask one question about any failure: would a fresh pod remove the cause? Crashes and dead nodes, yes. Database, config, or bug, no. Kubernetes guarantees pods are running, not that your app works. So add error-rate alerts, readiness checks, backups, and failover.

Running is not the same as working. Kubernetes keeps shop-api pods alive, but it can't tell whether customers can actually check out. So monitor what users experience, like error rates, not just pod status.