Implementing Azure-Managed Kubernetes and Azure Container Service [Tutorial]

11 min read

The next level of virtualization is containers as they provide a better solution than virtual machines within Hyper-V, as containers optimize resources by sharing as much as possible of the existing container platform.

Azure Kubernetes Service (AKS) simplifies the deployment and operations of Kubernetes and enables users to dynamically scale their application infrastructure with agility; along with simplifying cluster maintenance with automated upgrades and scaling. Azure Container Service (ACS) simplifies the management of Docker clusters for running containerized applications

This tutorial will combine the above-defined concepts and describe how to design and implement containers, and how to choose the proper solution for orchestrating containers. You will get an overview of how Azure can help you to implement services based on containers and get rid of traditional virtualization stuff with redundant OS resources that need to be managed, updated, backed-up, and optimized.

To run containers in a cloud environment, no specific installations are required, as you only need the following:

A computer with an internet browser
An Azure subscription (if not available, a trial could work too).

With Azure, you will have the option to order a container directly in Azure as an Azure Container Instance (ACI) or a managed Azure solution using Kubernetes as orchestrator.

This tutorial is an excerpt from a book written by Florian Klaffenbach et al. titled
Implementing Azure Solutions – Second Edition. This book will get you up and running with Azure services and teach you how to implement them in your organization.

All of the code for this tutorial can be found at GitHub.

Azure Container Registry (ACR)

If you need to set up a container environment to be used by the developers in your Azure tenant, you will have to think about where to store your container images. In general, the way to do this is to provide a container registry. This registry could reside on a VM itself, but using PaaS services with cloud technologies always provides an easier and more flexible design.

This is where Azure Container Service (ACS) comes in, as it is a PaaS solution that provides high flexibility and even features such as replication between geographies.

This means you will need to fill in the following details:

When you create your container registry, you will need to define the following:

The registry name (ending with azurecr.io)
The resource group the registry sits in
The Azure location
The admin user (if you will need to log in to the registry using an account)
The SKU:
- Basic
- Standard
- Premium

The following table details the features and limits of the basic, standard, and premium service tiers:


Resource	Basic	Standard	Premium
Storage	10 GiB	100 GiB	500 GiB
Max image layer size	20 GiB	20 GiB	50 GiB
ReadOps per minute	1,000	3,000	10,000
WriteOps per minute	100	500	2,000
Download bandwidth MBps	30	60	100
Upload bandwidth MBps	10	20	50
Webhooks	2	10	100
Geo-replication	N/A	N/A	Supported

Switching between the different SKUs is supported and can be done using the portal, PowerShell, or CLI.

If you still are on a classic ACR, the first step would be to upgrade to a managed registry.

Azure Container Instances

By running your workloads in ACI, you don’t have to set up a management infrastructure for your containers, you just can put your focus on design and building the applications.

Creating your first container in Azure

Let’s create a first simple container in Azure using the portal:

Go to Container Instances under New | Marketplace | Everything, as shown in the following screenshot:

After having chosen the Container Instances entry in the resources list, you will have to define some properties like:

We will need to define the Azure container name. Of course, this needs to be unique in your environment. Then, we will need to define the source of the image and to which resource group and region it should be deployed within Azure.

As already mentioned, containers can reside on Windows and Linux, because this needs to be defined at first. Afterwards, we will need to define the resources per container:
- Cores
- Memory
- Ports
- Port protocol
- Restart policy (if the container went offline)

After having deployed the corresponding container registry, we can start working with the container instance:

When hitting the URL posted in the left part, under FQDN, you should see the following screenshot:

After we have finalized the preceding steps, we have an ACI up and running, which means that you are able to provide container images, load them up to Azure, and run them.

Azure Marketplace containers

In the public Azure Marketplace, you can find existing container images that just can be deployed to your subscription. These are pre-packaged images that give you the option to start with your first container in Azure. As cloud services provide reusability and standardization, this entry point is always good to look at first.

Before starting with this, we will need to check if the required resource providers are enabled on the subscription you are working with. Otherwise, we will need to register them by hitting the Register entry and waiting a few minutes for completion, as shown in the following screenshot:

Now, we can start deploying marketplace containers such as the container image for WordPress, which is used as a sample, as shown in the following screenshot:

At first, we will need to decide on the corresponding image and choose to create a new ACR, or use an existing one. Furthermore, the Azure region, the resource group, and the tag (for example, version) need to be defined in the following dialog:

Now that the registry is being created, we will need to update the permission settings, also called enable admin registry. This can be done with the Admin user Enable button as shown in the following screenshot:

Regarding the SKU, this is just another point where we can set the priority and define performance. This may take some minutes to be enabled. Now, we can start deploying container images from the container registry, as you can see in the following screenshot with the WordPress image that is already available in the registry:

At first, we will need to choose the corresponding container from the registry; right-click the tag version from the Tags section:

Having done that, we will need to hit the Deploy to web app menu entry to deploy the web app to Azure:

As the properties that need to be filled are some defaults for Web Apps, it is quite easy to set them:

Finally, the first containerized image for a web app has been deployed to Azure.

Container orchestration

One of the most interesting topics with regard to containers is that they provide technology for scaling. For example, if we need more performance on a website that is running containerized, we would just spin off an additional container to load-balance the traffic. This could even be done if we needed to scale down.

