Lie #1 of 4
"Running", says the pod.
The container inside has crashed fourteen times. .status.phase does not care, and most dashboards read .status.phase. Rubick derives status the way kubectl does, so a crashloop looks like a crashloop. And when you open the logs they open on the container that failed, at its previous run, not the fresh copy that has not died yet.
We got this one wrong too
The Pods list has derived kubectl's status since 3.0.0. Three of Rubick's own readers still used .status.phase where that status was meant: the port-forward picker, the infrastructure builder and the peek panel's disabled-action sentence. A reviewer saw a crash-looping pod drawn as Running there.
Fixed in 713a2ad, with a corpus of pod shapes both the Rust and the TypeScript evaluator must now agree on. If you find the fourth reader, that is worth an issue.
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.