Cloud-native networking (VPC, peering, firewalls, container networking)
In this we will understand about cloud-native networking (VPC, peering, firewalls, container networking).
VPC network overview
A Virtual Private Cloud (VPC) network is a virtual version of a physical network, implemented inside of Google’s production network, using Andromeda. A VPC network provides the following:
- Firstly, provides connectivity for your Compute Engine virtual machine (VM) instances, including Google Kubernetes Engine (GKE) clusters and App Engine flexible environment instances.
- Secondly, offers native Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
- Thirdly, connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
- Lastly, distributes traffic from Google Cloud external load balancers to backends.
VPC networks have the following properties:
- Firstly, VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone.
- Secondly, subnets are regional resources. Each subnet defines a range of IP addresses.
- Thirdly, traffic to and from instances can be controlled with network firewall rules. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
- Fourthly, resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
- Next, instances with internal IP addresses can communicate with Google APIs and services.
- Then, network administration can be secured by using Identity and Access Management (IAM) roles.
- After that, VPC networks can be connected to other VPC networks in different projects or organizations by using VPC Network Peering.
- Lastly, VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network.
Routes and firewall rules
Routes
They define paths for packets leaving instances (egress traffic). Routes in Google Cloud are divided into two categories: system-generated and custom. However, every new network starts with two types of system-generated routes:
- Firstly, the default route defines a path for traffic to leave the VPC network. It provides general internet access to VMs that meet the internet access requirements. It also provides the typical path for Private Google Access.
- Secondly, a subnet route is created for each of the IP ranges associated with a subnet. Every subnet has at least one subnet route for its primary IP range. Additional subnet routes are created for a subnet if you add secondary IP ranges to it.
Dynamic routing mode
Each VPC network has an associated dynamic routing mode that controls the behavior of all of its Cloud Routers. Cloud Routers share routes to your VPC network and learn custom dynamic routes from connected networks when you connect your VPC network to another network. However, this is by using a Cloud VPN tunnel that uses dynamic routing, or by using Dedicated Interconnect or Partner Interconnect.
- Firstly, Regional dynamic routing is the default. In this mode, routes to on-premises resources learned by a given Cloud Router in the VPC network only apply to the subnets in the same region as the Cloud Router.
- Secondly, Global dynamic routing changes the behavior of all Cloud Routers in the network such that the routes to on-premises resources that they learn are available in all subnets in the VPC network, regardless of region.
Firewall rules
Firewall rules apply to both outgoing (egress) and incoming (ingress) traffic in the network. They also control traffic even if it is entirely within the network, including communication among VM instances. However, every VPC network has two implied firewall rules. One implied rule allows most egress traffic, and the other denies all ingress traffic. You cannot delete the implied rules, but you can override them with your own. Google Cloud always blocks some traffic, regardless of firewall rules; for more information, see blocked traffic.
Maximum transmission unit
VPC networks have a default maximum transmission unit (MTU) of 1460 bytes. However, you can configure your VPC networks to have an MTU of 1500 bytes.
The MTU is the size, in bytes, of the largest packet supported by a network layer protocol, including both headers and data. In Google Cloud, you set the MTU for each VPC network, and VM instances that use that network must also be configured to use that MTU for their interfaces. Further, the network’s MTU setting is communicated to a VM when that VM requests an IP address using DHCP. DHCP Option 26 contains the network’s MTU.
The MTU impacts both UDP and TCP traffic:
- Firstly, if a UDP packet is sent that is larger than the destination can receive or that exceeds the MTU on some network link on the path to the destination, then the packet is dropped if the Don’t-Fragment flag is set. When it gets dropped, an ICMP packet of the type Fragmentation-Needed is sent back to the sender.
- Secondly, if a UDP packet is sent that is larger than the destination can receive or that exceeds the MTU on some network link towards the destination. Then, it is (generally) fragmented if the Don’t-Fragment flag is not set. This fragmentation is done where a mismatch is detected: this could be at an intermediate router or even at the sender itself if a packet is sent that is larger than the MTU.
- Lastly, TCP negotiates the maximum segment size (MSS) during connection setup time. Packets are then segmented into the smaller MTU size of both endpoints of the connection.
Migrating services to a different MTU network
You might decide to migrate your services to new VMs in a new network rather than changing the MTU of your existing network. In such a case, you might have a server, such as a database server, that needs to be accessible to all VMs during the migration. If so, the following general approach might help you migrate cleanly:
- Firstly, create the new network with the new MTU.
- Secondly, create any necessary firewall rules and routes in the new network.
- Thirdly, create a VM with multiple network interfaces in the old network. One interface connects to the new network using the new MTU and the other connects to the old network using the old MTU.
- Fourthly, configure this new VM as a secondary server for the existing one.
- Next, fail the primary server over to the secondary one.
- Either Migrate VMs to the new network or create new VMs in the new network. However, if you create new VMs. Then, you can create them from scratch, from an existing image, or by creating a snapshot of the existing VMs and using that to populate the new persistent disks.
- After that, configure these VMs to use the operational server in that network. And, migrate traffic to the new VMs.
- Then, if you intend to delete the old network, create a new server in the new network, get it in sync with the existing server, and fail over to it.
- Lastly, delete the old server and old network.
Reference: Google Documentation