Global load balancer and traffic shifting is a real thing.
But my preferred way is in place as it's easy: upgrade one Ctrl plane node after the other, than upgrade every node or create a new one and move your workload.
The power of k8s is of course shit when you only move legacy garbage into the cloud as those are not ha at all.
But lucky enough people slowly learn how to write apps cloud native.
Even with the best cloud native apps that can really be easily moved from one node to another, it is not easy to do cluster upgrades.
Upgrading one control plane node after another can still break your cluster when you have your control plane nodes running incompatible versions.
If you get a big worker node failover during the control plane upgrade, which of the control plane nodes should provision the new worker nodes, which versions of containers should kubelet pull, etc?
The upgrade process for a running multi-node solution is an extremely difficult technical challenge, and it has to be designed very carefully to actually have a good chance of working. Breaking changes are almost impossible to introduce if the goal is to upgrade gracefully - you probably need a special compatible version to run while the upgrade is still in progress, that is neither the old version nor the targeted new version, but can handle both. You need to make sure all APIs are versioned in a way where it's easy to distinguish a request coming from an old client (so you can serve the old format) or a new one etc.
Kubernetes has done some work on this, but it still often requires manual work. And many common plugins have just not put in this work and will break if you try to upgrade a live cluster.
But my preferred way is in place as it's easy: upgrade one Ctrl plane node after the other, than upgrade every node or create a new one and move your workload.
The power of k8s is of course shit when you only move legacy garbage into the cloud as those are not ha at all.
But lucky enough people slowly learn how to write apps cloud native.