kubectl apply --dry-run behaving weirdly

[ghost]

Having a random deployment yaml file:

Modifying for example the image or the number of replicas:

• kubectl apply -f Deployment.yaml -o yaml --dry-run outputs me the resource with the OLD specifications

• kubectl apply -f Deployment.yaml -o yaml outputs me the resource with the NEW specifications and updates it

Since according the documentation:

--dry-run=false: If true, only print the object that would be sent, without sending it.

I would have expected the dry-run command to print the very same yaml configuration and not the old one.

Tested on minikube, gke v1.10.0

https://stackoverflow.com/questions/54074758/kubectl-apply-dry-run-behaving-weirdly

[ghost]

/sig apply
/sig apps

[liggitt]

/sig cli
/remove-sig apps

[liggitt]

cc @apelisse

[liggitt]

When updating existing objects, kubectl apply doesn't send an entire object, just a patch. It is not exactly correct to print either the existing object or the new object in dry-run mode... the outcome of the merge is what should be printed.

For kubectl to be able to accurately reflect the result of the apply, it would need to have the server-side apply logic clientside, which is a non-goal.

Current efforts are directed at moving apply logic to the server. As part of that, the ability to dry-run server-side has been added. kubectl apply --server-dry-run will do what you want, printing the result of the apply merge, without actually persisting it.

[liggitt]

@apelisse we should probably update the flag help for apply and possibly print a warning when using --dry-run when updating an object via apply to document the limitations of --dry-run and direct people to use --server-dry-run