Bump k8s-openapi to 0.20.0

[clux]

Also bumps minimum kubernetes version.
Standard just bump-k8s plus cargo upgrade -p k8s-openapi -i and the few readme updates.

Last one before release.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (main@3d68ec1). Click here to learn what that means.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1291   +/-   ##
=======================================
  Coverage        ?   72.31%           
=======================================
  Files           ?       75           
  Lines           ?     6347           
  Branches        ?        0           
=======================================
  Hits            ?     4590           
  Misses          ?     1757           
  Partials        ?        0           

📢 Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kube-rs).

[nightkr]

SGTM. Might be worth including a note about Arnavion/k8s-openapi#149 in the release notes.

[clux]

Ah, yes, will add.

[Arnavion]

Out of curiosity, for all the places where you updated the k8s-openapi feature v1_27 to v1_28, why don't you use latest ?

If you're worried about latest updating to a different version in a semver-compatible update, that won't happen, because adding (or removing) supported versions is always a semver-incompatible change. Not only could that break anyone using latest, but also it could break anyone using the version macros.

[clux]

Ah, yes. Actually just hadn't gotten around to do it yet. I did just update the recommendation in our docs yesterday to tell people to use latest. And there was also some automation for it in the justfile to bump so it has not been a hard job.

Still, nice to clear all that up. Will put up a PR to update it to latest as that side is a pretty clear improvement.

By the way, the earliest alias is also very nice, and could be very helpful for the other side of the range (for testing our minimum supported version), but we are slightly misaligned on our policies (we have currently settled on a 6 version range, and you have 7 - so our MSRV is always +1 of earliest atm). It's probably a bit surprising to folks that we deviate.

Do you have strong feelings about supporting this extended range? It could make k8s-openapi a little more lightweight to drop one. We reasoned that it made sense to follow upstream EOL cycles as per our current https://kube.rs/kubernetes-version/#policy - but if you are not keen on that, we could alternatively increase our range instead.

[Arnavion]

My policy is to support the oldest one that public clouds support, per https://github.com/Arnavion/k8s-openapi/blob/master/CONTRIBUTING.md#cloud-offerings . ACK tends to be the oldest one.

[clux]

In practice, that looks like it gives you sometimes 7 versions supported, and sometimes 8. At the very least, it would be good to have a consistent answer.

(ACK running 1.22 a full 10 months after upstream maintenance was dropped is an interesting choice - but i guess all cloud providers lag behind upstream support here to some extent (EDIT: looks like Kubernetes gave ~2mo extra leeway to backport CVE fixes so only 8mo but still..))