Instance Templates and Managed Instance Groups

An instance template is an immutable resource that defines the properties of a virtual machine instance. It acts as a blueprint for creating identical VMs. Key properties include: - Machine type (e.g., n1-standard-4) - Boot disk image or snapshot (e.g., debian-10-buster-v20250101) - Disk type and size (e.g., pd-standard, 10 GB) - Network and subnetwork (e.g., default with auto subnet mode) - Service account and scopes - Metadata (key-value pairs) - Startup and shutdown scripts - Tags and labels - Reservation affinity (for consuming specific reservations) - Scheduling options (preemptible, maintenance behavior) - Shielded VM and Confidential VM settings - Network interfaces, including IP aliasing and network tiers - Guest accelerators (GPUs) - Minimum CPU platform

Instance templates are regional (stored in a specific region) and immutable — you cannot modify a template after creation. To change properties, you must create a new template and update the MIG to use it. The template resource name must be unique per project.

Creating a template via gcloud:

gcloud compute instance-templates create my-template \
    --source-instance=source-vm \
    --source-instance-region=us-central1 \
    --configure-disk=auto-delete=false

Alternatively, you can specify all properties explicitly. The --source-instance flag is a convenient way to create a template from an existing VM, but note that the source instance must be stopped to capture a consistent state. If you use a running instance, the template captures the current disk state, which may include running processes.

A managed instance group (MIG) is a collection of identical VM instances created from a single instance template. The MIG controller automates: - Instance creation and deletion based on autoscaling policies - Health checking and automatic replacement of unhealthy instances - Rolling updates to transition to a new template - Resizing (manual or automatic) - Regional distribution (for regional MIGs)

MIGs come in two flavors: zonal (instances in one zone) and regional (instances spread across multiple zones in a region). Regional MIGs provide higher availability and are recommended for production workloads.

Autoscaling adjusts the number of instances based on load. The scaling policy can use: - CPU utilization (target utilization, e.g., 0.6) - HTTP load balancing utilization (based on load balancer metrics) - Stackdriver monitoring metrics (any custom metric) - Cloud Monitoring metrics (e.g., pub/sub queue depth)

Key parameters: - cool-down-period: seconds to wait before starting scale-in after instance starts (default 60s) - max-num-replicas: maximum number of instances (required) - min-num-replicas: minimum number (default 1) - scale-in-control: controls how aggressively to scale down (e.g., max-scaled-in-replicas-percent) - overprovisioning: temporarily creates extra instances during scale-up to handle traffic spikes (enabled by default)

Autoscaling uses a signal-based approach. The autoscaler collects metrics every 60 seconds and decides whether to add or remove instances. The decision is based on the desired number of instances calculated from the metric value and target. For example, if CPU utilization is 80% and target is 60%, the autoscaler will add instances to bring utilization down.

Each MIG has a health check defined in the instance template or the MIG configuration. The health check is a simple probe (HTTP, HTTPS, TCP, or SSL) that determines if an instance is healthy. If an instance fails the health check for a configurable number of consecutive checks (default 2), the MIG considers it unhealthy and recreates it. The health check runs every 5 seconds by default (configurable via check-interval-sec).

Autohealing replaces unhealthy instances with new ones from the current template. This is distinct from autoscaling — autohealing maintains the current group size, while autoscaling changes the size.

Rolling updates allow you to update instances in a MIG to a new template without downtime. There are two strategies: - Proactive: The MIG automatically replaces instances according to a rollout configuration (max surge, max unavailable). - Opportunistic: The MIG does not automatically replace instances; it only updates instances that are stopped or deleted (e.g., during autohealing).

Key parameters: - max-surge: number of extra instances created beyond the target size during update (default 0) - max-unavailable: number of instances that can be taken down simultaneously (default 0) - min-ready-sec: minimum time an instance must run before considered ready (default 0)

Example proactive update:

gcloud compute instance-groups managed rolling-action start-update my-mig \
    --version=template=new-template \
    --max-surge=3 \
    --max-unavailable=1 \
    --region=us-central1

By default, MIGs are stateless — all instances are identical and can be replaced. Stateful MIGs preserve state on specific disks or metadata per instance. You can define stateful configurations for: - Stateful disks: Disks that persist even if the instance is recreated (e.g., for databases). - Stateful metadata: Instance-specific metadata that survives updates.

Stateful MIGs are useful for workloads like Cassandra or Kafka where each node has unique data.

You can associate reservations with a MIG to ensure capacity. The MIG can be configured to use any-reservation (first available) or a specific reservation. This is critical for workloads that require guaranteed capacity, such as GPU instances.

List instance templates:

gcloud compute instance-templates list

Describe a template:

gcloud compute instance-templates describe my-template

Create a MIG:

gcloud compute instance-groups managed create my-mig \
    --template=my-template \
    --size=3 \
    --zone=us-central1-a

Set autoscaling:

gcloud compute instance-groups managed set-autoscaling my-mig \
    --max-num-replicas=10 \
    --min-num-replicas=2 \
    --target-cpu-utilization=0.6 \
    --cool-down-period=90 \
    --region=us-central1

Update template:

gcloud compute instance-groups managed set-instance-template my-mig \
    --template=new-template \
    --region=us-central1

Rolling update:

gcloud compute instance-groups managed rolling-action start-update my-mig \
    --version=template=new-template \
    --max-surge=1 \
    --max-unavailable=0 \
    --min-ready-sec=30 \
    --region=us-central1

Scenario 1: Web Application Scaling A SaaS company runs a Node.js web app on Compute Engine. They use a regional MIG with 10 instances behind an HTTP(S) load balancer. The instance template includes a startup script that pulls the latest container image from Container Registry and runs it. Autoscaling is configured with CPU target 0.6, min replicas 3, max replicas 20. During a marketing campaign, traffic spikes and the autoscaler adds instances up to 20. The health check probes /health endpoint; if the app fails, the instance is replaced. Rolling updates are used to deploy new versions with max-surge=2 and max-unavailable=1. The company learned the hard way that setting max-surge=0 caused a brief outage when an instance took too long to start.

Scenario 2: Stateful Database Cluster A financial services firm runs Cassandra on a stateful MIG. Each instance has a stateful persistent disk (SSD) that stores data. The instance template specifies the disk as stateful via --stateful-disk. The MIG has a fixed size of 5 (no autoscaling). Autohealing is configured with a health check that verifies Cassandra is accepting queries. If a node fails, the MIG recreates it with the same disk attached, preserving data. The team uses rolling updates with --max-unavailable=1 to upgrade Cassandra versions. They avoid max-surge because adding extra nodes would cause unnecessary data replication in the cluster.

Scenario 3: CI/CD Build Farm A game development studio uses a zonal MIG of preemptible VMs for build jobs. The instance template uses a custom image with build tools. Autoscaling is based on a Cloud Pub/Sub queue depth metric — when jobs pile up, new instances are created. Preemptible instances are cheaper but can be terminated at any time. The MIG's autohealing replaces preempted instances. The team sets --min-num-replicas=0 to save cost when there are no jobs. They discovered that without a health check, instances that failed to start would remain in the group and waste resources. Now they use a health check that tests that the build agent is registered with the queue.