Introduction to AKS - Managed Kubernetes Service on Azure
By Shahid Iqbal on 24 October 2017
To paraphrase Marc Andreessen, Kubernetes is eating the world.
Microsoft today (24th October 2017) announced the public preview of the AKS, a fully managed Kubernetes Service running on Azure.
AKS is to Azure what GKE is to Google Cloud Platform.
Kubernetes on Azure
Sure you’ve been able to run Kubernetes on Azure for a while, so why AKS and how does it differentiate itself from the other solutions on Azure?
Broadly speaking you have 3 choices for running Kubernetes on Azure.
- Kubernetes the hard way - spin up the infrastructure and install it yourself.
- Azure Container Service (ACS) - a service to provision and install Kubernetes for you
- AKS (“Azure Kubernetes Service”)] - a fully managed Kubernetes as a Service
I won’t talk much about option 1 (although if you want to really understand how Kubernetes is put together its a great way of understanding that).
Options 2 and 3 are more interesting if you want to get up and running without worrying too much about the detail behind the scenes.
ACS has been in GA since April 2016 and gave you a way of provisioning a Kubernetes cluster on Azure by simply defining a few parameters. Behind the scenes ACS uses the ACS engine to create ARM templates defining the resources required for the cluster and then provisions those resources for you. Once up and running you had a Kubernetes cluster with the requisite master and worker nodes and you were off and running. Think of ACS as a tool to make option 1 easier, once the components were up and running you were responsible to managing them and updating them (although ACS is an Azure service so you had some assistance from Azure).
AKS is the next logical step, rather than provisioning the infrastructure and leaving it to you to manage it all, AKS takes responsibility of a key part of your cluster, the master node(s), a.k.a the management plane.
The management plane is fully managed by Azure, with all the availability guarantees you’d expect from Azure, they take responsibility for patching the underlying hosts, upgrading minor versions of Kubernetes and ensure your etcd cluster (the datastore that Kubernetes uses) is backed up and quorum is maintained.
It couldn’t be simpler to get started with AKS, if you have the Azure CLI you can provision a new Kubernetes cluster in minutes. Even cooler, you can simply use the Azure Cloud Shell and be up and running without anything on your machine except a browser (you could even provision a cluster from your phone, although why would you need to!).
First make sure you have the updated Azure CLI (2.0.20+) so the new aks sub command is available if you’re not using the CloudShell
Create a resource group called hfck8sRG in one of the supported regions, in this case ukwest
az group create -n hfck8sRG -l ukwest
Now using the new aks command we can provision a cluster in that resource group using all the defaults. Here we are creating a cluster called hfck8s in the resource group we defined in step 1:
az aks create -n hfck8s -g hfck8sRG
The cluster will created and Kubernetes should be up and running in a few minutes. That’s it! in 2 steps you have a Kubernetes cluster up and running, and you won’t need to be too concerned about looking after the master node(s) and backing up the etcd datastore etc.
You can now download the kubeconfig file needed to interact with the cluster using the Kubernetes CLI (kubectl):
az aks get-credentials -n hfck8s -g hfck8sRG
From my local machine I can now use kubectl and get information about the cluster
And I can see my nodes
If you want to see the Kubernetes dashboard you can expose this by running the aks browse command which sets up port forwarding from your local machine to the cluster:
az aks browse -n hfck8s -g hfck8sRG
(note: aks browse wasn’t working for me when I tried so I had to resort to a different approach using:
kubectl -n kube-system port-forward <dashboard-pod-name> 9090:9090)
The defaults for the aks create command in step 2 is a 3 node cluster (3 worker nodes) using D2 v2 VMs but you can change this and other parameters when you specify the cluster at the command line in step 2.
- Upstream Kubernetes - not a customised version
- 99.95 Uptime SLA (once in GA)
- Ability to create clusters using different versions of Kubernetes and upgrade clusters
- Events & Metrics from control plane available with integration with OMS
- Easy scaling of agent nodes - Scale the number of worker nodes from the CLI by simply calling the aks scale sub command e.g.
az aks scale -n hfck8s -g hfck8sRG --node-count 5
AKS is free! Ok well not quite. With AKS you only pay for the worker nodes you provision (where your pods/containers run). The management plane (i.e. the master nodes) is fully managed by Azure and you don’t pay for that.
This pricing model is the same as Google Container Engine and was likely “inspired” by it :)
The fully managed Kubernetes platform space is highly competitive so you can expect to see the competition to attract users heat up.
With regards to AKS, some future developments we can obviously expect to see are things like support for hybrid clusters comprised of windows and Linux nodes (as this support becomes more mature within Kubernetes itself).
Better integration with other Azure services is also likely to be coming in the pipeline perhaps by GA.
AKS is the natural evolution for Kubernetes on Azure from ACS, for users of Azure its a very welcome addition to the platform. For users of other platforms, especially GKE I’m not sure its got enough (at the moment at least) to see you move over. This is an area where the competition is really hotting up and you can be sure that each provider is vying to bring unique features to their platform.
I’ll create a series of blog posts specifically around getting started with Kubernetes including using AKS keep an eye out for those in the near future. I am also speaking at local user groups on topics such as Kubernetes and Windows Containers, get in touch if you are interested in learning more.