Skip to content

Submariner

In the context of Kubernetes, Submariner is an open-source tool that enables direct network connectivity between Pods and Services in different Kubernetes clusters.

Think of it as a way to create a “flat” network across multiple, geographically distributed, or logically separated Kubernetes clusters, making them behave as if they were part of one larger, unified network.

Submariner extends the Kubernetes networking model beyond the boundaries of a single cluster, enabling seamless and secure communication for multi-cluster applications and architectures.

Here’s a breakdown of what it does and why it’s useful:

  1. Use Cases:

    • Application High Availability & Disaster Recovery: Deploying application instances across multiple clusters in different regions/zones for resilience.
    • Geo-Distributed Applications: Spreading microservices across clusters to be closer to users or data sources.
    • Hybrid Cloud: Connecting on-premises Kubernetes clusters with clusters in public clouds.
    • Centralized Services: Hosting shared services (e.g., monitoring, logging, databases) in one cluster and making them accessible to applications in other clusters.
    • Data Sovereignty: Keeping data within specific geographical boundaries while allowing controlled access from applications in other clusters.

  2. Problem Solved:

    • By default, Kubernetes clusters are isolated network environments. Pods in cluster A cannot directly reach Pods or Services (by their ClusterIP) in cluster B using their native IP addresses.
    • This isolation makes it challenging to build applications that span multiple clusters for reasons like high availability, disaster recovery, data locality, or hybrid cloud deployments.

  3. How Submariner Works (High-Level):

    • Gateway Nodes: Each participating cluster designates one or more nodes as “gateway” nodes.
    • Secure Tunnels: Submariner establishes secure, encrypted tunnels (commonly using IPsec, WireGuard, or VXLAN over IPsec) between the gateway nodes of different clusters.
    • Route Advertisement: It synchronizes network routing information (Pod and Service CIDR blocks) across these connected clusters. This means a Pod in cluster A knows how to route traffic destined for a Pod or Service in cluster B through the appropriate tunnel.
    • Service Discovery (Lighthouse): Beyond just network connectivity, Submariner includes a component called “Lighthouse” that enables multi-cluster service discovery. It exports services from one cluster and makes them discoverable (e.g., via DNS using a .clusterset.local suffix) in other connected clusters. This allows applications to consume services from remote clusters as if they were local.
    • Broker: A central component (which can run in a dedicated cluster or one of the managed clusters) that facilitates the discovery of gateway endpoints and cluster information. The broker is not in the data path; it’s only used for control plane coordination.

  4. Key Features & Benefits:

    • Direct Pod-to-Pod & Pod-to-Service Communication: Applications can communicate across cluster boundaries using standard IP routing and service DNS names.
    • Flat Networking: Simplifies multi-cluster application architecture.
    • Security: Communication between clusters is typically encrypted.
    • CNI Agnostic: Designed to work with various Container Network Interfaces (CNIs).
    • Handles Overlapping CIDRs (with Globalnet): If clusters have overlapping Pod/Service IP address ranges (a common issue), Submariner’s “Globalnet” feature can map these to a non-overlapping global CIDR space, enabling connectivity.
    • High Availability: Can be configured with multiple gateway nodes per cluster for redundancy.
    • Service Discovery: Makes it easy for applications to find and use services in remote clusters.

Page last modified: 2025-05-29 16:09:02