[DEPRECATED DOC]

Bring your own VPC

Pre-Requisites

Only available to Enterprise Customers

Requirements

  • All Subnets require unrestricted egress access to 0.0.0.0/0
  • Subnet must have private ip google access enabled
  • Primary IP range of the subnet defines the number of nodes you can have - we recommend allocating a /24 for nodes in order to provide plenty of room for future expansion (256 hosts max). Allocating a /22 gives plenty of room for expanding to support all future use cases. We recommend against allocating less than a /27 for your nodes because it gives very little room for expansion.
    GKE uses 256 IPs per node (Ascend configures GKE to support up to 110 pods per node), so the subnet must have a secondary IP range for pods 256 times larger than the node IP range (so for a /24 node IP range, the pod IP range would be /16).
  • The subnet must have a /24 secondary IP range for services.
  • You must identify a /28 IP range for the GKE control plane (this will be allocated by Ascend when your environment is provisioned).

Connecting to Private Networks

VPC Peering

Summary

This is the simplest way to connect Ascend to your Private networks, you simply add a peering connection from the Ascend VPC to whatever network contains your data stores that you want to access with Ascend, or to a transit VPC.

Limitations

The node, pod, service, and gke control plane IP ranges must not overlap with any other peered IP ranges. VPC Peering in GCP only supports full mesh routing, so it is not possible to create a VPC peering connection with overlapping IP ranges.

VPN Tunneling

Summary

GCP VPN configuration is more complicated than VPC Peering, but it gives you the ability to limit what IP ranges are shared as routable with the rest of your private network. Specifically, you only need to propagate routes for the node IP range, which allows you much greater capacity in your Ascend network with a much lower impact on consumption of your private IP space.
We recommend reading through GCP's documentation on HA VPN topologies and their documentation on NAT solutions for pod CIDR ranges in GKE.
We support any of these VPN solutions (VPN tunnels to a transit VPC, VPN tunnels directly to an on-prem network, etc).

Limitations

VPN setups are more complicated, more likely to be misconfigured, and harder to debug than VPC peering setups. If you have sufficient IP capacity in your network we recommend using the VPC peering setup.

Requirements

In both VPN and VPC Peering setups, there may not be any overlap between the IP ranges you provision for Ascend and the IPs of the data stores that you wish to access from Ascend. Additionally, traffic must be permitted from the node IP range to whatever data stores you wish to access from Ascend.

Info for install

  • network_name
  • subnetwork_name
  • pod_secondary_range_name
  • services_secondary_range_name
  • gke_control_plane_cidr

VPN-specific info for install

router_name (router is required in VPN setup for BGP announcements and the actual tunnels)

Table of valid subnet ranges

Max DFCs | ~500 | ~1k | ~2k | ~4k | ~8k | ~16k |
Nodes | /24 | /23 | /22 | /21 | /20 | /19 |
Pods | /16 | /15 | /14 | /13 | /12 | /11 |
Services | /24 | /24 | /24 | /24 | /24 | /24 |
Control Plane | /28 | /28 | /28 | /28 | /28 | /28 |