Expose the version of Kustomize that Kubectl embeds

[KnVerey]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes kubernetes-sigs/kustomize#1424. This is the top feature request on Kustomize by upvotes and has also been requested directly on the kubectl and oc repos.

/cc @natasha41575

Special notes for your reviewer:

Updated to match the implementation agreed to at the Mar 23 SIG CLI meeting

This PR extracts the current Kustomize version from the root go.mod and sets an ldflag that embeds the version into Kustomize's Provenance code (the same code that drives standalone kustomize version). It then uses that information to expose Kustomize version info in kubectl version. It also adds a sanity check to the Kustomize update script, ensuring that the version output matches what the update executor intended.

Alternatives considered:

• Embedding the Kustomize version inside the client section of kubectl version: [ALTERNATIVE] Expose the version of Kustomize that Kubectl embeds #108947
• Introduce kubectl version --kustomize to expose this info specifically. Would be clean to implement, but not consistent with anything else I'm aware of, and probably unintuitive.
• Having the Kustomize release process directly embed the version, or having the kubectl update process embed it in the kubectl integration code (3dba87f). Both of those would cause potentially inaccurate output for other CLIs importing kustomize and kubectl CLI code respectively.
• kubectl kustomize version (1e7c1db). It was pointed out at today's SIG meeting that the version also applies to kubectl apply -k, not just kubectl kustomize.

Output

Expand to show output samples

༶ _output/bin/kubectl version
Client Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.0-alpha.4.14+b85880aac7a987-dirty", GitCommit:"b85880aac7a9879f70b4d124e0f92826a00eeb0a", GitTreeState:"dirty", BuildDate:"2022-03-23T22:57:37Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.4.1
Server Version: # not relevant / unchanged

༶ _output/bin/kubectl version --client
Client Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.0-alpha.4.14+b85880aac7a987-dirty", GitCommit:"b85880aac7a9879f70b4d124e0f92826a00eeb0a", GitTreeState:"dirty", BuildDate:"2022-03-23T22:57:37Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.4.1

༶ _output/bin/kubectl version --client -o yaml
clientVersion:
  buildDate: "2022-03-23T22:57:37Z"
  compiler: gc
  gitCommit: b85880aac7a9879f70b4d124e0f92826a00eeb0a
  gitTreeState: dirty
  gitVersion: v1.24.0-alpha.4.14+b85880aac7a987-dirty
  goVersion: go1.17.6
  major: "1"
  minor: 24+
  platform: darwin/arm64
kustomizeVersion: v4.4.1

༶ _output/bin/kubectl version --client -o json
{
  "clientVersion": {
    "major": "1",
    "minor": "24+",
    "gitVersion": "v1.24.0-alpha.4.14+b85880aac7a987-dirty",
    "gitCommit": "b85880aac7a9879f70b4d124e0f92826a00eeb0a",
    "gitTreeState": "dirty",
    "buildDate": "2022-03-23T22:57:37Z",
    "goVersion": "go1.17.6",
    "compiler": "gc",
    "platform": "darwin/arm64"
  },
  "kustomizeVersion": "v4.4.1"
}

༶ _output/bin/kubectl version --short
Client Version: v1.24.0-alpha.4.14+b85880aac7a987-dirty
Kustomize Version: v4.4.1
Server Version: v1.22.4

Does this PR introduce a user-facing change?

`kubectl version` now includes information on the embedded version of Kustomize

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

@KnVerey: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

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/test-infra repository.

[natasha41575]

/lgtm

[natasha41575]

/retest

[KnVerey]

/hold

I think this approach might be problematic for CLIs that embed kubectl (and by extension kubectl kustomize). At minimum, I think kubectl kustomize version should print "unknown" by default and give those tools a hook to set the version they're using. And the version k/k is pinned to should probably be injected by the release pipeline (which needs to be informed of it somehow) instead of straight into the code during the dep update.

(Note: I tried debug/ReadBuildInfo#Deps, but it doesn't seem to be available, at least to local builds.)

[KnVerey]

/test pull-kubernetes-node-e2e-containerd

[KnVerey]

/test pull-kubernetes-node-e2e-containerd

[natasha41575]

/lgtm

[KnVerey]

When running the version tests, I noticed that some of the helpers it uses had nice colorization and others did not. This is in a separate commit, and I can easily remove it from the PR if it is unwanted.

[soltysh]

Good catch, those are usually handy :) Thank you!

[KnVerey]

I got rid of the separate serverVersion and clientVersion variables in favour of having all usages rely on the same copy of the data, i.e. the one in versionInfo

[KnVerey]

@soltysh I've updated this PR to match the implementation agreed to at the meeting earlier today. I've also created yet another option for consideration at #108947. LMK what you think.

[liggitt]

I'd really like to avoid this plumbing here, since the compiled in module info is in reach with go 1.18 and this build script services many binaries, not just kubectl

[soltysh]

/lgtm
/approve

[soltysh]

Good catch, those are usually handy :) Thank you!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KnVerey, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• hack/OWNERS [soltysh]
• staging/src/k8s.io/kubectl/OWNERS [KnVerey,soltysh]
• test/cmd/OWNERS [KnVerey,soltysh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mikebz]

great to see this in the version output. It is a frequently asked question.