Submariner consists of several main components that work in conjunction to securely connect workloads across multiple Kubernetes clusters. For more information about Submariner’s architecture, please refer to the Architecture section.
The Broker is an API to which all participating clusters are given access to, and where two objects are exchanged via CRDs:
The Broker must be deployed on a single Kubernetes cluster. This cluster’s API server must be reachable by all Kubernetes clusters connected by Submariner. It can be a dedicated cluster, or one of the connected clusters.
Once Submariner is deployed on a cluster with the proper credentials to the Broker it will exchange Cluster and Endpoint objects with other clusters (via push/pull/watching), and start forming connections and routes to other clusters.
Submariner has a few requirements to get started:
An example of three clusters configured to use with Submariner (without Globalnet) would look like the following:
|Cluster Name||Provider||Pod CIDR||Service CIDR||Cluster Nodes CIDR|
Submariner is designed to be cloud provider agnostic, and should run in any standard Kubernetes cluster. Presently, Submariner has been tested with the following network (CNI) Plugins that leverage kube-proxy with iptables mode:
The available methods for deployment are:
subctl greatly simplifies the deployment of Submariner, and is therefore the recommended deployment