Bird
Raised Fist0
GCPcloud~5 mins

Managed instance groups in GCP - Commands & Configuration

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
When you want to run many copies of the same virtual machine to handle more users or tasks, managed instance groups help by automatically creating, updating, and fixing these copies for you.
When you need to run multiple identical servers to share the work of a busy website.
When you want your servers to automatically restart if they crash or become unhealthy.
When you want to update all your servers with new software without downtime.
When you want to automatically add or remove servers based on how busy your app is.
When you want Google Cloud to handle balancing traffic between your servers.
Config File - instance_group.yaml
instance_group.yaml
apiVersion: compute.googleapis.com/v1
kind: InstanceGroupManager
metadata:
  name: example-instance-group
  region: us-central1
spec:
  baseInstanceName: example-instance
  instanceTemplate: projects/my-project/global/instanceTemplates/example-template
  targetSize: 3
  autoHealingPolicies:
  - healthCheck: projects/my-project/global/healthChecks/example-health-check
    initialDelaySec: 300
  updatePolicy:
    type: PROACTIVE
    minimalAction: RESTART
    maxSurge: 1
    maxUnavailable: 1

This file defines a managed instance group named example-instance-group in the us-central1 region.

baseInstanceName sets the prefix for VM names.

instanceTemplate points to the VM setup to use for each instance.

targetSize tells how many VM copies to run.

autoHealingPolicies uses a health check to restart unhealthy VMs after 5 minutes.

updatePolicy controls how updates happen, restarting one VM at a time to avoid downtime.

Commands
This command creates a managed instance group named example-instance-group with 3 instances based on the example-template in the us-central1 region.
Terminal
gcloud compute instance-groups managed create example-instance-group --base-instance-name example-instance --size 3 --template example-template --region us-central1
Expected OutputExpected
Created [https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1/instanceGroupManagers/example-instance-group].
--base-instance-name - Sets the prefix for the names of the VM instances.
--size - Specifies how many VM instances to run.
--template - Specifies the VM template to use for instances.
This command lists all managed instance groups in the us-central1 region to verify the group was created.
Terminal
gcloud compute instance-groups managed list --region us-central1
Expected OutputExpected
NAME REGION BASE_INSTANCE_NAME SIZE example-instance-group us-central1 example-instance 3
--region - Limits the list to the specified region.
This command starts a rolling update to replace instances with a new template version example-template-v2, updating one instance at a time.
Terminal
gcloud compute instance-groups managed rolling-action start-update example-instance-group --version template=example-template-v2 --region us-central1
Expected OutputExpected
Started rolling update for instance group [example-instance-group].
--version - Specifies the new instance template version to use.
This command lists all instances in the managed instance group to check their status after the update.
Terminal
gcloud compute instance-groups managed list-instances example-instance-group --region us-central1
Expected OutputExpected
INSTANCE_NAME ZONE STATUS example-instance-abc us-central1-a RUNNING example-instance-def us-central1-b RUNNING example-instance-ghi us-central1-c RUNNING
--region - Specifies the region of the instance group.
Key Concept

If you remember nothing else from this pattern, remember: managed instance groups keep many copies of your VM running and healthy automatically.

Common Mistakes
Creating an instance group without specifying the instance template.
Without a template, the group does not know what VM setup to use, so creation fails.
Always specify a valid instance template with the --template flag when creating the group.
Not specifying the region or zone when managing regional instance groups.
Commands may fail or affect the wrong resources if the location is not specified.
Always include the --region or --zone flag matching your instance group location.
Updating all instances at once during a rolling update.
This causes downtime because all VMs restart simultaneously.
Use rolling updates with maxSurge and maxUnavailable settings to update instances one at a time.
Summary
Create a managed instance group with a VM template and desired size.
List instance groups to verify creation and status.
Use rolling updates to safely update VM instances without downtime.
List instances in the group to check their running status.

Practice

(1/5)
1. What is the main purpose of a Managed Instance Group (MIG) in Google Cloud?
easy
A. To create a single virtual machine with custom settings
B. To run multiple copies of the same virtual machine for reliability
C. To store large amounts of data in the cloud
D. To manage user access and permissions

Solution

  1. Step 1: Understand the role of Managed Instance Groups

    Managed Instance Groups run many copies of the same VM to keep applications reliable and available.
  2. Step 2: Compare options with this role

    Options describing storage, single VM creation, and permissions are other cloud services, not MIGs.
  3. Final Answer:

    To run multiple copies of the same virtual machine for reliability -> Option B
  4. Quick Check:

    MIGs = multiple VM copies for reliability [OK]
