VPC & Project Bootstrap

On Google Cloud, a workload needs a network before anything else can run. ZopDay creates one as the first step of a cluster, VM or datastore job when you choose Create new VPC. You can also create a network on its own through the ZopDay API. The Provision screen has no network-only option. ZopDay does not turn on Google Cloud APIs or grant project roles; those stay with you.

What does a new GCP network contain

Every resource is named after the job. For a job called shop:

• shop-network, a VPC in custom subnet mode.
• shop-private-subnet, a regional subnet with Private Google Access on. Cluster jobs add two extra ranges for GKE: gke-pods (10.4.0.0/14) and gke-services (10.8.0.0/20). Other jobs skip them. That keeps those ranges free when a database or cache network is peered with a cluster network.
• shop-allow-internal, a firewall rule allowing TCP, UDP and ICMP from the subnet range, 10.4.0.0/14 and 10.8.0.0/20.
• shop-router, a Cloud Router, and shop-nat, a Cloud NAT on it. The NAT gets external IPs automatically and covers all subnets and all their ranges.

The main subnet ranges must differ between peered networks too. Every network created from the Provision screen uses 10.0.0.0/16. If you plan to peer two networks, create one of them through the ZopDay API with a different range.

There is no public subnet. Outbound traffic from the private subnet leaves through Cloud NAT.

How do you choose the GCP network range

Network range     the private subnet's range; default 10.0.0.0/16 (set through the ZopDay API)
Existing network  use a network you already have instead of creating one

The Provision screen offers Create new VPC (the default) or Use existing VPC. It also shows an address-range field under Advanced settings, but the screen does not pass that value on today. So networks created from the screen use 10.0.0.0/16. To choose another range, create the network through the ZopDay API.

With an existing network, ZopDay checks that it exists and lists its subnets in the region. ZopDay creates no subnet, router or NAT there.

Private services access arrives with the first datastore

When the first Cloud SQL or Memorystore instance is created on a network, ZopDay adds private services access. This is a /16 internal range named after the network (for shop-network, google-managed-services-shop-network), reserved for VPC peering. ZopDay also adds a service networking connection to servicenetworking.googleapis.com. Later databases and caches on the same network reuse it.

Each database or cache job also adds its own firewall rule, such as shop-datastore-allow. The rule allows TCP 3306, 5432 and 6379 from 10.0.0.0/8.

ZopDay does not pick where that /16 sits. It asks for a /16 on the network and Google chooses the range. Leave room for it when you plan the network’s address range.

Which project APIs and IAM the GCP network step leaves to you

• ZopDay does not turn on APIs such as Compute Engine, Kubernetes Engine, Cloud SQL Admin or Service Networking. Turn them on in the project first.
• ZopDay does not create IAM roles or service accounts. GKE nodes use the project’s default Compute Engine service account.
• ZopDay does not set up Shared VPC, subnet flow logs or custom firewall rules.
• ZopDay does not create VPC peering as part of the network. Connecting a Memorystore instance to a cluster on another network adds a peering, and both networks must be in the same project. A Cloud SQL instance gets a Private Service Connect endpoint in the cluster’s network instead.

What does deleting a GCP network job remove

When ZopDay created the network, deleting the job that owns it removes, in this order:

1. the private services access connection and range;
2. the router and NAT;
3. every firewall rule ZopDay created on the network;
4. the subnet and the network.

ZopDay never deletes a network you brought. If a database or cache sits on a cluster’s network, that network belongs to the cluster job, and deleting the database or cache job leaves it in place.