View from the Community: Introduction to the Azure Kubernetes Service (AKS) and Dev Spaces


By Richard Conway, Microsoft Regional Director, MVP and Co-founder of the UK Azure User Group

This month we had a great talk by Marco de Sanctis, Microsoft MVP, who delivered new material on the Azure Kubernetes Service to a packed room of developers.

AKS is a new service that enables developers to focus on writing code. As we go through our cloud journey, Microsoft keeps removing the need to define a heavy ops burden on our cloud deployments. This is the way it should be. Microsoft can streamline this and do it better, and most developers want to be enabled in writing code over writing the glue to make code work.

To start off we’ll logon to the Azure Portal and create a new Kubernetes service. To keep costs down we’ll select a single node, but remember that AKS makes this process fluid and dynamic so we don’t need to worry about this now. However, note that a single node is also a single point of failure!

We’ll skip over the authentication but in order to manage this cluster so that we don’t have to, it will create us a default Service Principal, which is a non-interactive user that can issue commands to Azure on our behalf to get stuff done. It is used all over the place in automation and this is just another form.

Networking is next and this is down to routing HTTP if we have APIs we want to host, or going as far down as low level networking to understand how Docker is addressed.

Now that we’re done with the basics we can create everything that we need. There’s a lot of pieces that it needs to create, so we should give it a good 5-10 minutes.

With that complete, we’ll go as far as to build an application using .NET Core so that we can host an API. Just for simplicity I’ll make sure that this is API is stateless, so we’ll just create a simple sum method which takes two arguments.

[HttpGet]
public ActionResult<int> Get(int a, int b)
{
       return a + b;
}

We’ll be using Azure Dev Spaces to connect to the cluster. If you don’t have the toolkit installed for VS.NET 2017, be sure to install it. We should now be able to connect to our Kubernetes cluster quite simply.

We can deploy to Dev Spaces from our run dropdown in Visual Studio, and point to a subscription and our Kubernetes cluster. We can make this publicly accessible or lock this down so that it is only available on a private network. For simplicity, let’s go with the flow as it’s easier to create an internet client.

Now that we’ve done this, we have to enable Dev Space for the cluster. This takes a couple of minutes and Kubernetes should now enabled for Dev Spaces. As an aside, two resource groups are created. One with the Kubernetes service and vnets:

And the other with the physical parts to support the cluster, VM and network:

With Azure Dev Spaces we can debug the container in Kubernetes in real-time by hitting start on the Dev Space, which will automatically deploy the code to the cloud and open a browser.

It's simple to now make a request with parameters to the Controller class that you’ve created.

I have to say, what a great experience. I’m usually very sceptical about all the hidden work I have to do with the application stack, but this was seamless. It makes a bit of a mockery of Service Fabric deployments and the crazy level of config, and what you had to do with the old ACS and even Azure Functions. All of these other services will come of age eventually and I’m very much looking forward to Ivan Gavryliuk’s talk in April on Service Fabric Mesh which should show how far this has come. For the time being, this seamless, serverless approach to everything will really set Microsoft apart.


Like this article? Consider joining us at the UK Azure User Group! Meetings are attended by up to 100 people a time and all those with an avid interest to learn Azure are encouraged to attend. The group regularly gives a platform for the Microsoft Azure engineering teams and distinguished community speakers. Upcoming events include:

Skip to main content