The author describes a common debugging scenario where a service is down in Kubernetes despite all technical indicators appearing healthy. This occurs because Docker verifies an application runs, while Kubernetes verifies it is operable. Docker's simplicity hides four critical questions an application must answer in a production environment. The first question is whether the application can be found by name, not just by address, as localhost in a Kubernetes pod refers only to the pod itself. Secondly, applications must be able to handle being cleanly killed by an external system by properly responding to signals like SIGTERM. The third crucial aspect is proving readiness before receiving traffic, as Kubernetes actively probes application health from the moment it starts. Finally, applications need to function without relying on local disk persistence, by using Kubernetes's mechanisms for configuration and storage. Understanding these four questions helps demystify why applications behave differently in Docker and Kubernetes. The author provides examples of how failing to address these points can lead to common production issues. This explanation is not an argument against Kubernetes, but rather an exploration of the operability debt that Docker allows teams to accumulate.