Decouple updating Kubernetes and Lokomotive components when updating Lokomotive.

[ipochi]

Considering an analogy of Ubuntu system:

Executing sudo apt upgrade doesn't update the Ubuntu operating system , my desire and the command's intention are in sync with each other i.e Upgrade the software packages and that's what I think of Lokomotive components.

If I specifically want to upgrade the operating system to a newer version along with newer version of software packages I would call upon a different command sudo apt dist-upgrade / sudo apt full-upgrade which is what I think of Kubernetes as i.e equivalent of an OS.

Currently Lokomotive does not separate from updating Lokomotive cluster( i.e Kubernetes version) and Lokomotive components when executing lokoctl cluster apply with a newly released Lokomotive version.

What this entails is that the user must consume the lokomotive binary in full (i.e update cluster and the updated components).
This creates a problem if the desire is not to frequently update the Kubernetes versions rather only the Lokomotive components.

As per the latest container-report by Datadog, it was observed that the most popular version of Kubernetes was v1.15 even though it was released 17 months ago. However it is not clear whether this is due to the desire not wanting to do frequent updates or easy hassle free upgrades is a gap in the market, so some research is required to understand the Why.

[invidian]

This is something we should approach very carefully, as implemented, would greatly expand our test matrix. I definitely agree that we should have a good understanding why running older version is the most popular case. To be honest, my guess is that people can't keep up with updates and testing when you have OS -> Kubernetes -> Infrastructure components -> Application Manifests.