Last week during our tech alignment, we had an opportunity to discuss VPC peering in our new Kubernetes infrastructure. The use of peering will be consistent with the existing production infrastructure and it seemed like it would satisfy our needs.
Let’s have an open discussion on designs using peering and not using peering.
I think everyone is familiar with the concept of peering but I’ll include this AWS document just in case:
Much like the diagram on that page, we have a one to one relationship between the Kubernetes cluster VPC and a “resource” VPC which contains resources like RDS and Elasticache. Right now, we do not have multiple production clusters so we only have one cluster communicating with those resources in that one resource VPC.
Where should a shared resource, like an RDS database, exist in our network and how will network traffic be routed, monitored (I’m thinking security monitoring / flow log analysis) and restricted?
Is it appropriate to segment resource types by VPC, adding a peering connection and restricting access based on security groups?
How can you weigh in on the design?
- Share your personal experience with VPC peering
- Propose a different architectural model
- Raise concerns from a performance and availability perspective
- Raise concerns from an architecture design perspective (anti-patterns, etc.)
An additional architecture note:
Today, we have one Kubernetes cluster in one VPC (the VPC setup is part of the Terraform to create the cluster) but in the future we may have multiple clusters spread across multiple VPCs. Pods running in multiple clusters could share the same RDS database.
We reached consensus during last weeks tech alignment that VPC peering was the best way to separate concerns between cluster destruction and RDS provisioning since our RDS databases will likely be far longer lived than the clusters themselves.
Ideally, we’d like to close this issue out soon and finalize the architecture we use for deploying the database and other supporting resources.