Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lighthouse hub-controller enhancement proposal #82

Closed
wants to merge 1 commit into from
Closed

Lighthouse hub-controller enhancement proposal #82

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions lighthouse/hub-controller.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Hub Controller for Lighthouse

## Summary

The current Lighthouse implementation has a passive broker, it is a central apiserver that is
accessed by each cluster in the clusterset. Clusters synchronise resources to and from the
broker with all sync and reconciliation logic implemented in the clusters.

There are feature gaps that would be much easier to address if we introduce an active broker
that can implement reconciliation logic.
Comment on lines +5 to +10
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Passive broker is part of the broader Submariner architecture which emphasizes distributed clusters where each cluster is autonomous, and the broker is simply some mechanism to disseminate the data which is very simple (could've been a simple etcd service and not K8s API).

If we're going to change that, then it should be discussed on a higher level architecturally and not just in the context of Lighthouse.


- `ServiceExport` conflict resolution, per the MCS KEP [^1]
- Merging exported `Services` into single `ServiceImport`

Benefits of central reconciliation in an active broker include:

- Single consistent model of intended state, rather than models computed per cluster
- Target state computed _before_ it gets synced out to clusters
- Synchronise fewer resources from broker to each cluster

## Proposal

This enhancement proposes to add an mcs-controller to the broker that will implement the
reconciliation logic from `ServiceExport` to `ServiceImport` resources. This will result in a
clear separation of logic for MCS resources:

- Clusters will sync resources to and from the broker
- The mcs-controller on the broker will reconcile `ServiceImport` object state from the
provided `ServiceExport` state.

Once an mcs-controller has been introduced, the reconciliation logic will be extended to address
the following open issues:

- Mark conflicting `ServiceExport` objects with the `ServiceExportConflict` condition
- Merge matching `ServiceExport` objects into a single `ServiceImport` object

The resulting solution is expected to be less complex overall, ready to be more conformant to
the MCS KEP and to provide opportunity for minimising the data synchronisation between clusters.

[^1]: [KEP-1645: Multi-Cluster Services API](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api#constraints-and-conflict-resolution)