Google Cloud allows changes to the networking configuration of instances. Possible permitted modifications are as follows:
- From a legacy network to a VPC network in the same project
- From one VPC network to another VPC network in the same project
- From one subnet of a VPC network to another subnet of the same network
- From a service project network to the shared network of a shared VPC host project
All those actions must be performed when the instance is powered off, and it cannot be a part of a managed instance group (MIG) or network endpoint group (NEG).
Console
After stopping the VM instance, we need to edit its configuration. In the networking section, we need to perform network adjustments, as shown in the following screenshot:
Figure 4.66 – Changing the VM instance network settings
In our case, we switched the instance to a different VPC in the same project.
Command line
The changes made through the console can also be done via the command line.
We need to stop the VM instance first:
gcloud compute instances stop INSTANCE_NAME –zone=ZONE_NAME
Once the instance is stopped, we can update its configuration:
gcloud compute instances network-interfaces update INSTANCE_NAME –zone=ZONE_NAME –network-interface=NIC –network=NETWORK_NAME –subnetwork=SUBNET_NAME
After a moment, the instance configuration is changed to the desired network.
This last activity concludes the networking-related activities. Those activities are vital to successfully managing Google Cloud and passing the ACE exam.
An MIG is a group of VM instances treated as a single entity.
There are two kinds of instance groups to choose from:
- MIGs, which allow us to use applications on identical VM instances automatically
- Unmanaged instance groups, which allow us to load balance applications across instances managed by ourselves
There are many scenarios where an MIG can be used:
- Stateful applications or batch workloads
- Stateless batch or high-performance compute workloads
- Stateless workloads such as hosting a website
The following diagram illustrates the concept of an MIG with a Load Balancer:
Figure 4.67 – A simplified view of Load Balancing with an MIG
The previous diagram shows simplified load balancing where an MIG receives network traffic from the Internet
There are several advantages of using MIGs:
- High availability: An MIG supports regional/multi-zone deployment. If there is zone failure, the application can still be served from the unaffected zone. One essential aspect is the load-balancing option for the application. Various load-balancing options with Cloud Load Balancing are supported with MIGs.
- Scalability: An MIG supports automatic scaling based on various metrics, so you no longer need to add servers manually. When the load on the servers is increased, more instances are added. When the load decreases, instances are automatically deleted.
- Automated patching: Whenever an application or configuration is changed, we have the option to update the underlying infrastructure. This allows for faster application shipment and updates.
- Auto healing: Instances in a group are monitored, and whenever an instance crashes, stops responding, or is deleted, it will be automatically replaced by a new instance from the template. Various health checks are available in the MIG and can be combined with Cloud Load Balancing health checks.
If your application or workload is stateless, you can benefit from using preemptible/spot instance VMs and lower your bill significantly.