GCP Manage Instance group(MIG) - ghdrako/doc_snipets GitHub Wiki

Resource:

• https://cloud.google.com/compute/docs/instance-groups?utm_source=youtube&utm_medium=unpaidsoc&utm_campaign=CDR_ret_gcp_xtiykyzj3c0_ComputeEngineBasics_100721&utm_content=description
• https://www.youtube.com/watch?v=xTiyKYZJ3c0
• https://cloud.google.com/compute/docs/instance-groups/rolling-out-updates-to-managed-instance-groups

There are two types of instance groups:

• Managed instance groups: This type of instance group allows your workloads to be scalable and highly available via automated services in the groups, such as autoscaling or autohealing. Google recommends using this type of group unless it is unavoidable due to pre-existing configurations or a requirement to group dissimilar instances. Machine instance are identicale create from template.
  • Stateful MIG
  • Stateless MIG
• Unmanaged instance groups: This type of instance group allows for load balancing across a fleet of VMs that are not identical. They are user-managed, therefore autoscaling and autohealing are not supported.

Managed Instance Groups (MIGs)

A MIG is a cluster of individual VMs that are managed as a single VM. The main purpose of using MIGs is automating things such as scalability, deployments, and updates. By shifting applications (instances) on multiple VMs quickly, the cloud can do the following:

• Autoscaling Scale up and down.
• Autohealing Minimize downtime in case one of the VMs crashes or shuts down.
• Monitor application health and verify each application is working as expected on every VM. If an application does not respond, the cloud auto-heals by creating a new instance of the app.
• Automatically deploy new versions using different rollout scenarios, such as canary deployments or rolling updates.
• Multi-Region deployment for HA

Other powerful features of MIGs include load balancing, support for stateful workloads, and multiple zone coverages (which can be used to reduce latency).

Each of the VM instances deployed into the instance group comes from the same instance template, which defines the machine type, boot disk images, labels, and other instance properties.

Google Cloud Resouce using to manage MIG:

• Instance Group Manager - its represents Instance Group itself
  • VM localtion
  • VM distribution zonal/regional,
  • Group Size
• Instance template
• Health check
  • for Autohealing
  • HTTP,HTTPS,HTTP2,SSL or TCP
  • Custom interval and timeouts
• Autoscaling Policy
  • resize metrics
  • min/max group size
  • scale-in control

Autoscaling groups of instances

Autoscaling works by adding more VMs to your MIG when there is more load (scaling out, sometimes referred to as scaling up), and deleting VMs when the need for VMs is lowered (scaling in or down).

For regional MIG aditional requirements:

• You must set the group's target distribution shape to EVEN.
• To scale in and out, you must enable proactive instance redistribution.

You cannot use autoscaling if your MIG has stateful configuration.

For Google Kubernetes Engine groups, use cluster autoscaling instead.

Autoscaling policy

When you define an autoscaling policy for your group, you specify one or more signals that the autoscaler uses to scale the group. When you set multiple signals in a policy, the autoscaler calculates the recommended number of VMs for each signal and sets your group's recommended size to the largest number.

Signals can based on target utilization metrics or based on schedules.

Target utilization metrics:

• average CPU utilization
• HTTP load balancing serving capacity, which can be based on either utilization or requests per second.
• Cloud Monitoring metrics.

Schedules

• Capacity: minimum required VM instances
• Schedule: start time, duration, and recurrence (for example, once, daily, weekly, or monthly)

Cool down period

The cool down period is also known as the application initialization period. While an application is initializing on an instance, the instance's usage data might not reflect normal circumstances. cool down period to indicate how long it takes applications on your instance to initialize. By default, the cool down period is 60 seconds.

Stabilization period

For the purposes of scaling in, the autoscaler calculates the group's recommended target size based on peak load over the last 10 minutes. These last 10 minutes are referred to as the stabilization period.

Using the stabilization period, the autoscaler ensures that the recommended size for your managed instance group is always sufficient to serve the peak load observed during the previous 10 minutes.

Instance Template

Instance templates are global resources, which means they are not tied to a specific zone or region. Zonal resources in the template itself will restrict the template to the zone where that resource resides. For example, the template may include a disk that is tied to a specific zone.

An instance template is a resource that you can use to create virtual machine (VM) instances and managed instance groups (MIGs).

Instance templates define the machine type, boot disk image or container image, labels, startup script, and other instance properties. You can then use an instance template to create a MIG or to create individual VMs. Instance templates are a convenient way to save a VM instance's configuration so you can use it later to create VMs or groups of VMs.

An instance template is a global resource that is not bound to a zone or a region.

gcloud compute instance-templates create example-template-custom \
    --machine-type=e2-standard-4 \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --boot-disk-size=250GB


gcloud compute instance-templates describe example-template

gcloud compute instance-templates create INSTANCE_TEMPLATE_NAME \
    --source-instance=SOURCE_INSTANCE \
    --source-instance-zone=SOURCE_INSTANCE_ZONE \

gcloud compute instances create backend \
    --machine-type=n1-standard-1 \
    --tags=backend \
   --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh