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
- 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 execwork 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.