Lie #2 of 4
"All green", says the Service.
Healthy pods, matching selector, one mistyped port name. The Service publishes nothing, and it will stay green all week. Rubick reads the endpoints the cluster actually publishes, not the ones you meant to publish.
selector matches 3/3 pods
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.