Along the lines of messing with go mods. Is there any good reason we still pin the k8s libs to v0.28.2? @gorgeous-waitress-5026 mentioned that we should probably align with the k8s support model and I agree we should probably unpin those libraries and keep them up to date, even if we don't use new k8s features in Flyte

Yeah, +1 to upgrading to a newer k8s client version. As of 1.16, sidecar containers are now required for copilot (which is required for container task to manage inputs and outputs) k8s 1.29 introduced sidecars as alpha, but they didn't become stable until k8s 1.33 -- cloud distros like EKS didn't start shipping it until recently

Is there any good reason we still pin the k8s libs to v0.28.2

we should be able to unpin it once we upgrade go to 1.25

We can bump up to at least the 1.33 client (which is far enough for now IMHO) against Go 1.24 per https://github.com/kubernetes/client-go/commit/a126675a40e57bf4b0cb94bd88520c38b1322487#diff-33ef32bf6c23acb95f5902d[…]a061167ec0716715b0b9eeaa5f6L5

FWIW, I’m currently working on upgrading spark-operator to v2.3.0, which also requires a newer client-go version. So +1 from my side on unpinning the k8s libs once the Go 1.24/1.25 upgrade lands. it’ll help keep the spark-operator work aligned as well.

PR to unpin the k8s libs: https://github.com/flyteorg/flyte/pull/6835