The concept of container orchestration

Regarding this technology, we need an orchestration tool to provide this feature set. There are some well-known container orchestration tools available on the market, such as the following:

Docker swarm
DC/OS
Kubernetes

Kubernetes is the most-used one, and therefore could be deployed as a service in most public cloud services, such as in Azure. It provides the following features:

Automated container placement: On the container hosts, to best spread the load between them
Self-healing: For failed containers, restarting them in a proper way
Horizontal scaling: Automated horizontal scaling (up and down) based on the existing load
Service discovery and load balancing: By providing IP-addresses to containers and managing DNS registrations
Rollout and rollback: Automated rollout and rollback for containers, which provides another self-healing feature as updated containers that are newly rolled-out are just rolled back if something goes wrong
Configuration management: By updating secrets and configurations without the need to fully rebuild the container itself

Azure Kubernetes Service (AKS)

Installing, maintaining, and administering a Kubernetes cluster manually could mean a huge investment of time for a company. In general, these tasks are one-off costs and therefore it would be best to not waste these resources. In Azure today, there is a feature called AKS, where K emphasizes that it is a managed Kubernetes service.

For AKS, there is no charge for Kubernetes masters, you just have to pay for the nodes that are running the containers.

Before you start, you will have to fulfill the following prerequisites:

An Azure account with an active subscription
Azure CLI installed and configured
Kubernetes command-line tool, kubectl, installed
Make sure that the Azure subscription you use has these required resources—storage, compute, networking, and a container service:

For the first step, you need to choose Kubernetes service and choose to create your AKS deployment for your tenant. The following parameters need to be defined:
- Resource group for the deployment
- Kubernetes cluster name
- Azure region
- Kubernetes version
- DNS prefix
Then, hit the Authentication tab, as shown in the following screenshot:

On the Authentication tab, you will need to define a service principal or choose and existing one, as AKS needs a service principal to run the deployment. In addition, you could enable the RBAC feature, which gives you the chance to define fine-grained permissions based on Azure AD accounts and groups.
On the Networking tab, you can choose either to add the Kubernetes cluster into an existing VNET, or create a new one. In addition, the HTTP routing feature can be enabled or disabled:

On the Monitoring tab, you have the option to enable container monitoring and link it to an existing Log Analytics workspace, or create a new one:

The following is the source from which to set your required tags:

Finally, the validation will check for any misconfigurations and create the Azure ARM template for the deployment. Clicking the Create button will start the deployment phase, which could run for several minutes or even longer depending on the chosen feature, and scale:

After the deployment has finished, the Kubernetes dashboard is available. You can view the Kubernetes dashboard by clicking on the View Kubernetes dashboard link, as shown in the following screenshot:

The dashboard looks something like the one shown in the following screenshot:

As you can see in the preceding screenshot, there are four steps to open the dashboard. At first, we will need to install the Azure CLI in its most current version using the statement that is mentioned in the following screenshot:

Afterward, the AKS CLI needs to be enabled. It is called kubectl.exe.

Finally, after setting all the parameters (and when you have performed steps 3 and 4 from the preceding task list), the following dashboard should open in a new browser window:

The preceding dashboard provides a way to monitor and administer your Azure Kubernetes environment, in general, from a GUI.

If a new Kubernetes version becomes available, you can easily update it from the Azure portal yourself with one click, as shown in the following screenshot:

If you need to scale your AKS hosts, this is quite easy too, as you can do it through the Azure portal. A maximum of 100 hosts with 3 vCPUs and 10.5 GB RAM per host is currently possible:

You can now upload your containers to your AKS-enabled Docker and have a huge scalable infrastructure with a minimum of administrative tasks and time for the implementation itself.

If you need to monitor AKS, the integration with Azure monitoring is integrated completely. By clicking the Monitor container health link, you will be directed to the following overview:

The Nodes tab provides the following information per node:

This not only gives a brief overview of the health status but also the number of containers and the load on the node itself.

The Controllers view provides detailed information on the AKS controller, its services, status, and uptime:

And finally, the Containers tab gives a deep overview of the health state of each container running in the infrastructure (system containers included):

By hitting the Search logs section, you can define your own custom Azure monitoring searches and integrate them in your custom portal:

To get everything up-and-running, the following to-do list gives a brief overview of all the tasks needed to provide an app within AKS:

Prepare the AKS App:
Create the container registry:
Create the Kubernetes cluster
Run the application in AKS:
Scale the application in AKS:
Update the application in AKS:

AKS has the following service quotas and limits:

Resource	Default limit
Max nodes per cluster	100
Max pods per node (basic networking with KubeNet)	110
Max pods per node (advanced networking with Azure CNI)	301
Max clusters per subscription	100

As you have seen, AKS in Azure provides great features with a minimum of administrative tasks.

Summary

In this tutorial, we learned the basics required to understand, deploy, and manage container services in a public cloud environment. Basically, the concept of containers is a great idea and surely the next step in virtualization that applications need to go to. Setting up the environment manually is quite complex, but by using the PaaS approach, the setup procedure is quite simple (because of automation) and allows you to just start using it.

To understand how to build robust cloud solutions on Azure, check out our book Implementing Azure Solutions – Second Edition