Declaring Remote Pod CIDRs with Static Routes

Declaring Remote Pod CIDRs with Static Routes An architecture diagram generated by Archify. Hybrid node 10.80.0.2 · Pod CIDR 10.85.1.0/24 · CNI · Remote Node CIDR 10.80.0.0/16 · Remote Pod CIDR 10.85.0.0/16 Hybrid node 10.80.0.2 Pod CIDR 10.85.1.0/24 · CNI Hybrid node 10.80.0.3 · Pod CIDR 10.85.2.0/24 · CNI · Remote Node CIDR 10.80.0.0/16 · Remote Pod CIDR 10.85.0.0/16 Hybrid node 10.80.0.3 Pod CIDR 10.85.2.0/24 · CNI On-prem router · Routing table · Architecture component On-prem router Routing table Gateway · On-prem ↔ AWS link · VPC 10.0.0.0/16 · Architecture component Gateway On-prem ↔ AWS link · VPC 10.0.0.0/16 10.85.1.0/24 static 10.85.2.0/24 static 10.0.0.0/16 static Remote Node CIDR 10.80.0.0/16 · Remote Pod CIDR 10.85.0.0/16 Legend Backend Cloud

Static route setup

  • • You register each pod CIDR and its next hop (the node IP) on the router by hand
  • • 10.85.1.0/24 points at 10.80.0.2 and 10.85.2.0/24 at 10.80.0.3
  • • Every new node means another entry on the router

Router routing table

  • • 10.80.0.0/16 [local] via eth0 (CONNECTED)
  • • 10.0.0.0/16 [static] via Gateway (STATIC)
  • • 10.85.1.0/24 [static] via 10.80.0.2 (STATIC)
  • • 10.85.2.0/24 [static] via 10.80.0.3 (STATIC)

When to use it

  • • With few, stable nodes it is the simplest and most predictable option
  • • It is the realistic choice when the network gear cannot run BGP
  • • Routes do not fail over on their own, so you need an operational procedure