Lifecycle integrations for clusterClass

[killianmuldoon]

ClusterClass is currently able to supply a cluster with the required objects to set up a working Kubernetes cluster through CAPI, but not all features of Cluster API, or technologies that integrate with Cluster API are covered. The ClusterClass proposal says, under "prospective future work":

Lifecycle integrations: Extend ClusterClass to include lifecycle management integrations such as MachineHealthCheck and Cluster Autoscaler to manage the state and health of the managed topologies.

This issue is about defining how, if desired, we can implement these Lifestyle integrations in ClusterClass. The following issues cover three areas have their own issues:

Cluster Autoscaler: #5442
MachineHealthCheck: #5125
ClusterResourceSet: #5203

Questions:

• Which of the above, if any, do we want to support in ClusterClass?
• Where should the line be drawn for including resources/capabilities directly in the ClusterClass spec?
• Should we have a more generic extensible interface for including integrations in ClusterClass (/cc @elmiko 📖 Add MHCClass spec and details to proposal #5511 (review))
• Should these integrations be embedded in the spec or use external templates?

/area topology

/cc @enxebre @sbueringer @elmiko

[elmiko]

thanks @killianmuldoon , i think this is a good discussion to have

[fabriziopandini]

/milestone v1.1
I agree this is a good discussion.

Expanding a little bit on my opinion about this issue discussed in last office hours/in previous threads:

• We should consider that we are dealing with different type of objects here; MHC is a Cluster API primitive and so I don't consider this an integration but a built in.
• With regards to integration with other components, there is not only the autoscaler, but also CSI, CPI and probably CNI (and might be some more). Also, IMO this problem has two dimensions:
  • Installing an managing the lifecycle of those components; I have a very opinionated idea WRT to this point, because IMO we should strive for a better integration with addon management tools in the ecosystem (e.g helm, kapp), vs reinventing the wheel; I have already opened Security Self Assessment: [STRIDE-INFODISCLOSE-1] RFE cluster addons #5491 to gather feedback on this idea.
  • Ensuring that the objects generated by a ClusterClass could be configured for working with those components. This IMO is the most interesting discussion; some steps were already taken (e.g make the replicas fields optionals), but we should figure out deltas if any.
• WRT to ClusterResourceSet, I consider them orthogonal to ClusterClass given that a CRS by design can apply to multiple clusters, and It would be an anti pattern to provide a solution for creating a copy of a resource set for each cluster

[fabriziopandini]

Q: should we close this issue given that there are more detailed one for MHC, autoscaler, CRS?

[killianmuldoon]

@fabriziopandini I think we probably can given this issue isn't attracting much in the way of comments. I'm in agreement on your points above. I'm going to do a prototype PR for MHC as laid out in the proposal PR.

Other components, and the ClusterResourceSets, don't cleanly fit into the same bucket as MHC so we should think of another abstraction to integrate them with ClusterClass.

@elmiko WDYT?

[killianmuldoon]

/close

[k8s-ci-robot]

@killianmuldoon: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.