You renamed one label. Kubernetes refused the whole deploy. Here's the path. The developer runs kubectl apply with app: frontend, and kubectl sends the Deployment update to the API Server. The API Server sends back an error, saying the selector is immutable. kubectl passes that along, and the deploy is rejected. So why can't you change it?

The cause starts with the selector. A selector is a label rule the Deployment uses to find its own Pods. Here, the Deployment's selector says app: web, and it matches Pod 1, Pod 2, and Pod 3, which all carry that label. That match is how the Deployment knows which Pods are its own.

On the left, the Deployment's rule is app: web, and its three Pods carry that label, so the lines are solid. On the right, the rule says app: frontend. None of the running Pods match it, so the connections break. That's why Kubernetes locks the selector on an existing Deployment.

Follow the arrow. The Deployment now carries the new selector, app: frontend, and that selector matches no Pods at all. Meanwhile, the three web Pods keep running, but nothing manages them anymore. They'd be unmanaged. The lock exists to stop the Deployment from losing track of its own Pods.

You have two safe options. First, leave the selector as app: web and add any new labels next to it. Second, if you truly need a different selector, create a new Deployment with it, then remove the old one.

Here's the first fix. The Deployment's selector still points at app: web, and the Pods keep that label, so they still match. Then we add tier: frontend as an extra label on the Pods. The selector doesn't change, so the Deployment keeps control, and you still get your new label.

Labels are how a Deployment finds its Pods. Change the name, and it can't find them. So keep the selector fixed and add labels instead.