Support Kubernetes v1.26

[tenzen-y]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
We need to support Kubernetes v1.26 since that version was released on 2022-12-9.

https://kubernetes.io/releases/#release-v1-26

Maybe, we can support that version after the next katib release.
This means supporting v1.26 is out of scope in katib v0.15.0.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

---

Love this feature? Give it a 👍 We prioritize the features with the most 👍

[andreyvelich]

@kubeflow/wg-training-leads @tenzen-y @anencore94 Do we have plans what Kubernetes versions do we want to support in the following releases ?

I don't think we should be extremely fast to drop old Kubernetes versions (e.g. 1.23).
Many users still use old Kubernetes versions and they can't move as fast as OSS goes.
So if we want to get more production usage of Katib, we should be in sync with our users and be careful about Kubernetes versions.

For example, Istio (which has big adoption and production usage) supports 4 Kubernetes versions: https://istio.io/latest/docs/releases/supported-releases/#support-status-of-istio-releases.

[terrytangyuan]

In Argo project, we usually only support the ones that are still actively maintained to avoid security risks. This is what we look at when deciding the supported versions: https://endoflife.date/kubernetes

[tenzen-y]

Do we have plans what Kubernetes versions do we want to support in the following releases ?

I think we can support v1.23, v1.24, and v1.25. This means we do not support v1.26 on the next release.

I don't think we should be extremely fast to drop old Kubernetes versions (e.g. 1.23).
Many users still use old Kubernetes versions and they can't move as fast as OSS goes.
So if we want to get more production usage of Katib, we should be in sync with our users and be careful about Kubernetes versions.

As @terrytangyuan says, if we support the EoL K8s versions, we can not avoid security risks and bugs.
Also, this means we suggest the EoL K8s versions to users for the long term since we have a slow release cycle.

In addition, supporting 4 versions of K8s would require more time for E2E testing.

So, I think we need to have a more quick release cycle and make speed up E2E testing if supporting 4 versions.

[tenzen-y]

in favor of #2155.

/close

[google-oss-prow]

@tenzen-y: Closing this issue.

In response to this:

in favor of #2155.

/close

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.