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:

Install Admiralty in each cluster that you want to federate. Configure clusters as sources and/or targets to build a centralized or decentralized topology.
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="".
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).
Pod dependencies (config maps and secrets) and dependents (services and ingresses) "follow" delegate pods, i.e., they are copied as needed to target clusters.
A feedback loop updates the statuses and annotations of the proxy pods to reflect the statuses and annotations of the delegate pods.
kubectl logs and kubectl exec work as expected.
Integrate with Admiralty Cloud/Enterprise, Cilium and other third-party solutions to enable north-south and east-west networking across clusters.

Open Source and Admiralty Cloud/Enterprise

This documentation covers both the Admiralty open source cluster agent and Admiralty Cloud/Enterprise. Features only available with Admiralty Cloud/Enterprise are clearly marked; in that case, as much as possible, open source and commercial third-party alternatives are discussed.