support v1_22 by feature gating crd v1beta1

[clux]

slightly dodgy because we need to do one of:

• pin k8s-openapi to v1_22 to test legacy features (tested in crd_api)
• pin k8s-openapi to v1_21 and hope the legacy paths work (cant test)
• build multiple k8s-openapi versions in CI

maybe the latter is the best. can pin latest everywhere, and have
examples lag behind as the only place to test legacy?

[nightkr]

For the testing, maybe it'd be enough to add the following commands to the test suite:

• cargo test --package kube --features k8s-openapi/v1_22
• cargo test --package kube --features k8s-openapi/v1_21,deprecated-crd-v1beta1

[mattsre]

Hey there, is there any work that can be picked up here to help push this forward? I've looked a bit at the related issue and am currently running into the same issue on a project of mine when trying to upgrade to v1_22. I think being able to build/test against multiple versions of k8s_openapi in CI would be really nice.

[clux]

Yeah sorry, a bit busy atm. Insofar as functionality is concerned this branch is done so you can use a cargo git pin to test. Otherwise, I'll be back for a bit on Tuesday evening and can probably make a few tweaks to the testing strategy and get this in then.

[clux]

Decided on tracking latest version in master, so have fixed up unit tests in kube-core to point at non-deprecated endpoints, and bump to v1_22 everywhere.

Also added a deprecated feature re-export in examples and corr. feature gates around the crd_api example so that we can simply add one more test instruction in the ci job (similar to @teozkr 's suggestion) where we remove default features and test examples with a deprecated feature instead. However, this does need a disablable latest examples feature afaikt because the v1_22 feature must exist by default , and we can't just union in an older version (k8s-openapi only permits one feature), so this is the closest thing I could see working.

[clux]

Ok, did some testing of this locally. The compile tests we run for crd_api is likely ok, just wanted to check. To actually check it we need to run an older cluster:

k3d cluster create --servers 1 --agents 1 --image rancher/k3s:v1.20.10-k3s1
# export kubeconfig correctly and maybe use it with KUBECONFIG
cargo run --example crd_api --no-default-features --features=deprecated,native-tls,kubederive

Satisfied that this at least works, so will merge this and leave the test to compile only on CI for now.

[clux]

Released in 0.60.0 :-)