Kubernetes Crash Course for .NET Developers (2026) – Part 3

The Desired State

A deployment.yaml describes the desired state of the Kubernetes resources defined in that file, not the desired state of the entire cluster.

Example

When you change the name of your deployment in your deployment.yaml and re-apply it, you get this: an additional deployment next to the old one

~  $ kubectl get pods
NAME                               READY   STATUS              RESTARTS   AGE
demo-deployment-6b7d948997-gvzdb   1/1     Running             0          5m45s
demo-deployment-6b7d948997-hk4d9   1/1     Running             0          5m45s
demo-deployment-6b7d948997-swvf6   1/1     Running             0          5m45s
demo-ramboe-6cbbf94498-5stjn       0/1     ContainerCreating   0          3s
demo-ramboe-6cbbf94498-6q7vt       0/1     ContainerCreating   0          3s
demo-ramboe-6cbbf94498-b8w2b       0/1     ContainerCreating   0          3s

Now let's pretend you're working in a team, so someone else caused this other deployment and you don't know where it's coming from right away.

how would we investigate that?

Methods used for investigation

fzf-lua

We could browse our deployment files by <old-deployment-name>

git history

grep through all the additions and deletions in the commit history of files in the current directory plus sub paths

git log --all -p -- . | grep "demo-deploy"

Part	Meaning
git log	Show commit history
--all	Include all branches (not just the current one)
-p	Show the patch (diff) for each commit, not just the commit message
--	Separator: everything after this is a path, not a flag
.	The path — "current directory and everything under it"

use the kubernetes.io/change-cause annotation

use kubectl rollout history deployment/<old-deployment-name> to display the change-cause recipe

kubectl rollout history deployment/demo-deployment

~  $ kubectl rollout history deployment/demo-deployment
deployment.apps/demo-deployment
REVISION  CHANGE-CAUSE
1         init

Consequences for the Http Traffic Routing

We still have the same service inside kubectl get svc, remember: services route traffic by label. The new deployment got new pods, but they still have the same old label.

So this service now simply distributes the between all the containers from both deployments

Clean up command to remove the old deployment

kubectl delete deployment demo-deployment