kubectl diff command

[fgrzadkowski]

It'd be great if user could diff current configuration with the one in a file. I imagine output to be a regular smart diff of JSON files (ignoring version, status etc).

[kbeecher]

I take it you mean something like this?

$ kubectl diff service my-service my-service.json

And that would output, for example:

{
   "kind":"Service",
   "apiVersion":"v1beta3",
   "metadata":{
      "name":"redis-master",
      "labels":{
         "name":"redis-master"
      }
   },
   "spec":{
      "ports": [
        {
-          "port":6379,
+          "port":6380
        }
      ],
      "selector":{
         "name":"redis-master"
      }
   }
}

Of course, this should work with YAML too.

[bgrant0607]

cc @jackgr

[bgrant0607]

diff is a building block needed for configuration reconciliation (#1702), so I'd like to get this in.

[mikedanese]

Assigning to @jlowdermilk as he has the PR assigned to him.

[bgrant0607]

@krmayankk

The patch generated should not contain the defaults. Think of it as a 3-way merge. It's not just defaults, but all fields set during/after creation.

For more info, see:

#15894
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#defaulting
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#late-initialization
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#strategic-merge-patch

[arashbina]

I like to contribute and looking for a task to start. Not sure if @krmayankk is working on this but if no one has taken this on I can work on it.

[janetkuo]

@fraenkel has a PR #31892 addressing this with kubectl apply --dry-run, instead of kubectl diff.

[janetkuo]

I like to contribute and looking for a task to start.

@arashbina Not sure if you already know about this -- we have the kubectl roadmap here: https://github.com/kubernetes/community/wiki/Roadmap:-kubectl

[arashbina]

@janetkuo I didn't know about the roadmap. Thanks. I'll check it out.

[neelance]

@janetkuo Is this still planned? I would like to see if a kubectl apply would actually change something or not, to determine if the cluster state is actually in sync with the files describing the resources.

As far as I can see, #31892 would have added that feature, but it got superseded by #31892 which also adds --dry-run, but without the "diff" functionality.

[0xmichalis]

@neelance https://github.com/kubernetes/community/blob/master/contributors/design-proposals/sig-cli/kubectl_apply_getsetdiff_last_applied_config.md should handle your case.

[k8s-github-robot]

@fgrzadkowski There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here.

[fgrzadkowski]

@kubernetes/sig-cli-feature-requests

[shiywang]

@fgrzadkowski I'm working on a new command kubectl apply diff-last-applied here #46560, I think part of the code could be reuse (but it's using an external diff tool to do that job), is there any one already taken this yet ? if not, I would like to do that

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[janetkuo]

kubectl diff has been implemented as an alpha release in 1.9. Feature tracking issue: kubernetes/enhancements#491

[gjcarneiro]

There is no documentation about what the exit status of the command means.

It seem that the exit status is 0 if there are no changes and 1 if there are changes. But without explicit documentation I am afraid to rely on this undocumented behaviour and it breaking in the future.

[cmrust]

@gjcarneiro I agree that this behavior should be documented (and tested if it isn't already), but I'd like to point out that this is how the linux diff cli tool works as well and I imagine this was implemented this way purposefully and is likely safe to rely upon.

[apelisse]

@gjcarneiro I agree that this behavior should be documented (and tested if it isn't already), but I'd like to point out that this is how the linux diff cli tool works as well and I imagine this was implemented this way purposefully and is likely safe to rely upon.

Correct, but we still should document that none-the-less. Thanks for the interest.

[praseodym]

kubernetes/kubectl#707 was created to improve the exit code behaviour, hopefully this will result in some documentation as well.

[apelisse]

/wg apply