Upgrade kubectl (currently 1.21.10)

[BernhardGruen]

Is your feature request related to a problem? Please describe.
The used version of kubectl inside the provided container-image (based on Dockerfile from this repository) uses an outdated version of kubectl (1.21.10 as of writing this issue).

Describe the solution you'd like to see
I think upgrading to version 1.25.x would be a nice step forward. This ensures API compatibility from 1.23 to 1.27 and 1.25.x is still supported upstream.

Describe alternatives you've considered
One alternative would be to provide images with multiple versions of kubectl. But that would increase the image size. The second alternative would be to provide multiple images with different version to still provide best backwards compatibility.

[nabokihms]

@BernhardGruen, thank you for pointing this out. I think the best option to resolve the problem is to remove kubectl from the container image. Let me explain why.

1. Shell-operator now has a Kubernetes patcher, which is a powerful tool to work with Kubernetes objects. Most kubectl operations can be substituted with it. The listing of objects can be done through kubernetes bindings. As of today, we are considering using kubeclt as an edge case.

2. Shell-operator is tight to the kubectl Kubernetes version compatibility matrix. Updating kubectl in the image may break user installations. By abstaining from controlling the kubectl version, we can save users from accidental breaking changes.

We are in Flant using the alternative approach you have described. There is our wrapper for kubectl that picks the version according to the version of the cluster. However, I'm afraid it does not apply to generic cases when users control their Kubernetes clusters themselves.

For now, rushing and removing kubectl from the image is not wise. We can just agree that kubectl should be in sync with the apimachinery library dependency.