Managed Instance Group (MIG)
Think of a Managed Instance Group (MIG) as a Kubernetes ReplicaSet, but for VMs.
As a backend developer, imagine you need 10 identical application servers running your Spring Boot application.
Instead of manually creating and managing 10 VMs, you:
- Define a blueprint (Instance Template)
- Tell Google Cloud to maintain 10 copies
- Google automatically creates, heals, scales, and updates them
Core Components
1. Instance Template = Blueprint
Contains VM configuration:
- Machine type
- OS image
- Startup scripts
- Metadata
- Network settings
Example:
2. Managed Instance Group
Suppose: Desired instances = 3
Self-Healing Feature
If one VM crashes:
using the same template.
This is called auto-healing.
Auto Scaling
Traffic increases:
based on:
- CPU usage
- Load Balancer traffic
- Custom metrics
- Monitoring metrics
When traffic decreases: 10 → 3 VMs
Rolling Updates
Suppose version v1 is running:
Create a new template and update MIG.
Google replaces instances gradually:
No downtime.
This is called a rolling update.
Load Balancer Integration
Without MIG:
Zonal vs Regional MIG
Zonal MIG
Instances in one zone only.
Regional MIG (Recommended)
Instances spread across zones.
Higher availability.
Google generally recommends Regional MIGs.
MIG Creation Flow
Step 1
Create Instance Template
Step 2
Create Managed Instance Group
Step 3
Choose Region/Zone
Step 4
Configure Autoscaling
Step 5
Configure Health Check
Step 6
Attach Load Balancer (optional)
Comments
Post a Comment