You fixed it with kubectl edit. The next deploy undid it. Here's the chain: pods got OOMKilled, meaning killed for running out of memory. You raised the memory, and the app recovered. Later, a teammate ran apply, the old value came back, and the pods were OOMKilled again.

kubectl edit opens the live object, the copy stored in the cluster, not your file. Here the developer raises the memory limit from 256Mi to 512Mi and saves. Kubernetes replaces the pods with the new limit, and the app recovers. Only the cluster changed, though.

Meanwhile, the manifest file in the repo, deployment.yaml, still says 256Mi. Nobody changed it. Later, a teammate runs kubectl apply with that file, and the output says deployment web configured. Apply treats the file as the source of truth, so it pushes 256Mi back into the cluster.

Follow the live value. The repo file sets 256Mi, and the cluster starts there. The developer edits the cluster to 512Mi. The file never changes. Then the teammate reads that same file, still 256Mi, and applies it. The live value drops back. Only the cluster was ever edited, never the file.

Think of it this way: the file is the source, and apply copies it onto the cluster, overwriting live edits for the fields the file sets.

The fix happens in the file. Change the memory limit in deployment.yaml to 512Mi, then commit it so teammates and pipelines get the same value. Finally, run kubectl apply. Now the file and the cluster agree, so every future apply keeps 512Mi.

Apply copies the file onto the cluster, so it overwrites live edits. Make your change in the repo file, then apply. The file always wins. Fix the file.