Lie #3 of 4
"No route to host", says nobody at all.
Somewhere between the Ingress and the pod, the request dies quietly. Rubick draws the whole chain on the workload's own page, and where the path stops it names the reason: a backend that does not exist, a selector matching nothing, pods running but not ready.
Four paths on host shop.example.test, no middleware. Slash resolves to three ready pods through Service api-ok. Slash legacy reaches Service api, whose target port name matches no container, so its addresses are published with no port. Slash checkout reaches Service checkout, whose only pod crashes on start and has never been Ready, so nothing is published. Slash api points at Service api-v2, which does not exist in this namespace; inspection stops there. Cluster configuration was inspected; request delivery was not tested.
Reproduce them
Three of them, one throwaway cluster.
kind or k3d is enough for these three, and no ingress controller is needed: the lies live in the objects, not in the traffic. You get a pod whose phase is Running while its only container crashes on every start, with the ConfigMap, Secret and volume its page will list, a Service whose three pods are Ready and which publishes no port next to a twin Service on the same pods that publishes fine, and one host with four paths: one healthy, one behind the crashlooping pod, one behind the mistyped port, one pointing at a Service that does not exist.
kubectl apply -f https://rubick.tech/lies.yamlkubectl -n rubick-lies get pod,svc,endpointslice,ingresskubectl delete -f https://rubick.tech/lies.yaml# kubectl reads the same objects Rubick does, so it is not fooled either. The dashboards that are fooled read .status.phase, or the selector, or the rule, and stop there.