Repository navigation
Multi Cluster Support #1308
Description
As discussed in #1307 it would be nice to have cluster a context setting for each controller.
Why?
Currently a operator can only a act on a single context. Traditionally that's fine as an operator often orchestrates only resources in the very cluster its deployed it self. In this scenario the operator gets its identity natively from the kubernetes context and is statically configured for its own cluster.
In contrast to that we have a use case where we manage multiple clusters with on operator which is deployed to a meta/central cluster. The operator still manages resources within this meta cluster but to instantiate the desired application it will also manage child/runtime clusters.
Example:
The control cluster manages a CRD which has been instantiated twice. The operator picks them up and deploys resources to fulfil the desired resource. To do that the operator has to deploy the application into multiple clusters which are e.g. physically separated and therefore can't have a single identity or are separated due to availability needs or to test new versions of kuberentes etc. Therefore a full replication of the resources is created in each cluster and the operator watches all of them.
Control Cluster
┌──────────────────────────────┐ Cluster A
│ │ ┌──────────────────────────────────────────┐
│ Namespace-crds │ │ Namespace-A Namespace-B │
│ ┌──────────────┐ ┌───┼─┤►┌─────────────┐ ┌─────────────┐ │
│ │ │ │ │ │ │ │ │ │ │
│ │ CRD-A │ │ │ │ │ Deployment │ │ Deployment │ │
│ │ CRD-B │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ └─────────────┘ └─────────────┘ │
│ └─────▲────────┘ │ │ │ │
│ │ │ │ └──────────────────────────────────────────┘
│ │ Reconcile │ │
│ │ │ │ Cluster B
│ ┌────┴────────┬──────┘ │ ┌──────────────────────────────────────────┐
│ │ │ │ │ Namespace-A Namespace-B │
│ │ Operator ├──────────┼──┤►┌─────────────┐ ┌─────────────┐ │
│ │ │ Create/ │ │ │ │ │ │ │
│ └─────────────┘ Reconcile │ │ Deployment │ │ Deployment │ │
│ │ │ │ │ │ │ │
│ │ │ └─────────────┘ └─────────────┘ │
│ │ │ │
└──────────────────────────────┘ └──────────────────────────────────────────┘
Goals:
- add a context setting for the controller annotation so context can be in addition to the namespace for each reconciler individually
- add startup probe to ensure all desired context are available
Activity
jmrodri commentedon Jun 30, 2022
Controller runtime had an issue about multi cluster support: kubernetes-sigs/controller-runtime#745 (comment) and a POC kubernetes-sigs/controller-runtime#950
juangon commentedon Oct 28, 2022
Wow, this would be a great feature. In my case we are using operators to provision applications and having the chance to select which cluster (maybe in other clouds) can be great
csviri commentedon Oct 31, 2022
So thinking about this issue more, the real benefits would be:
But also we have to be very careful about this, since this has a huge impact on overall architecture and the use case might target only a small subset of users. (Just think how would you model this in terms of a dependent resource? )
So I would recommend to create a prototype to see more clearly the implications, and make decision if we want to do this or not at the end.
[-] Switch context for specific reconciler (add multi cluster support) [/-][+]Multi Cluster Support[/+]csviri commentedon Nov 11, 2022
This is a very interesting argument, why actually this makes sense in general to have:
https://youtu.be/1p00SMLletY?t=1249
Although this not necessarily about the multiple clusters in one instance, but nice example how to manage resources from an other cluster and why it makes sense.
csviri commentedon Mar 14, 2023
see also: #1817
katheris commentedon Aug 13, 2024
Hey, is there any update on this feature? I work on the Strimzi Access Operator which is responsible for delivering connection details for a Kafka cluster to Kafka applications. We are looking at a usecase where you have one Kubernetes cluster hosting your Kafka cluster, and a different one hosting your Kafka applications. So the operator would only watch for CRs in a single Kubernetes cluster, but could query on Kubernetes clusters as part of the reconciliation loop.
Strimzi issue for reference.
csviri commentedon Aug 13, 2024
Hi @katheris
Having a generic multi cluster support is quite complex change. But having Informers watching different clusters might be something doable (your use case). Will create a separate issue with such scope.
see issue with limited scope here: #2493
csviri commentedon Aug 15, 2024
@katheris created the PR: #2499
that includes a sample, tbh I think this covers the original request within this issue.
csviri commentedon Aug 15, 2024
Just a side not having a controller managing primary resources (not just secondary resources as in the PR above) from multiple clusters is more complex to implement, but definitely doable. Pls let us know if that is needed.
katheris commentedon Aug 19, 2024
For our usecase we only need to manage secondary resources in a different Kubernetes cluster, the controller will be deployed in the same cluster as both the CR it is the controller for, and any primary resources it creates.
csviri commentedon Feb 17, 2025
For the record, there is now an experimental feature on top of controller runtime: https://github.com/multicluster-runtime/multicluster-runtime