Allow force use of upgrade-k8s

[myoung34]

I recently got tricked up by using 1.9.5 talosctl after upgrading my nodes to 1.10.6 (I thought I was using 1.10.6 client)

It resulted in:

$ talosctl -n 192.168.1.25 upgrade-k8s --to 1.33.2

automatically detected the lowest Kubernetes version 1.32.3
unsupported upgrade path 1.32->1.33 (from "1.32.3" to "1.33.2")

While I like the idea of that, and the use of checks, I have my own usage of kubent and kubeconform.
Id like to be able to force upgrades. I know its great to have these checks, but requiring them on the client isn't ideal without a work around.

Some thoughts:

• the client being 1.9.5 and only allowing up to 1.32.7 is a weird enforcement. 1.33.3 exists regardless. Im ok with a flag that forces the onus on me to know if its compatible or not such as --force
• The error message automatically detected the lowest Kubernetes version 1.32.3 is not great. 1.32.7 was valid and would work here but echoing back what I have installed on my nodes with nothing to hint at to what to do really tripped me up. Maybe a Client 1.9.5 cannot go beyond 1.32.x. That would have literally told me what I was doing wrong.
• I may not want to use talosctl built in upgrade checker. There are nuances in checking upgrade compatibility. If for some reason it says I can't but I know I can due to updates to kubent, kubeconform, kubepug, or the others out there I would have been stuck. Maybe a --no-compatibility-check flag. Also this lets people use their own tools of choice, and you know how people are with their tools of choice 😉

I like that talosctl wanted to help me, but it kind of got in the way here based on some choices in opinions, not actual technical reasons.

Thoughts:

• talosctl -n 192.168.1.25 upgrade-k8s --to 1.33.3 --force -> no compatibility check, just (atttempt to do it). error if 1.33.3 isnt available.
• talosctl -n 192.168.1.25 upgrade-k8s --to 1.32.7 --no-compatibility-check -> dont force, still see if its available first (like it did) but just skip the checks. Let people break their own stuff use their own judgement/compatibility tools if they choose

[jamessevener]

This has tripped me up as well. It'd be helpful if talosctl either told you it wasn't the latest version, or as Marcus suggested something like Client 1.9.5 cannot go beyond 1.32.x would help significantly.

[rothgar]

I think this is a reasonable output that points people in the right direction while still being able to keep opinions about how the compatibility should be managed

[myoung34]

To add why I dont like this

[smira]

You can always upgrade yourself if you don't like the CLI tool provided (or even build your own), but we should try to ensure that we solve it for the majority of the users in the safest way possible.

[jamessevener]

Quite like talosctl but the output when it's not updated enough for a given action has left me stumped in the past. I think it makes sense to make the output more helpful.

[myoung34]

I love the CLI provided tool, I just want it to block me for technical reasons, not opinions
I would have 100% been successful using the 1.9.5 tool to upgrade from 1.32.3 to 1.33.3 had it let me.

Even if i wanted to do it myself that's not documented. Every result for "talos upgrade kubernetes" links to the tool and the upgrade-k8s subcommand

[pjoomen]

My 2 cents on this discussion:

• it would make sense to have the upgrade-path check being done server side and not client side
• the fact upgrade-k8s also applies internal and external manifests being specified in the machineconfig can be confusing/suprising (if one is not expecting this side-effect)