Understanding VPC Peering in Kubernetes

VPC peering is a fundamental networking concept that enables communication between isolated network environments. In this deep dive, we explore how KubeOVN implements VPC peering in Kubernetes, allowing you to build complex multi-VPC architectures while maintaining strong isolation guarantees.

What is VPC Peering?

VPC peering creates a logical network connection between two Virtual Private Clouds, enabling resources in different VPCs to communicate as if they were on the same network. Think of it as building a private bridge between two isolated islands.

Key Characteristics

Bidirectional: Traffic can flow in both directions once peered
Non-transitive: If VPC-A peers with VPC-B, and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C
Requires static routes: Peering alone isn't enough; you must configure routing
No overlapping CIDRs: Peered VPCs must have unique IP address spaces

How KubeOVN Implements Peering

KubeOVN leverages OVN (Open Virtual Network) logical routers to implement VPC peering. Each VPC has its own logical router, and peering creates interconnections between these routers.

The localConnectIP

One unique aspect of KubeOVN peering is the localConnectIP parameter. This is a virtual network used exclusively for the peering connection itself:

vpcPeerings:
  - remoteVpc: "vpc-b"
    localConnectIP: "192.168.100.0/24"

                Important: The localConnectIP is not assigned to any VM or pod. It's purely 
                for routing between VPC routers. Think of it as the "glue" network that connects the two VPCs.
            

Configuring VPC Peering

Setting up peering requires configuration on both sides. Let's walk through a complete example.

Scenario: Connecting Two VPCs

VPC-A: Subnet 10.1.0.0/16
VPC-B: Subnet 10.2.0.0/16

Step 1: Configure VPC-A

spec:
  vpcPeerings:
    - remoteVpc: "vpc-b"
      localConnectIP: "192.168.1.0/24"
  staticRoutes:
    - policy: "policyDst"
      cidr: "10.2.0.0/16"          # VPC-B's subnet
      nextHopIP: "192.168.1.1"     # Gateway through peering

Step 2: Configure VPC-B

spec:
  vpcPeerings:
    - remoteVpc: "vpc-a"
      localConnectIP: "192.168.2.0/24"
  staticRoutes:
    - policy: "policyDst"
      cidr: "10.1.0.0/16"          # VPC-A's subnet
      nextHopIP: "192.168.2.1"     # Gateway through peering

Common Peering Patterns

Hub-and-Spoke Topology

In enterprise environments, a hub-and-spoke model is common. A central "hub" VPC peers with multiple "spoke" VPCs, providing centralized services like logging, monitoring, or shared databases.

         spoke-1
            │
            ▼
    spoke-2 → HUB → spoke-3
            ▲
            │
         spoke-4

Note: In this model, spokes cannot communicate with each other directly. Traffic must flow through the hub, which requires additional routing configuration.

Kubernetes Integration

A powerful pattern is peering custom VPCs with the default Kubernetes cluster VPC. This allows VMs in custom VPCs to access Kubernetes services while remaining isolated from other VPCs.

vpcPeerings:
  - remoteVpc: "ovn-cluster"
    localConnectIP: "10.100.0.0/24"
staticRoutes:
  - policy: "policyDst"
    cidr: "10.54.0.0/16"       # K8s pod network
    nextHopIP: "10.100.0.1"

Troubleshooting VPC Peering

Issue: Peering Configured but No Connectivity

This is usually caused by one of these issues:

Only one side configured (peering must be bidirectional)
Incorrect nextHopIP in static routes
Overlapping CIDR ranges
Security groups blocking traffic

Verification Commands

# Check VPC peering status
kubectl ko nbctl lr-route-list vpc-a

# View OVN logical router details
kubectl ko nbctl show vpc-a

# Test connectivity from within a VM
ping

Best Practices

1. Plan IP Address Allocation

Use non-overlapping RFC 1918 private address ranges:

10.0.0.0/8 for large networks
172.16.0.0/12 for medium networks
192.168.0.0/16 for small networks

2. Document Peering Relationships

Maintain a peering map showing which VPCs are connected. This becomes crucial as your network grows.

3. Use Meaningful Peering IPs

Make localConnectIP ranges follow a pattern. For example:

# Pattern: 10.{source_vpc_id}.{dest_vpc_id}.0/24
vpc-1 → vpc-2: 10.1.2.0/24
vpc-2 → vpc-1: 10.2.1.0/24

4. Implement Security Groups

Even with peering, use security groups to control which traffic is allowed between VPCs:

ingressRules:
  - protocol: "tcp"
    portRangeMin: 443
    portRangeMax: 443
    remoteAddress: "10.2.0.0/16"  # Only from peered VPC
    policy: "allow"

Performance Considerations

VPC peering in KubeOVN introduces minimal overhead because it operates at the logical router level within OVN. Traffic stays within the same OVN cluster and doesn't need to traverse external networks.

Latency: Near-native performance, typically <1ms added latency
Throughput: Limited only by the underlying physical network
Scalability: OVN efficiently handles hundreds of peering connections

Conclusion

VPC peering in KubeOVN provides a powerful mechanism for controlled communication between isolated network environments. By understanding the peering model, configuring routes correctly, and following best practices, you can build sophisticated multi-VPC architectures that balance isolation with necessary inter-VPC communication.

Whether you're implementing a hub-and-spoke model, connecting VMs to Kubernetes services, or building a multi-tenant platform, VPC peering gives you the flexibility you need while maintaining strong security boundaries.

Kubernetes KubeOVN Networking VPC Peering OVN SDN

← Back to Blog