<!-- END doctoc generated TOC please keep comment here to allow auto update -->
Submariner is a tool built to connect overlay networks of different Kubernetes clusters.
Submariner is designed to be network plugin (CNI) agnostic and supports both encrypted and
non-encrypted tunnels between the connected clusters.
Note that Submariner is in an early stage, and while we welcome usage and experimentation, it is quite possible that you could run into
bugs.
Submariner is a Cloud Native Computing Foundation sandbox project.
The network path of Submariner varies depending on the origin/destination of the IP traffic. In all cases, traffic between two clusters will
transit between the leader elected (in each cluster) gateway nodes, through the configured cable driver.
When the source Pod is on a worker node that is not the elected gateway node, the traffic destined for the remote cluster will transit
through the submariner VXLAN tunnel (vx-submariner) to the local cluster gateway node.
On the gateway node, traffic is forwarded to the remote cluster over the configured tunnel.
Once the traffic reaches the destination gateway node, it is routed in one of two ways,
depending on the destination CIDR. If the destination CIDR is a Pod network, the traffic is routed via CNI-programmed network. If the
destination CIDR is a Service network, then traffic is routed through the facility configured via kube-proxy on the destination gateway
node.
Submariner is always deployed using a Go-based Kubernetes custom controller, called an
Operator, that provides API-based installation and management. Deployment tools like
the subctl command line utility and Helm charts wrap the Operator. The recommended deployment method is subctl, as it is currently the
default in CI and provides diagnostic features.