You can create and manage groups of virtual machine (VM) instances so that you don't have to individually control each instance in your project. Compute Engine offers two different types of instance groups: managed and unmanaged instance groups.
Managed instance groups
A managed instance group uses an instance template to create identical instances. You control a managed instance group as a single entity. If you wanted to make changes to instances that are part of a managed instance group, you would apply the change to the whole instance group. Because managed instance groups contain identical instances, they also offer the following features over unmanaged instance groups:
- When your applications require additional compute resources, managed instance groups can automatically scale the number of instances in the group.
- Managed instance groups work with load balancing services to distribute network traffic to all of the instances in the group.
- If an instance in the group stops, crashes, or is deleted by an action other than the instance groups commands, the managed instance group automatically recreates the instance so it can resume its processing tasks. The recreated instance uses the same name and the same instance template as the previous instance, even if the group references a different instance template.
- Managed instance groups can automatically identify and recreate unhealthy instances in a group to ensure that all of the instances are running optimally.
You can create a zonal managed instance group, which contains instances from the same zone, or regional managed instance groups, which contains instances from multiple zones across the same region.
To learn how to create a zonal instance group, read Creating a Managed Instance Group.
To learn how to create a regional managed instance group, read Distributing Instances using Regional Managed Instance Groups.
Managed instance groups and the network
By default, instances in the group will be placed in the
default network and
randomly assigned IP addresses from the regional range.
Alternatively, you can restrict the IP range of the group by creating a
custom subnet network and custom
subnet that uses a smaller IP range, then specifying this subnet in the instance
template. This can simplify the creation of firewall rules.
After you create a managed instance group, the new instances start in the group as soon as the system can provision them. This process can take a significant amount of time depending on the number of instances in the group. Verify the status of instances in your managed instance group.
Zonal versus managed regional instance groups
It is possible to create a managed instance group with only instances from a single zone, or you can create a regional managed instance group, which contains instances spread across multiple zones in a single region.
When designing a robust application, Google recommends using regional managed instance groups so that your application can handle extreme scenarios such as a single zone failure. However, configuring a regional managed instance group can take more work than an instance group in a single zone, so you could start by creating managed instance groups in zones and gradually grow your application until you require a more robust solution, at which time you should transition to regional managed instance groups.
Instance templates define the machine type, image, zone, and other instance properties for the instances in a managed instance group. Each managed instance group has a single instance template that it uses to create or update the instances that are part of the group. You can create an instance template once and reuse it for multiple API requests, groups, and configurations.
An instance template is a global resource that is not bound to a zone or a
region. However, you can still specify some zonal resources in an instance
template, which restricts the template to the zone where that resource resides.
For example, if you include a read-only persistent disk from
your instance template, you cannot use that template in any other zone because
that specific disk exists only in zone
us-central1-b. For more information
about zonal resources, read Regions and Zones.
To learn how to create an instance template, read Creating Instance Templates.
Unmanaged instance groups
Unmanaged instance groups are groups of dissimilar instances that you can arbitrarily add and remove from the group. Unmanaged instance groups do not offer autoscaling, rolling update support, or the use of instance templates so Google recommends creating managed instance groups whenever possible. Use unmanaged instance groups only if you need to apply load balancing to your pre-existing configurations or to groups of dissimilar instances.
If you must create a group of dissimilar instances that do not follow an instance template, see Unmanaged Instance Groups.
Instance groups and load balancing
All of the load balancing configurations available on Google Cloud Platform require that you specify instance groups or target pools that can serve traffic distributed from the load balancer.
For HTTP(S), internal, and SSL load balancing, you must assign an instance group to a backend service. A backend service is a centralized service for managing backends, which in turn manages instances that handle user requests for your load balancer. Each backend service contains one or more backends, and each backend contains one instance group. The backend service knows which instances it can use, how much traffic they can handle, and how much traffic they are currently handling. You can assign either a managed or unmanaged instance group to a backend service.
For network load balancing, you must add individual VM instances to a target pool or assign one or more managed instance groups to a target pool, which causes the server to add all instances that are part of the instance group to the specified target pool.
For more information on different load balancing configurations, see the respective documentation:
Managed instance groups and autoscaling
Managed instance groups support autoscaling so you can dynamically add or remove instances from a managed instance group in response to increases or decreases in load. You enable autoscaling and choose an autoscaling policy to determine how you want to scale. Applicable autoscaling policies include scaling based on CPU utilization, load balancing capacity, Stackdriver monitoring metrics, or by a queue-based workload like Google Cloud Pub/Sub.
Because autoscaling requires adding and removing instances from a group, you can only use autoscaling with managed instance groups so the autoscaler can maintain identical instances. Autoscaling does not work on unmanaged instance groups, which can contain heterogeneous instances.
For more information, read Autoscaling Groups of Instances.