Create the PR placeholder to update the About API CRD based on kubernetes/enhancements#3652

Notably:

• update CRD and add client for v1beta1
• update any examples with id.k8s.io --> cluster.clusterset.k8s.io

Please see this link for reference.
Without this annotation, the deployment of the CRD will throw an error such as:

The CustomResourceDefinition "clusterproperties.about.k8s.io" is invalid: metadata.annotations[api-approved.kubernetes.io]: Required value: protected groups must have approval annotation "api-approved.kubernetes.io", see https://github.com/kubernetes/enhancements/pull/1111

Provide standalone CRD yaml that could be referenced using a URL to avoid needing to clone the repo and do make install because of the kustomize, which itself requires many other dependencies. (hat tip @jkremser for flagging this 🎉 )

The clusterproperty API group is currently defined as group: about.k8s.io
https://github.com/kubernetes-sigs/about-api/blob/master/clusterproperty/config/crd/bases/about.k8s.io_clusterproperties.yaml#L10

But as stated in KEP k8s.io group protection https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/2337-k8s.io-group-protection/README.md
This group should be protected unless there is an annotation with the PR attached.
The current kustomize patch annotation points to a not related API (default template value?): https://github.com/kubernetes/kubernetes/pull/78458
https://github.com/kubernetes-sigs/about-api/blob/master/clusterproperty/config/crd/patches/annotation_for_clusterproperties.yaml#L6

Should the clusterproperty API group be x-k8s.io instead?

Add a custom value column to the ClusterProperty CRD, so basic kubectl get shows a truncated value

run hack/update-codegen.sh does not generate informer and lister

/help
It looks like we are eligible to upgrade our toolchain at somepoint using the latest kubebuilder variant with plugin go/v4. Of the listed upgrade reasons we meet the following criteria:

- If you are looking to have your project update with the latest version available
- if you are not targeting k8s versions < 1.16 and 1.20 if you are using webhooks
- If you are looking to work on with scaffolds which are compatible with k8s 1.25+

/priority important-longterm
However, we are not in a rush as we are not blocked by any of the other reasons, and this does require a tedious migration process involving regenerating some code as the directory structure totally changed. See the migration guide here if you are interested.

go get github.com/kubernetes-sigs/about-api/clusterproperty@f06d7db18c74a8da69510b755bad4e6f55679b14
go: downloading github.com/kubernetes-sigs/about-api/clusterproperty v0.0.0-20220614182201-f06d7db18c74
go: downloading github.com/kubernetes-sigs/about-api v0.0.0-20220614182201-f06d7db18c74
go get: github.com/kubernetes-sigs/about-api/[email protected]: parsing go.mod:
	module declares its path as: k8s.io/clusterproperty
	        but was required as: github.com/kubernetes-sigs/about-api/clusterproperty

go get k8s.io/clusterproperty
go get: module k8s.io/clusterproperty: git ls-remote -q origin in ...: exit status 128:
	ERROR: Repository not found.
	fatal: Could not read from remote repository....

I am not a golang expert, but I think either the k8s.io/clusterproperty should redirect to this github repo or this should be named differently.

golang/go#34055

I can't easily refer to k8s.io/clusterproperty from my go-1.17 project because it doesn't resolve; instead, I see 404 errors.

We accidentally left in .spec.name when the KEP describes / the intention is to have the names of ClusterProperties use .metadata.name.

I am trying to install the about API using the make file in the repository. When I try building the binary or the container image, I get the following error:

bash: /Users/<name>/GitProjects/about-api/clusterproperty/bin/controller-gen: No such file or directory

I am using Go 1.21.4. Creating a /bin directory in the clusterproperty directory had no effect.

Develop some vendor agnostic intro tutorials about the About API that can be easily digested as part of a generic documentation push. I think it would be useful to tie them to some common use cases as suggested below.

• About API for storing cluster name and sending as prometheus label in your metrics instrumentation
• About API for storing arbitrary, implementation specific cluster properties following the rules listed here and discussed on this slide, possibly a cluster's network name, region, etc