Virtual Network

An Azure Virtual Network is the private address space that AKS nodes, VMs and databases share. The Provision screen has no standalone network option. ZopDay builds the VNet as one step of the cluster, VM or database job that needs it. The ZopDay API also offers a network-only job type, vpc, that runs just that step.

What does ZopDay create: one VNet and one subnet

VNet: named after the job (a job called shop gets shop-vnet)
Address range: 10.0.0.0/16
Subnet: shop-nodes, the first /20 of the range (10.0.0.0/20 on the default)
Tags: provisioner: zopdev, cluster-name: shop
Resource group: the one you named or picked, or zop-shop; created if missing

The VNet and its subnet are created in one Azure call. Nothing else is created in this step: no network security group, NAT gateway, public IP or route table.

Why is the address range field ignored on the Provision screen

Advanced settings shows a Network address range (CIDR) field prefilled with 10.0.0.0/16. The Provision screen does not send it with the job, so every VNet created from the screen uses 10.0.0.0/16. If you create the job through the ZopDay API, ZopDay does use the address range you send. On another range, the subnet is the /20 that starts at the range’s base address.

What do later steps add to the VNet

An AKS cluster puts its node pool in the nodes subnet, such as shop-nodes. It uses Azure CNI with Calico network policy, so pods take addresses from that same subnet as the nodes. Kubernetes services use 172.16.0.0/16, outside the VNet. A MySQL or PostgreSQL job adds its own delegated /24 subnet, named after the database (a database called orders gets orders-db-subnet). Its third octet falls between 16 and 255. VM jobs create their own network security groups. None of these appear in the network step. So a VNet that is otherwise empty right after it is created is expected.

How do you bring your own VNet

Choose Use existing VPC on the Provision screen and ZopDay creates no network. It lists the VNet’s subnets and places the workload in them. The job stops with an error if the VNet has no subnet yet, so create at least one first. ZopDay never deletes a VNet you brought.

How does peering work when a database sits in another VNet

When you connect a database to a cluster in a different VNet, the connection job peers the two VNets in both directions. It also links the database’s private DNS zone to the cluster’s VNet. Both VNets must be in the same subscription. Azure does not peer VNets whose address ranges overlap. Every VNet created from the Provision screen uses 10.0.0.0/16, so two VNets that ZopDay created separately will collide. Placing the database in the cluster’s own VNet avoids peering altogether. The ZopDay API allows this when you create the database and name the cluster’s job. The Provision screen does not offer it.

What happens to the VNet when the job is deleted

When ZopDay created the resource group, deleting the job deletes that resource group. That removes the VNet with everything else in it. When you picked an existing resource group, ZopDay deletes only the VNet it created and leaves the resource group and its other resources alone.