kubectl apply --dry-run behaving weirdly

Question

I am facing a weird behaviour with kubectl and --dry-run.

To simplify let's say that I have the following yaml file:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginxsdf
        imagePullPolicy: Always
        name: nginx

Modifying for example the image or the number of replicas:

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

According to the documentation:

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

However the object printed is the old one and not the one that will be sent to the ApiServer

Tested on minikube, gke v1.10.0

In the meanwhile I opened a new gitHub issue for it:

https://github.com/kubernetes/kubernetes/issues/72644

Yes, I was able to reproduce this behaviour and am equally surprised. Could be a bug but at least it's bad UX. I left a comment in the SIG CLI channel, maybe someone has a look at it and has an idea if this is expected or not. — Michael Hausenblas, Jan 07 '19 at 13:20
Moreover with `create` it does not show this behaviour and the output it the expected. I created a github issue for it — GalloCedrone, Jan 07 '19 at 13:21
That's a good idea, maybe update your question with a link to the issue? FWIW, I suspect the three-way merge semantics of `apply` here showing strange side effects here but let's see ;) — Michael Hausenblas, Jan 07 '19 at 13:23
@MichaelHausenblas I tried to understand how it was happening checking the trace with the -v=10 but I went nowhere — GalloCedrone, Jan 07 '19 at 13:33

score 8 · Accepted Answer · edited Jun 20 '20 at 09:12

I got the following answer in the kubernetes issue page:

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.

@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

score 5 · Answer 2 · answered Nov 17 '21 at 18:25

5

The latest version of the client uses:

kubectl apply -f Deployment.yaml --dry-run=server

answered Nov 17 '21 at 18:25

Charles Gravlee

53
1
4

kubectl apply --dry-run behaving weirdly

2 Answers2