Add optional full yaml paths to kubectl explain output

[spkane]

What would you like to be added: It would be GREAT if there was a way to get kubectl explain to output the full yaml path for each entry, especially when --recursive is set.

So, output that looks like this today:

  metadata	<ObjectMeta>
    annotations	<map[string]string>
    managedFields	<[]ManagedFieldsEntry>
      apiVersion	<string>
      fieldsType	<string>

might look like this:

  metadata	<ObjectMeta>      [metadata]
    annotations	<map[string]string>      [metadata.annotations]
    managedFields	<[]ManagedFieldsEntry>      [metadata.managedFields]
      apiVersion	<string>      [metadata.managedFields.apiVersion]
      fieldsType	<string>      [metadata.managedFields.apiVersion]

Why is this needed:

In addition to using kubectl explain to find out what a field is for and what type it expects, it could be very useful in determining where in the YAML structure a section belongs. With this change, running something like the following would make it much clearer WHERE the section belongs in the YAML manifest.

$ kubectl explain pod --recursive=true | grep preferredDuringSchedulingIgnoredDuringExecution

        preferredDuringSchedulingIgnoredDuringExecution	<[]PreferredSchedulingTerm>    
  [spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution]
        preferredDuringSchedulingIgnoredDuringExecution	<[]WeightedPodAffinityTerm>    
  [mspec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution]
        preferredDuringSchedulingIgnoredDuringExecution	<[]WeightedPodAffinityTerm>    
  [mspec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution]

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[spkane]

@eddiezane @soltysh Is this something that seems reasonable? If I have some time I might try and make this happen if there are no general issues with the idea.

[mpuckett159]

I think this might be best suited as a plugin to start out with. I'm a little reluctant to accept this because this would make the output pretty cluttered, and this information is generally available elsewhere. If you're willing to put together a PR for us to look at more directly.

Note, I would expect metadata.managedFields to be metadata.managedFieldEntry[] or something else that denotes it's a list.