Introducing Multicluster-Controller
Tags: kubernetes, opensource, devops, showdev
Published: 2018-10-30 14:11:39

---
title: Introducing Multicluster-Controller
published: true
description: A Library for Building Hybrid and Multicloud Kubernetes Operators
tags: kubernetes,opensource,devops,showdev
canonical_url: https://admiralty.io/blog/introducing-multicluster-controller/
cover_image: https://thepracticaldev.s3.amazonaws.com/i/ubk8mwr85vhr66raal86.jpg
---

[_Originally published in Admiralty's blog._](https://admiralty.io/blog/introducing-multicluster-controller/)

Hybrid and multicloud architectures are becoming prevalent, either as a [strategy](https://thenewstack.io/why-enterprises-are-adopting-a-multicloud-strategy/) or simply as a result of [history and/or mergers and acquisitions](https://www.reddit.com/r/devops/comments/91afzz/why_multicloud/e2x156y/). Luckily, to help reduce the inherent complexity, Kubernetes is standardizing the way clouds are operated: the same workflow can be used to manage resources in any cloud, whether public or private. However, managing workloads _across_ clouds is still a challenge. Technically, you _could_ create a single Kubernetes cluster encompassing your entire infrastructure, but that could invalidate some of the [assumptions](https://kubernetes.io/docs/concepts/cluster-administration/federation/#scope-of-a-single-cluster) made in the design of Kubernetes itself. Also, you would miss out on [turn-key Kubernetes distributions](https://kubernetes.io/docs/setup/pick-right-solution/). A more common approach is to operate multiple clusters.

Clusters are isolated from each other by default, which helps with:
- fault isolation;
- trust boundaries;
- only paying for a top-tier service level in production;
- enforcing geographical regulations;
- etc.

However, cluster boundaries get in the way when you'd like to manage the following globally:
- scheduling and autoscaling (ensuring high availability and low latency at the lowest cost);
- service discovery;
- storage;
- monitoring;
- backups and migrations;
- policy enforcement;
- etc.

We need tools to manage resources across clusters. Specific solutions exist. Notably, [federation-v2](https://github.com/kubernetes-sigs/federation-v2) can sync workloads and route traffic across clusters. To do so, it uses the concepts of Templates, Placements, and Overrides, propagating resources with a push reconciler.

While building a multicluster scheduler at [Admiralty (stay tuned)](https://admiralty.io), we needed a lower-level abstraction: namely the controller pattern (sometimes called the operator pattern), but for resources in multiple clusters. We needed a tool like the [Operator SDK](https://github.com/operator-framework/operator-sdk) or [Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) (see [comparison in a previous blog post](https://admiralty.io/blog/kubernetes-custom-resource-controller-and-operator-development-tools/)), but supporting multiple clusters. Unfortunately, their designs don't allow that. Their APIs would have to change significantly. So, rather than submit a pull request, we decided to make our own tool. Luckily, we were able to leverage parts of [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime), the library powering Kubebuilder and now also the Operator SDK.

**Today, we're open-sourcing [multicluster-controller](https://github.com/admiraltyio/multicluster-controller).** Check out the README for more details on how it works, including how it can be used with custom resources (using CRDs). We've also included a few examples. We hope that the community will find the project useful. (Anyone volunteering to build a multicluster Prometheus operator?)

{% github admiraltyio/multicluster-controller %}

_Warning:_ though we're already using multicluster-controller internally with great success, the project is still in its infancy and the API may break in future releases. Also, a few must-have features are still in the works:
- cross-cluster [garbage collection](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/);
- integration with [cluster-registry](https://github.com/kubernetes/cluster-registry);
- service accounts and RBAC generators;
- validating and mutating [webhooks](https://book.kubebuilder.io/beyond_basics/what_is_a_webhook.html);
- [leader election](https://godoc.org/k8s.io/client-go/tools/leaderelection);
- more tests.

[Contributions](https://github.com/admiraltyio/multicluster-controller/blob/master/CONTRIBUTING.md), [feature requests and bug reports](https://github.com/admiraltyio/multicluster-controller/issues) are welcome.

## Acknowledgements

Many thanks to all the Kubernetes authors, especially those of [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime/graphs/contributors), [apimachinery](https://github.com/kubernetes/apimachinery/graphs/contributors), and [client-go](https://github.com/kubernetes/client-go/graphs/contributors).