Multi-Region Kubernetes Clusters
A step-by-step guide to running two Kubernetes clusters in two regions behind a single environment. You'll provision a cluster in each region, attach both to one environment, and let SeaGit route each visitor to the nearest region with latency-based DNS — for high availability and lower global latency.
What You'll Build
Region A — us-east-1:
- ✓ Dedicated VPC (10.0.0.0/16)
- ✓ EKS cluster (2 nodes)
- ✓ ALB + cert-manager + External DNS
Region B — eu-west-1:
- ✓ Dedicated VPC (10.1.0.0/16)
- ✓ EKS cluster (2 nodes)
- ✓ ALB + cert-manager + External DNS
One environment routing to both clusters (latency-based)
Estimated time: ~45 minutes (most of it EKS provisioning, which runs in parallel across both regions)
Prerequisites
- A connected cloud provider — see Providers. The two clusters can share one provider or use two different accounts.
- A domain managed by SeaGit for automatic DNS and TLS — see DNS & Domains.
- A completed single-region setup helps — if this is your first cluster, start with the Getting Started guide first.
Plan note:
Cross-region routing policies (Latency-based, Failover) are available on paid plans. You can still create clusters in multiple regions on any plan — the paid feature is the managed multi-region routing.
Step 1: Create a VPC in Region A
A network (VPC) is region-scoped, so each region needs its own. Go to Networks → Create Network.
- Name:
vpc-us-east-1 - Region:
us-east-1 - CIDR Block:
10.0.0.0/16 - Availability Zones: 2 (for high availability)
- Public + Private Subnets: Yes
Use a distinct CIDR per region so the two VPCs never overlap. See Networks for details.
✓ Step complete
Region A VPC ready.
Step 2: Provision the Cluster in Region A
Go to Clusters → Create Cluster and place it in the Region A VPC.
- Name:
cluster-us-east-1 - Network:
vpc-us-east-1 - Kubernetes Version: latest stable
- Node Group:
t3.medium, min 2 / max 5
Install these add-ons (required for managed DNS + TLS):
- ☑ ALB Controller
- ☑ Cert-Manager — per-cluster TLS certificates
- ☑ External DNS — writes the region-aware DNS records
- ☑ Metrics Server
EKS provisioning takes ~15-20 minutes. Start Step 3 while it runs.
✓ Step complete
Region A cluster provisioning.
Step 3: Create a VPC in Region B
Repeat Step 1 for your second region. Back in Networks → Create Network:
- Name:
vpc-eu-west-1 - Region:
eu-west-1 - CIDR Block:
10.1.0.0/16(non-overlapping) - Availability Zones: 2
✓ Step complete
Region B VPC ready.
Step 4: Provision the Cluster in Region B
Repeat Step 2, placing the cluster in the Region B VPC and selecting the same add-ons so both regions behave identically.
- Name:
cluster-eu-west-1 - Network:
vpc-eu-west-1 - Add-ons: ALB, Cert-Manager, External DNS, Metrics Server
Wait until both clusters show Ready before continuing.
✓ Step complete
Both regional clusters are Ready.
Step 5: Create an Environment and Attach Both Clusters
One environment spans both regions. Go to Environments → Create Environment.
5.1 Configure the Environment
- Name:
production-global - Root Domain:
yourdomain.com - Ingress Class:
alb - TLS: Enabled (auto-issue certificates)
5.2 Attach Both Clusters
In Attach Clusters, select both cluster-us-east-1 and cluster-eu-west-1. This is what makes the environment multi-region: every deployment to it rolls out to both clusters. See Environments.
✓ Step complete
One environment now spans both regional clusters.
Step 6: Set the Routing Policy
The routing policy decides how visitors are steered across the two regions. Under the environment's DNS / Routing settings:
- Latency-based (recommended) — each visitor is routed to the region with the lowest latency for them. This is the default choice for global, active-active traffic.
- Failover — one region serves all traffic; the other is a warm standby that takes over only if the primary becomes unhealthy.
- Simple — a single destination (not recommended for multi-region).
How it works: SeaGit uses each cluster's External DNS add-on to publish region-aware records for the same hostname, and cert-manager issues a valid certificate in each region — so app.yourdomain.com resolves to whichever cluster is nearest and healthy. Routing policies require a paid plan.
✓ Step complete
Traffic now steers to the nearest healthy region.
Step 7: Verify DNS & TLS
Confirm both regions answer for your hostname over HTTPS:
# Resolve the app hostname (should return a regional endpoint)
dig +short app.yourdomain.com
# Verify HTTPS + a valid certificate in each region
curl -sSI https://app.yourdomain.com | head -n 1If a region doesn't resolve yet, DNS propagation can take a few minutes. See Certificates & TLS and Troubleshooting if a certificate stays pending.
✓ Step complete
Both regions resolve and serve valid TLS.
Next: Deploy Your Application to This Environment
Your multi-region environment is ready. From here you deploy exactly like a single-region setup — nothing about the application changes. Create an application instance that targets the production-global environment and deploy it normally. Each deployment automatically rolls out to both attached clusters, and the environment's routing policy sends every visitor to the nearest healthy region.
👉 Follow the standard Deployments guide to create and manage instances and releases against this environment. For configuring the application template itself, see Applications.
Frequently Asked Questions
Do I need a separate network for each region?
Yes. A SeaGit network (VPC) is region-scoped, so a two-region setup needs one VPC per region. You create a VPC in each region first, then provision one EKS cluster into each VPC.
Which routing policy should I use for multi-region clusters?
Use the Latency-based policy so each visitor is routed to the region closest to them for the lowest response time. Add a Failover policy when you want one region to act as a standby that only receives traffic if the primary region becomes unhealthy. Routing policies are available on paid plans.
How does SeaGit route traffic across two regions?
When both clusters are attached to one environment and a routing policy is set, SeaGit programs region-aware DNS records (via External DNS on each cluster) and issues TLS certificates per cluster. Requests resolve to the nearest healthy region automatically — you deploy once and both regions serve the same application.
Can the two clusters live in different cloud accounts?
Yes. Each cluster can use its own provider, so the two regions can sit in different AWS accounts. SeaGit still manages cross-region DNS and per-cluster certificates from the single environment.