Multi Cluster Support

[bs-matil]

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

[jmrodri]

Controller runtime had an issue about multi cluster support: kubernetes-sigs/controller-runtime#745 (comment) and a POC kubernetes-sigs/controller-runtime#950

[juangon]

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]

So thinking about this issue more, the real benefits would be:

1. Have a out of the box access/experinece to other clusters and able to register informers that will trigger the reconciliation regarding a custom resource on a different cluster.
2. Manage resources on different clusters in a sense that reconciler is able to make decision based on a global state (taking in mind resources on multiple clusters)

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.

[csviri]

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.