GCP ByoVPC

Bring your own VPC

Prerequisites

Must be an Enterprise Customer.

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 to provide plenty of room for future expansion (256 hosts max). Allocating a /22 allows room for expansion to support all future use cases. We recommend against allocating less than a /27 for your nodes because it restricts room for expansion.
• The subnet must have a secondary IP range for pods that is 256 times larger than the node IP range (so for a /24 node IP range, the pod IP range would be /16). This is required because GKE uses 256 IPs per node. Ascend configures GKE to support up to 110 pods per node.
• 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). You do not need to allocate a subnet for this in your VPC, Ascend only needs this information for configuration purposes.

Shared VPC

📘

Shared VPC Terminology

In the Shared VPC details below, we are using GCP's terminology for referencing the relevant resources. The most relevant distinction is:

• Client Project - This is the project that Ascend is installed into.
• Host Project - This is the project where the Shared VPC lives.

Find Service Account Names

1. In order to calculate the Service Account names for the internal GCP Service Accounts, you need to first find the Client Project number. To find that, expand the left navigation bar and click on Cloud overview > Dashboard

2. In the Project Info card you will find the Project number. This value will be referred to in the instructions as CLIENT_PROJECT_NUMBER.

Requirements

• In addition to the standard information we need for install, for Shared VPC installation we also need the name of the Shared VPC host project.
• Service Networking API must be enabled on the Shared VPC host project.
• [email protected] must be granted Compute Network User in the Host Project.
• The GKE Service Account from the Client Project must be granted Compute Network User, Compute Security Admin, and Kubernetes Engine Host Service Agent User in the Host Project. The service account name is service-CLIENT_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.
• The Google APIs Service Account from the Client Project must be granted Compute Network User in the Host Project. The Service Account naame is [email protected].

📘

Limited Permissions

If you're concerned with the permission set in Compute Security Admin, for the GKE service account, you may construct a custom IAM Role containing the following permissions as described here:

• compute.networks.updatePolicy
• compute.firewalls.list
• compute.firewalls.get
• compute.firewalls.create
• compute.firewalls.update
• compute.firewalls.delete

If there are any questions regarding the security profile or other details of a Shared VPC setup with GKE, please reference GCP's documentation here.

Connecting to Private Networks

VPC Peering

Summary

To connect Ascend to your private networks, add a peering connection from the Ascend VPC to the network containing your data stores 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 creating a VPC peering connection with overlapping IP ranges isn't possible.

VPN Tunneling

Summary

GCP VPN configuration is more complex 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. This allows you greater capacity in your Ascend network with a 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 complex, susceptible to misconfiguration, 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 the 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

Shared VPC info for install

• shared_vpc_project_name

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