1. Step 01 – Getting Started with Instance Groups
Welcome back. Welcome to this new section on instance groups. In this section, let’s see how you can use instancegroups to manage a group of virtual machine instances. What are instance groups? How do you create a group of virtual machine instances? That’s where we’d go for an instance group. An instance group is nothing but a group of virtual machine instances managed as a single entity. You can manage a group of similar VMs with a similar lifecycle as one unit. There are two types of instance groups that you can create. The first one is the managed instance group. The Migrants Group, or MiG, is another name for it. These are identical VMs created using a template. So these VMs that are part of a managed instance group have the same machine type, same image, and the same configuration. So they are created using an instance template. to the Using the instance group, you can scale the number of compute instances up and down.
Managed instance groups also provide auto-healing. You can configure a health check, and if the health check fails, that specific instance will be automatically replaced with a new instance. Another important feature is managed releases. You can go from one version to another without any downtime. The other type of instance group is an unmanaged instance group. In unmanaged instance groups, you can have VMs with different configurations. You might have VMs with different images that were used to create them, or you might have VMs with different hardware. So you don’t want to group VMs with different kinds of configurations.
In those kinds of situations, you create an unmanaged instance group. The important thing to remember is that unmanaged instance groups do not include any features such as auto scaling or auto healing. Only managed instance groups are supported. That’s basically identical VMs that are created using an instance template, and only for them do you have features like auto scaling and auto healing. For unmanaged instances, you do not have the features of auto-scaling and auto-healing. An important thing to remember is that unmanaged instances are not recommended unless you need different kinds of VMs. If you want to create multiple instances of the same kind of VM in those situations, always go for a managed instance group. Go for unmanaged only when you need different kinds of VMs. You can create it in a specific zone. Or you might want the instance group to distribute the instances across different zones in a specific region. Obviously, regional is recommended because it gives you higher availability. Let’s now talk about the most important type of instance group, which is the managed instance group.
As we discussed earlier, it’s also referred to as MiG. managed instance group. A managed instance group is an identical set of VMs created using an instance template. So you have an instance template that has the configuration, and you can use that to create a managed instance group with the important features we have already referred to. The important features of a managed instance group are that it can maintain a certain number of instances. You can say, “I would want two virtual machine instances running all the time in that kind of situation.” Even if one of the instances fails, the managed instance group will replace it with a new instance so it can maintain a certain number of instances. If an instance crashes, MiG launches another instance. It can detect application failures using health checks, so it’s self-healing. So basically, you can configure a health check on the application that is deployed on your instance. And if the health check fails, that instance would be replaced by a new one. You can also increase and decrease the number of instances that are part of your managed instance group based on the load and the number of users using the application, so it provides auto-scaling. You can also add a load balancer attached to your managed instance group to distribute load. among the different virtual machines that are part of your managed instance group. And if you are creating regionally managed instance groups, then you can distribute the instances across multiple zones. This gives you higher availability. So, regionally managed instance groups provide you with higher availability compared to zone-managed instance groups.
The other important feature of a managed instance group is that you can release new application versions without downtime. Whenever I have a new application version, I create a new instance of the instance template, and I can upgrade from one instance of the instance template to another instance of the instance template without any downtime. Among the features that are provided are rolling updates. Basically, you can release new versions step by step. You can update a percentage of instances to the new version at a time. If you have ten instances, you can update them two at a time, for example. The other option you also have is canary deployment. Basically, you can test the new version of the instance template with a group of instances.
So out of the ten instances that are live right now, you can choose two instances. I can test it with those. two instances, and then I can roll it out to all the other instances at one time. This is called canary deployment. So with managed instance groups, you can do rolling updates and redeployments as well. You can update. a group of instances at a time. Or you can test with a group of instances and then roll it out at once to all remaining instances. We were introduced to instance groups in a step. If you want to manage a group of virtual machines together, you would create an instance group. There are two types: managed and unmanaged. In a managed instance group, it’s all identical. Auto scaling, self-healing, and managed releases are among the features provided by VMs and a managed instance group. When you want different kinds of VMs in a group, then you can go for an unmanaged instance group. An unmanaged instance group, on the other hand, does not provide you with self-healing or auto-scaling. I’m sure you’re having a wonderful time, and I’ll see you in the next.
2. Step 02 – Creating Managed Instance Groups (MIG)
Welcome back. In the last step, we got an introduction to a managed instance group. In this step, let’s look at what’s involved in creating a managed instance group. The first thing that you need is an instance template. The instance template is mandatory, and once you configure the instance template, you need to configure auto scaling to automatically adjust the number of instances based on the load. So you can configure the minimum number of instance instances. The maximum number of instances for which auto-scaling metrics can be configured is How do you want to do automatic scaling? Do you want to do it based on CPU utilisation or do you want to do it based on load balancer utilization? Or there is also a monitoring tool, which is provided by Google Cloud. It is called Stack driver. So, do you want to use any Stack driver metrics to do the auto scaling so that you can configure everything when configuring auto scaling?
In addition to that, you can also configure a cooldown period. If I’m executing an auto-scaling action right now, how much time should I wait before looking at the auto-scaling metrics again? That is what is configured by the cooldown period. This would ensure that scaling up and scaling down does not happen very frequently. So you perform a scaling action. So you increase the number of instances by three and then wait for some time before you look at the metrics again. That is what is configured by the cooldown period. You can also configure a few built-in controls. You don’t want a sudden drop in the number of VM instances. Scale in controls can be configured in these situations. You can say I don’t want to scale in by more than 10%, or three instances in five minutes. So in that interval, the maximum number of instances that should be scaled in or the maximum number of instances that should be reduced should be 10%. Or you can also configure a specific number, like three. I only want to reduce three instances in 5 minutes.
As part of your auto-scaling configuration, you can also configure the settings for auto-healing. Auto-healing is just the process by which the managed instance group can identify unhealthy instances and replace them with healthy ones. How do you do that? The way you can do that is by configuring a health check. Along with the health check, you can also configure an initial delay. Whenever you set up a new virtual machine, you need to give it some time before it’s ready to accept traffic. You can configure an initial delay, saying how long should you wait for the app to initialise before running a health check? We now have a lot of theory that we have discussed up to this point. Let’s now get started with a demo. On the managed instance group, I have one VM instance that was manually created earlier. So I actually used the instance template that we had earlier.
So we have this instance template, “my instance template with custom image,” which we created earlier. In the last section, I used it and said “create VM,” and I created the VM with the default settings. What you want to do is create instance groups. Where do we create instance groups? I can minimize virtual machines and go to instance groups in here, and you can see that as part of instance groups, there are instance groups and health checks. I’ll go to instanced groups first. This is where you can create your instance groups. Instance groups let you organise your VM instances or use them in the load balancing backend service. You can group existing instances or create a group based on an instance template. If you are grouping existing instances, then most likely you are creating an unmanaged instance group. If you are creating a group based on an instance template, you are creating a managed instance group.
Let’s go ahead and create an instance group. So over here on the left-hand side, you can see the different types of instance groups that you can create. You can create a new managed instance group that is stateless or a new managed instance group that is tasteful. What is the difference between stateless and stateful? If you are creating something like a database that has a full workload, you’d want to ensure that all data is persisted; you don’t want any instances to be removed without the data being persisted. And when you are running stateful workloads like databases, you would create a new managed instance group for a stateful one. However, for most of the situations, we would be running stateless workloads in the virtual machines. We’d be running web applications or Rest APIs, which ideally should not have any state.
And in those kinds of situations, you’d go for a managed instance group that is stateless. An unmanaged instance group is a group of VMs that you manage yourself. So it’s just a group. If you click the unmanaged instance group, you’ll see that you can give it a name and select a zone and a region, and all the instances in that region and zone will appear here, and you can select any of the existing VM instances and add them. These VM instances that are present don’t need to have the same configuration. So you can see that the instance that I created earlier, my instance template with the custom image, I can add to this specific group, and right now I don’t really have any other instances. If I have other instances, then I can also add them to this group as well. So this is kind of just a group of instances. They don’t really need to be similar. The only constraint that they must meet is the one that we define here. They should be in a specific zone, and they should be part of the same network and subnetwork. Now, let’s not worry about unmanaged instance groups. Unmanaged instance groups are very infrequently used. The ones that are mostly used are the managed instance groups. Let’s go back to the new managed instance group.
And we want to create a managed instance group. So I’ll name this my managed instance group. Over here, when you’re creating a managed instance group, you can choose whether your instances will be in a single zone or multiple zones. When you have a single zone, you can choose the region and the zone. When you have multiple zones, you can only select the region. If you want high availability, you can go for multiple zones. I’d go for multiple zones, and I’d distribute them across multiple zones in this specific region if you want. You can also choose the specific zones you want to make use of. I don’t really want to worry about it, so I’ll take the defaults that are suggested. The next thing you’d need to choose is the instance template. And we already have a couple of instance templates earlier.I’ll select my instance template with a custom image, which we created with a custom image. So I’ll choose that. And next, you can go to auto-scaling mode. and you can see that there are multiple options. You can either enable auto-scaling or specify that you do not want it at all. So you can turn off autoscaling and then actually configure how many instances you want. The other option you have with autoscaling is to auto-scale only up. So you’re saying that you should only add instances and never remove them? What I’d like to do is enable auto scaling. So I’ll choose auto-scaling. After configuring auto scaling, you can select the metric on which auto scaling will be based. So over here, the default is CPU utilization. If you click this, you can actually change it to other metrics as well. and For now, I’ll choose the default.
So I’m going to say cancel. In here. I’ll use CPU utilization. You can see that the target that is configured by default is 60%, and right below that we would configure the cool-down period. The default cooldown period, which is configured here, is 60 seconds, and next to it, you can actually configure the minimum number of instances and the maximum number of instances. For now, I’ll actually set them both to two. So if I actually set them both to two, then it would ensure that two instances are always running. The next thing that you can configure is scaling controls. So if you want, you can enable scaling controls and configure I don’t want to reduce more than 10% of instances over 10 minutes, and I don’t really want to worry about it, so I’ll disable it. And the next thing that you can configure here is a health check. So I can go ahead and say “create a health check,” and over here I can configure a lot of details as part of the health check. So I’ll call it my VM health check, and I’d like to use the HTTP protocol.
So you want to send HTTP requests on port 80, and let’s choose the default request path, which is /. And at the end, you can also configure health criteria. You can define how health is determined. The important configuration is the check interval. How often should the health check be done? The default is 10 seconds. The next configuration is timeout. How long should I wait before my request is deemed unsuccessful? Let’s say a health check request is sent. How long should it wait before the attempt is considered a failure? The default that we are configuring here is 5 seconds. The next one is a threshold. How many consecutive successes should occur to mark a VM instance as healthy? Only when there are two successively successful health checks. The VM instance would be marked as healthy. The next one is the unhealthy threshold. The unhealthy threshold is how many consecutive failures must occur to mark a VM instance as unhealthy. The default is three. So only if the health check fails three times will this instance be marked as unhealthy. Only if the health check passes twice will it be labelled as healthy. So let’s go ahead and configure the health check; let’s say save and continue right below. You can also configure an initial delay. How much time do you want to allow for the instance to boot? The default shell delay, which is configured here, is 300 seconds. and that’s very, very high. I don’t really need that much time for my instance to start up, so I’ll reduce it to 30 seconds. So make sure that you are reducing the initial delay to 30 seconds. And what I would do now is go ahead and say “create eight.” This should start the creation of our instance group. The creation of the instance group would take a little while. I recommend that you take a break and I’ll see you later.
3. Step 03 – Playing with Managed Instance Groups (MIG)
Welcome back. The creation of the instance group took about ten minutes, and at the end of the ten minutes, I could see the new instance group that was created. You would see a warning in here that says the minimum number of instances is equal to the maximum number of instances. This means the auto scalar cannot add or remove instances from the instance group. Make sure that this is the correct setting. That’s fine; you don’t really need to worry about this warning. I’m attempting to keep two instances running at all times with Hell check enabled. So even if one of the instances is killed, you’d see that it would be automatically replaced with a new instance by the managed instance group. In an ideal world, the maximum number of instances would probably be higher. So probably you would set it to a higher number, like 10 or 20 or 30, or whatever you expect to be the maximum number of instances that you might want to use.
I can see the name of the managed instance group, the number of instances, and the template that was used to create it on the managed instance group page. You can see that this is a managed instance group. When was it created? On the right, you can also see the autoscaling configuration. Now, when I click inside the managed instance group, I will be able to see a few more details. You can see that there are two instances in total, and two instances are running. You can see where it is and how many of them are completely healthy. You can also see that Auto Healing is set up with a health check. Where is that health check configured? You can actually click it, and you’ll be taken to the health check. And you can see all the details of the health check that are configured. You can see that we are making an HTTP request to the root on port 80. Let’s go back to the instance group. And over here, you can also see the two instances that are part of the instance group. You can see that their names are configured by default. So my managed instance group is the name of the instance group Hyphen. With a few random letters and numbers, you can see that these two are created in two different zones: US Central Zone F and US Central Zone C.
Now I can click in here, and this will take me to the configuration of that specific virtual machine instance. Now I’ll click on the virtual machine instances in here to see all the virtual machine instances that are present in this area. This is the instance that I created earlier from a custom image. So I use the instance template to create this specific image directly. And these two are the ones that we created through the managed instance group. And over here, you can see that these two are tagged as induced by a specific managed instance group. And clicking the external IPS of both of these should bring up the HTTP response. So hello world from my manager group, the name and IP address, the internal IP, and similarly from the other one. So this is also working. Now I’ll go back to the instance groups, and I’ll go to the specific instance group, and if you want, you can also edit the group.
So you can go here and say “edit the group,” and over here you can actually configure if you want to change the metrics that are used for auto scaling. You can change the health check or increase or decrease the number of instances. Let’s say I would want to actually just have one instance, and then I can change this to one as well. Or if I want five instances, I can increase it to five as well. So if I actually, let’s say, change the minimum to three and the maximum to three as well, then say save, what would happen? You’d see that this group would be updated. Let’s go back a step, and you’ll see that the third instance is also up and running within a few minutes if you give it a few minutes. We got started with playing around with the instance group. There are a lot more things that we’d want to learn about it, and I’ll see you in the next chapter.
4. Step 04 – Updating a Managed Instance Groups (MIG) – Rolling Updates and Restart
that we understood how to create a managed instance group. Let’s shift our attention to updating a managed instance group. We did one of the basic updates in the last step. We updated the number of instances. Or we updated this auto-scaling configuration to Max Three and Min Three and saw that the number of instances would be increased automatically. Other than that, there are a lot of other updates that you can do with a managed instance group. Let’s look at them in this specific step. The first type of update that you can do is a rolling one. A rolling update is a gradual update of the instances in an instance group to a new instance template. Let’s say I have one version of the instance template and I want to upgrade to the new version of the instance template.
The earlier version of the instance template might be referring to an old version of the application, and the new version of the instance template is referring to the new version of the application. In that kind of situation, what we are doing here is switching from an old version of the application to a new version of the application. When we are doing this, the first thing that you need to do is specify the new template. Optionally, you can also specify a template for canary testing. A rolling updates would befallbackend resulte. Let’s say I have ten instances. I can say I would want to update two instances at a time. So I would want two instances first, two instances next, and two instances after that. So we are updating in two groups of two instances each. The other option is to test a set of instances first. So you would configure a new template that’s basically called the Canarytemplate, and you’d test two instances. Once the two instances are all tested, you would roll them out at once to the remaining eight instances. This approach is called a “canary testing” approach. You’re testing a set of instances quickly, and then you’re rolling it out to all the instances at the same time. You can do both canary testing and a gradual rollout using an update to a managed instance group. The next thing you need to specify is how you want the update to be done. When should the update be done? Should the update start immediately? That’s basically called proactive. So, proactively update all the instances. Or you can also be opportunistic: when the instance group is resized or when the instances are killed, you’d want to replace them with an instance created using the new template. Typically, we would go for proactive, but there might be situations where the update is not really important. You can wait some time in those kinds of situations. You can go for opportunistic. The next thing you’d want to configure is: how should the update happen? At any given time, how many instances should be updated? Let’s have ten instances. I can say I would want to add a maximum of two instances at any point in time, so in total, there will be twelve instances that would be running at any point in time. You can also set the maximum amount of time unavailable while the update is being performed. How many instances can be offline? If I have ten instances and, let’s say, two instances can be offline, then those two instances can be updated to the new version. The remaining eight instances will be serving traffic.
The other type of update that you can perform is a rolling restart or replacement. This is not really an update, but you’d want to actually, let’s say, restart all VM instances without any downtime, or you’d want to replace a VM instance with a new version created with the same template. So over here, there is no change in template, but you’d want to either restart the existing VM or replace the existing VM with a new one using the same template. Even in this case, you have the option of configuring maximum search, maximum unavailable, and what you want to do. You can configure whether you want to restart the instances or replace the instances. Now let’s go back to our instance groups. Let’s refresh the thing. Once it refreshes, I can see that there are three instances running right now. I can go inside the My managed instance group. Let’s start by talking about rolling, restarting, and replacing. So this is a gradual restart or replacement of all instances in the group. Over here, we are not changing the template, but we would want to replace or restart existing VMs.
How do you do that? That’s where you can go for a rolling restart or replacement. You can go in here, click rolling restart or replacement, and over here you can configure what operation you want to do. I want to restart all VMs, or I would like to replace the instances. You can configure the maximum surge and the maximum number of temporary instances to add while replacing. So how many new instances will be added temporarily when the replacement is in progress?
You can also specify the maximum number of unavailable users. how many instances can be offline at the same time while restarting or replacing, and you can also configure a minimum wait time. How much time should I wait between consecutive instance restarts or replacement operations? Once you do this, you can click “restart.” The other option is to actually do something or replace something. So you’d want to replace the existing instances with new ones, and you can configure one maximum unavailable instance at a time, as well as create one new instance at a time, and you can go in and say, “I don’t want to replace.” Let’s not really worry about it; let’s do a cancellation.
The other thing you can do is do a rolling update. The rolling update is a gradual update of instances in an instance group to a new instance template. You can create a new version of the instance template and update it using the rolling update. So you can click “Rolling Update,” and over here you can configure a new template. Over here, you can see that the existing template is configured by default. If you’d like to do canary testing, what you can do is add in a secondary template so you can choose a new template. Let’s say the Mindset template with StartupScript is the template configured with the next version of your application.
And you can go in here and say, “I would want to update one instance at the start to the specific template.” Then two instances will be using the old template and one instance will be using the new template, and I can see how the update goes. I can test this specific instance. If the update went well, then I can update the remaining instances to the new version and over here configure the update mode. Do you want proactive or opportunistic behavior? Maximum search, maximum unavailable, and maximum wait time can also be set. Now, as far as the exam is concerned, there are a lot of questions around this. Let’s say I would want to upgrade to the new version without any downtime, and I would want to maintain the existing number of instances all the time. In that kind of situation, I would want to configure maximum unavailable to zero.
I don’t want any reduction in the number of instances that are serving traffic. As a result, the maximum unavailable will be zero, and you can set the maximum search time to how many hours you want to update at a given point in time. Let’s say you have ten instances and you want to update two at a time. You can then set Maximum Search to two. I don’t really want to execute the update, so I’ll do a cancel and go back into the step. We talked about how you can actually update a managed instance group. We talked about rolling updates, which are used to gradually update instances in our instance group to a new version of your application or a new version of your instance template. The other option is “Rolling Restart or Replace,” where you’d want to restart or replace the existing instances of aVM without any change to the instance templates. I’m sure you’re having a wonderful time, and I’ll see you on the next step.