Hint: MIGs run many identical VMs to keep apps running [OK]
Common Mistakes:
  • Confusing MIGs with storage services
  • Thinking MIGs manage single VMs only
  • Mixing up MIGs with user permission management
2. Which command correctly creates a managed instance group named web-group with 3 instances using the instance template web-template?
easy
A. gcloud compute instance-groups managed create web-group --template=web-template --size=3
B. gcloud compute instance-groups create web-group --template web-template --count 3
C. gcloud compute managed-instances create web-group --template=web-template --size=3
D. gcloud compute instance-groups managed create web-group --template web-template --count=3

Solution

  1. Step 1: Identify correct gcloud syntax for managed instance group creation

    The correct command uses 'gcloud compute instance-groups managed create' with '--template' and '--size' flags.
  2. Step 2: Check each option for syntax correctness

    gcloud compute instance-groups managed create web-group --template=web-template --size=3 matches the correct syntax exactly. The other options have incorrect flags or command structure.
  3. Final Answer:

    gcloud compute instance-groups managed create web-group --template=web-template --size=3 -> Option A
  4. Quick Check:

    Correct command syntax = gcloud compute instance-groups managed create web-group --template=web-template --size=3 [OK]
Hint: Use '--template' and '--size' with 'instance-groups managed create' [OK]
Common Mistakes:
  • Using 'count' instead of 'size'
  • Omitting 'managed' keyword
  • Wrong command order or flags
3. Given this autoscaling policy for a managed instance group:
autoscaling:
  minNumReplicas: 2
  maxNumReplicas: 5
  cpuUtilization:
    targetUtilization: 0.6

What happens when CPU usage rises to 80%?
medium
A. The group stays at the current number of instances
B. The group scales down to 2 instances
C. The group scales up by adding more instances, up to 5
D. The group deletes all instances

Solution

  1. Step 1: Understand autoscaling triggers

    The target CPU utilization is 60%. When actual CPU usage is 80%, it is above the target.
  2. Step 2: Determine autoscaling behavior

    Since CPU usage is higher than target, autoscaler adds instances up to maxNumReplicas (5) to reduce load.
  3. Final Answer:

    The group scales up by adding more instances, up to 5 -> Option C
  4. Quick Check:

    CPU > target -> scale up [OK]
Hint: CPU above target means add instances [OK]
Common Mistakes:
  • Thinking it scales down when CPU is high
  • Assuming no change happens
  • Confusing min and max replica counts
4. You try to update a managed instance group with a new instance template but get an error. Which is the most likely cause?
medium
A. Autoscaling is disabled
B. You did not specify the rolling update policy
C. The managed instance group has zero instances
D. The instance template name is missing or incorrect

Solution

  1. Step 1: Identify common update errors

    Updating a MIG requires a valid instance template name; missing or wrong name causes errors.
  2. Step 2: Evaluate other options

    Rolling update policy is optional, zero instances or autoscaling off do not cause update errors.
  3. Final Answer:

    The instance template name is missing or incorrect -> Option D
  4. Quick Check:

    Invalid template name -> update error [OK]
Hint: Check instance template name carefully when updating MIG [OK]
Common Mistakes:
  • Assuming rolling update policy is mandatory
  • Ignoring template name correctness
  • Confusing autoscaling with update errors
5. You want to ensure zero downtime when updating a managed instance group with a new version of your app. Which strategy should you use?
hard
A. Perform a rolling update with a minimal number of instances unavailable at once
B. Delete all instances and recreate them with the new template immediately
C. Turn off autoscaling before updating and turn it back on after
D. Manually stop each instance, update it, then start it again

Solution

  1. Step 1: Understand zero downtime update methods

    Rolling updates replace instances gradually, keeping most instances running to avoid downtime.
  2. Step 2: Evaluate other options for downtime risk

    Deleting all instances or manual stop/start causes downtime; turning off autoscaling is unrelated.
  3. Final Answer:

    Perform a rolling update with a minimal number of instances unavailable at once -> Option A
  4. Quick Check:

    Rolling update = zero downtime [OK]
Hint: Use rolling updates to avoid downtime during MIG changes [OK]
Common Mistakes:
  • Deleting all instances at once
  • Manual updates causing downtime
  • Misunderstanding autoscaling role in updates