Start with what the daemon does when the HEALTHCHECK line fires. It runs your command inside the container and writes the result where `docker inspect` can read it [3]. That is the entire contract. In Compose, one thing consumes it: a dependency edge spelled `depends_on: condition: service_healthy` [3], which orders startup and then has no further opinion. Swarm consumes it as a routing signal, taking an unhealthy service out of rotation and replacing it per the restart policy [4]. The kubelet does not consume it [5].
Of the three layers the post walks through, exactly one gates traffic on that status [1]. The syntax is what does the damage. Interval, retries, and the healthy/unhealthy vocabulary all read like an availability feature, which is why the author calls it a log shaped like a feature [16], and why he thinks the shared name is what makes people trust it further than any one layer promises [10].
On the Kubernetes side the same idea arrives split into three. Liveness failure restarts the container. Readiness failure removes the pod from the Service's endpoints and restarts nothing. A startupProbe exists so a slow boot is not killed by liveness first [6]. Each carries its own period, timeout and failure threshold in the manifest [5]. A single Docker boolean cannot express that, which is a better explanation for the missing translation than an oversight in the kubelet.
The Compose experience transfers under two conditions only: your orchestrator is Swarm, or the sole thing you needed was startup ordering on one host. On a cluster the Service selects endpoints, and with no readinessProbe the pod joins that set as soon as the process is up, whether or not it has finished connecting to the database or warming its pool [7]. The author's account of teams walking into this is specific: a tidy `curl` HEALTHCHECK in the Compose file, `depends_on` honoured locally, and an assumption that the behaviour rides along into the cluster [12].
The part of that work which survives is the endpoint. A curl against the health endpoint proves the app can answer a question [12]. The probe block is what makes something ask. It is the same shape as the Actuator problem he flagged earlier: expose `/actuator/health`, get nothing, because nobody on the orchestration side is querying it with the right semantics [13]. Meanwhile `docker inspect` goes on reporting healthy, accurately, to no one [9].
On sourcing: this is one practitioner publishing the same argument twice, in Spanish and English [2]. The probe semantics are checkable against the Kubernetes documentation he cites, which is explicit that none of the three probes defer to the image's HEALTHCHECK [14]. The diagnosis of how teams get here, and the harder claim that the Dockerfile status is dead weight rather than merely inert, are his own [9][11]. In my context the call is cheap: keep HEALTHCHECK in the Compose file where a dependency edge actually reads it, and treat a pod spec with no readinessProbe as an unfinished deployment no matter how carefully the image reports on itself [1].
