Some of your users are hitting your test app. Here's the path a request takes. A user asks for slash orders. That request goes to the web Service, which is the stable entry point in front of your app. The Service forwards it to a Pod, a running copy of the app. This time, that Pod is the test one, so test data comes back.

Here's the cause. A label is a name tag on a Pod. A selector is the Service's search filter: it looks for Pods wearing a matching tag. Our Service, web, searches for app: web. The three production Pods wear that tag, and so does the new test Pod, because it was copied.

The web Service doesn't know which Pods you meant. It just checks labels. Three production Pods carry app: web, and so does the test Pod, so all four become endpoints. A Service routes to every Pod whose labels match its selector. That means roughly one request in four may reach the test Pod.

The fix is to change the test Pod's label, not the Service. Production Pods keep app: web. The test Pod becomes app: web-test. The Service selector still says app: web, so it no longer matches the test Pod. Each app needs labels that no other app shares.

To verify the fix, run kubectl describe service web. It shows the selector, app equals web, and the Endpoints, which are the Pod IPs the Service routes to. Then kubectl get pods with the same label lists the matching names. After the fix, you should see three Pods, as in this illustrative output.

A Service routes to every Pod whose labels match its selector. After each deploy, check its Endpoints. A Service doesn't know which Pods you meant. Only which labels match.