janiskemper
commented
7 months ago Thanks @mxmxchere for this proposal! I want to make a comment on Cluster Stacks vs ClusterClasses, because you proposed to use ClusterClasses but said that Cluster Stacks are not flexible with regards to Kubernetes version.
The Cluster Stacks use ClusterClasses under the hood and just package all objects together and all the configuration that is needed for the Kubernetes update. It therefore extends ClusterClasses and gives the same flexibility in terms of upgrading Kubernetes versions.
If you have doubts, feel free to raise a topic e.g. in the container meeting!
cah-hbaum
Openstacks Instance flavors define immutable (to the best of my knowledge) aspects and capabilities of an openstack instance such as CPU, Disk, GPU, memory...
Analog to Openstack Instance Flavors we could introduce "Cluster flavors" which control certain aspects of a cluster that are immutable once it is created. I think it is easiest to explain that with an example. We have two Cluster flavors named "dev" and "prod"
prod flavor
Clusters of the cluster flavor prod get deployed with three controlplane nodes and it is taken care that these nodes are scheduled on different hypervisors. Those clusters take longer to deploy, are more robust but are more expensive for the customer.
dev flavor
Clusters of the Cluster flavor dev get a controlplane that is managed by kamaji on a shared controlplane hosting cluster. The cluster is ready quicker, is not as robust as the prod flavor but costs less and uses fewer resources.
I assume that in a typical scenario a customer will order one or a few prod clusters with many dev clusters where developers can test changes to the prod environment.
the concept of cluster flavors is completely decoupled from instance/worker flavors. cluster flavors (in my proposed definition) divide clusterclasses by aspects that are immutable during the lifetime of that cluster. Workers of any instance/worker flavor can be added and removed all the time independent of the chosen cluster flavor
There might be a synergy with the Cluster stacks approach. However, to the best of my knowledge a clusterstack has a fixed kubernetes version. I consider the kubernetes version a changing aspect over the lifecycle of a cluster. Therefore it does not qualify for being a property that creates a new cluster flavor. In other words: a cluster of v1.28.1 or v1.27.2 should be available in the same cluster flavor and it should be possible to update the kuberntes within the same flavor (Analog to a instance/worker flavor where you can update your operating system while staying in the same flavor or choose different start images independent of the instance/worker flavor
It seems to me that cluster api supports this proposal very well: There could be different Clusterclasses for each flavor (or we could even adopt the terminus of clusterclasses instead of flavorurs). In addition to that clusterapi supports different controlplane providers. cluster api could spawn dedicated nodes for prod clusters or facilitate kamajis cluster-api control plane provider for small dev clusters