Microsoft will sunset Azure Container Service as it doubles down on Kubernetes, so current users need to plan accordingly.
Azure Container Service (ACS), Microsoft's original container service, will be retired as of January 2020, and replaced with Azure Kubernetes Service (AKS). This will put Microsoft's focus solely on Kubernetes, doing away with its managed service option for hosting containers on its public cloud via Docker Swarm and Apache Mesos.
ACS was basically an orchestration wrapper for deploying and configuring IaaS, whereas AKS is the first step in providing a managed PaaS offering for Kubernetes. With AKS, the Kubernetes management plane is fully abstracted. Users don't manage, maintain or even pay for their Kubernetes masters. Instead, they focus solely on their worker nodes.
What you need to know about the Azure Container Service shutdown
In this video we explore the differences between ACS and AKS. We look at the benefits of the newer service, as well as what the changes mean for those currently working in ACS that will need to migrate. By understanding the key differences between the services, you will be able to assess how easy it will be to migrate your application into AKS and make required changes.
Once we understand the potential issues and requirements, we will look at how the migration process from ACS to AKS will work with different scenarios for different types of applications. We will also follow through a live example of migrating a stateful application using the Azure CLI.
After watching this video, users should have a good understanding of why they might want to migrate to AKS, the work that will be required of them and how to go about doing it.
Transcript - Prepare for Azure Container Service deprecation
Azure Container Service, or ACS, was Microsoft's first attempt at offering container orchestration service in Azure. This was released in 2017, but as of January 2020, this service is going to be retired. And so those who are using ACS are going to need to move off onto another service, and Microsoft's recommendation is to start looking at Azure Kubernetes Service, or AKS.
ACS allows you to deploy container orchestration solution into Azure running any of the big three container orchestrators: Kubernetes, Docker Swarm and Mesos. But what it effectively did was deploy a set of infrastructure-as-a-service VMs and configure them for you to run those applications. But what you were left with was a set of virtual machines that you are now responsible for managing and patching and so on. And whilst ACS was a much simpler way of deploying a container orchestration than having to do it all manually, people were still really asking for much more of a managed service solution than having to look after a bunch of virtual machines themselves.
And so with the move from ACS to AKS, Microsoft has focused on making this much more of a managed service. So with AKS, you no longer have to look after the actual management control plane of your orchestrator. This is taken care of by the service and the only infrastructure you see deployed is the actual worker nodes which will be in your subscription as virtual machines or virtual machine skillsets, and eventually, in the future, I expect even those to go away and become part of a managed service.
So the move to AKS has simplified things a great deal, but there are a number of things you need to be aware of if you're going to be migrating from ACS to AKS. The first and most obvious thing is that AKS, given the name, is Kubernetes only. It no longer supports Docker Swarm or Mesos. So if you want to migrate to AKS, you need to make sure that your applications are configured to run in Kubernetes and if they're not, go for a process of migrating your applications to run in Kubernetes.
The second point is that we've moved to a completely managed control plane, so you no longer have access to the Kubernetes masters in the cluster. They are created by and managed by Microsoft and you do not have any access to these. This obviously has a number of good points because you're not having to look after those virtual machines, and it also decreases the cost. So when you deploy an AKS cluster, you are only actually paying for your worker nodes. You're not paying for the masters. However, if in your previous deployment on ACS, you made changes to the masters or the way the master setup worked, you are no longer going to be able to do that.
Another change from ACS to AKS is the way that state works, in particular with persistent volume claims. In ACS, if you're using pure as your services, you could create PVCs using Azure Disks or Azure Files. This is still possible with AKS, but the Azure Disk part has moved from unmanaged disks to managed disks. And so there is a migration required if you're using Azure Disks for your PVCs to move to managed disks. If you're using Azure Files, this will still work as previously.
Finally, there are a couple of features that were available in ACS which are available in AKS but are in preview currently. Firstly, Windows support. So if you're using Windows containers on Windows nodes, this has recently been introduced in AKS but it is in preview. So expect that to change and evolve over the near future.
Secondly, multiple node pools. So if you were running Windows and Linux nodes side by side, or you had different node pools with different sizes of VMs and so on in your ACS cluster, again, this is possible, but it is in preview and it is still evolving. So if you're using either of those two things, Windows or multiple node pools, and you need to use that in production, you need to think carefully because these have not yet reached the general availability stage in AKS.
So now that we know what's changed, how do we migrate our applications from ACS to AKS? Well, the first step is, as the only supported orchestrator is Kubernetes, if you had previously been using Docker Swarm or Mesos, you'll need to migrate your application configuration to work with Kubernetes, so creating the appropriate YAML files and possibly even helm packages if you want to go down that route to be able to deploy your application to Kubernetes. We don't have time in this video to detail exactly how to do that. There are plenty of resources available online for migrating from those platforms.
Once we have our application configured to work in Kubernetes, we need to migrate it and there are two different approaches, depending on whether your application is stateless or whether it has state that is stored on persistent volume claims that'll require some additional migration. So first off, if we have a look at a stateless application where we are not storing any state inside our actual Kubernetes resources, there may be state stored outside in a database or something like that, but we're not considering that here. Migrating a stateless application is pretty straightforward. What we're going to do is first create a new cluster running AKS in whatever location we want that to be deployed to. Then we'll go ahead and deploy our application onto that new cluster. All the time, current traffic is still being sent to the old cluster and being serviced by that.
Once we have our application deployed and we have everything running and we've tested things on our new AKS cluster, we can then initiate a cut-over at the DNS level to send traffic over to our new cluster. And then once we're happy that everything on the new cluster is working, we can go ahead and decommission the old ACS cluster. At this point, we're fully migrated over to AKS. Where things are a bit more complicated is where we have state stored using persistent volume claims, and there are actually two scenarios to this, whether you're using Azure Disks or Azure Files.
So, first off, Azure Disks, which is the most complicated one. All right, so we've got our ACS cluster running with the data stored on our PVC claims, which are using old unmanaged disks. Same as before. We're going to go ahead and create an AKS cluster ready to accept our new traffic, and we're going to deploy our application onto it. And this is where things get a bit more complicated because to do this migration, we are more than likely going to need some downtime. We need to be able to take a snapshot of those disks and then copy them across to the cluster. To ensure that we get the data in a clean state and we don't lose any data, we're going to have to quiesce those disks and make sure that no additional traffic is being sent to the cluster that could write to those disks to allow us for the transfer. So more than likely, at this point, we are going to have to stop traffic coming into the cluster to allow us then to quiesce the disks and create a snapshot.
Once we've created a snapshot, we can then create managed disks in our new AKS cluster using that snapshot. Those disks are going to be up to date at the point we took the snapshot. Now that we have the managed disks attached to our cluster, we will configure our application to use those managed disks as a persistent volume claim, and at that point our application will be up and running. We do some tests, and if we're happy we'd redirect our traffic over to the AKS cluster and everything would start working over there. Once we're happy, everything is doing what we want, we can then decommission the ACS cluster.
Let's take a look at how we would do a migration of an Azure Disk persistent volume. As you can see here on this cluster, we've got a single persistent volume and a persistent volume claim and these are using an unmanaged disk to back that of size 5 GB. And if we look in the Azure portal, you can see we've got our VHD in our storage account which is backing this persistent volume. So we need to migrate that over to our AKS cluster.
The first thing we would do is stop any traffic coming into our cluster so we're not going to get new writes to this disk during the process. Then we're going to switch back to using the command line and we're going to use the Azure CLI for this. And the first thing you want to do is create a snapshot of that disk. So we're going to use the AZ Snapshot Command to create a snapshot. We're giving it the resource group that we want the snapshot to be created into, the name we want to give the snapshot, which I've used a persistent volume claim name for, and then the source URL of the blob that we're going to use to create our snapshot. So we'll go ahead and run that. And you can see that's created the snapshot for us. If we switch back to the Azure portal and refresh, we should now see we've got a snapshot created.
Now we've created a snapshot, we can again use the CLI to create a disk from that snapshot. We use the AZ disk create command, just give it the name of the disk we want to create, and then the source being the snapshot, and we can run that, and our disk has now been created and back in the portal we can now see that that disk is here as well. So that's now created in the right resource group in the manage disk format ready for our AKS cluster to consume it. All we need to do now is create the persistent volume claim and the persistent volume in the AKS cluster so that we can use them.
Over at visual studio code, we've got the YAML file for creating our persistent volume and our persistent volume claim. This is slightly different from the standard because instead of creating a new disk dynamically, we want it to use the existing disk.
So in our Azure disk section, you see we're using the type managed and we're going to pick the disk name, which is the actual name of the disk that shows in the portal in the CLI and then the URI, which is the full resource path to the actual disk object, so including the subscription resource group and then the disk name. Then in our persistent volume claim, we're just going to use the PVC we created earlier and create that claim. We're then able to use that claim within our deployments and pods to attach the disk as we require.
The final scenario is where we are using Azure files for our persistent volume claim rather than Azure disks. The benefit of Azure Files is that it does allow multiple clusters to read and write to the files at the same time, so we don't need to do the same thing where we're taking snapshots and copying data around. All we need to do is deploy our new cluster, deploy our applications, and then configure those applications to talk to our Azure file share. This can be done at the same time as the current ACS cluster is still running and still accessing that file share. And we're happy and we're ready, we can switch over the DNS again to point to our AKS cluster.
That covers the most common scenarios of migrating from ACS to AKS. If you're using other storage providers outside of Azure, you will need to follow a process that allows you to migrate those storage providers. I hope that's been useful and thank you for your time.