Introduction

Admiralty is a system of Kubernetes controllers that intelligently schedules workloads across clusters. It is simple to use and simple to integrate with other tools. It enables many multi-cluster, multi-region, multi-cloud, and hybrid (simply put, global computing) use cases:

  • high availability,
  • active-active disaster recovery,
  • dynamic content delivery networks (dCDNs),
  • distributed workflows,
  • edge computing, Internet of Things (IoT), 5G,
  • central access control and auditing,
  • blue/green cluster upgrades,
  • cluster abstraction (clusters as cattle),
  • resource federation (including global research platforms),
  • cloud bursting,
  • cloud arbitrage...

In a nutshell, here's how Admiralty works:

  1. Install Admiralty in each cluster that you want to federate. Configure clusters as sources and/or targets to build a centralized or decentralized topology.
  2. Annotate any pod or pod template (e.g., of a Deployment, Job, or Argo Workflow, among others) in any source cluster with multicluster.admiralty.io/elect="".
  3. Admiralty mutates the elected pods into proxy pods scheduled on virtual-kubelet nodes representing target clusters, and creates delegate pods in the remote clusters (actually running the containers).
  4. Pod dependencies (configmaps and secrets only, for now) "follow" delegate pods, i.e., they are copied as needed to target clusters.
  5. A feedback loop updates the statuses and annotations of the proxy pods to reflect the statuses and annotations of the delegate pods.
  6. Services that target proxy pods are rerouted to their delegates, replicated across clusters, and annotated with io.cilium/global-service=true to be load-balanced across a Cilium cluster mesh, if installed. (Other integrations are possible, e.g., with Linkerd or Istio; please tell us about your network setup.)