With Kubernetes there are a ton of options out there for where to run your Kubernetes. For example, you can run it on servers in your own data center, run it on servers in cloud, or use a Kubernetes managed service as all of the major cloud providers have a managed Kubernetes offering now. In this post we are going to focus on when to use Azure Kubernetes Service (AKS) or run your own Kubernetes cluster.
Latest posts by Steve Buchanan (see all)

In the world of tech, containers have been exploding in regards to adoption. When organizations get to running critical mass of containers in production, they typically need a container orchestration platform. There are many orchestration platforms in the market. However, Kubernetes has risen to the top of the orchestration pack as the defacto standard. Unless you have been living under a rock chances are that you have heard about Kubernetes (K8s). Also, there is a strong chance that your organization has decided to adopt containers and Kubernetes.

Kubernetes was created by Google and designed to work in your environment of choice such as on-premises, or in public cloud. With Kubernetes there is a lot to learn and many decisions to be made; one of the key decision areas is "should I deploy my own Kubernetes cluster or use a Kubernetes service?". In this post we are going to explore this decision.

AKS in a Nutshell ^

First of all, lets briefly talk about what AKS is. It stands for Azure Kubernetes Service. It is a managed Kubernetes service from Microsoft in Azure and in my opinion is awesome. In a nutshell AKS removes the complexity of deploying and running your own Kubernetes clusters offloading majority of complexity to Microsoft.

To be clear with AKS there is still parts of the Kubernetes cluster that you need to manage. With AKS Microsoft manages the master nodes and you are responsible to manage the worker/agent nodes. The master nodes are the core nodes that power your Kubernetes cluster. The worker AKA agent nodes run the pods (container/s) that power your workloads.

Example of Deployment workloads running on an AKS cluster

Example of Deployment workloads running on an AKS cluster

Example of Deployment workloads running on an AKS cluster

With AKS deploying a Kubernetes cluster has been simplified. You can deploy an AKS cluster from the Azure Portal, an ARM Template, or code (Azure CLI, PowerShell, or Terraform). When you deploy an AKS cluster the master and agent nodes are deployed and configured for you along with configuration of the cluster.

Also, ancillary items are deployed and configured such as networking, integration with Azure Active Directory for RBAC, monitoring and more. Ongoing maintenance and operations of the master nodes is handled for you but you are responsible for the agent nodes for example node scaling, upgrading the K8s version (Microsoft does simplify this but you chose when to do it.) etc.

Also, with AKS a key point is that you only pay for the agent nodes within your cluster. You do not pay for the AKS service itself or the master nodes. We could do an entire blog post or blog posts about AKS alone but we are not going to do that here. For full a previous blog post on "Getting Started with AKS".

Organizations will typically use AKS for the following scenarios:

  • Centralized and simplified configuration and management of microservice based applications.
  • Combining DevOps and Kubernetes together for GitOps and more efficacy in CI/CD pipelines and Infrastructure as Code (IaC).
  • Ease of scale up or out on a moment's notice in automated ways.
  • Migration of existing applications to containers and microservices.

What AKS is and what it's not ^

Before we go any further let's take some time to explore some key points on what AKS is and what it is not. This will help when decide to adopt AKS or deploy your own K8s cluster. Here is a table breaking down these key points:

What AKS has

  • Get started with AKS faster
    • You can deploy AKS in the Azure portal quickly and get up and running with your containers in no time. Keep in mind there is a difference between getting AKS running and doing it the right way by planning before you deploy.
  • Reduces K8s deployment complexity
    • Deploying your own Kubernetes cluster is complex.
  • Reduces K8s operations complexity
    • Managing your own Kubernetes cluster can be complex.
  • Makes K8s version upgrades easier
    • AKS streamlines the AKS version upgrade process.
  • Gives you first hand integration with needed ancillary services
    • Running Kubernetes needs more technology beyond just the cluster itself. Some of the additional technology you will need for your K8s cluster is there as an add-on with AKS in Azure. For example, with AKS integrating with Azure networking, identity management provider, Azure Container Registry, Azure Key Vault for secrets management, Security Center, Azure Policy for K8s policy enforcement, and monitoring via Azure Monitor can be added on. Also, you can use Azure Container Instances as virtual nodes with your AKS cluster.
  • Option for an Uptime SLA
    • When you deploy your own AKS you will not get an SLO or SLA you will be responsible for this.
    • By default, AKS has an SLO of 99.5% from Microsoft. As an option Microsoft will give you a guaranteed Uptime SLA of 99.95% for your AKS cluster. The Uptime SLA comes at an additional cost. Go here for More details about the Uptime SLA.

What AKS doesn't have

  • Completely free
    • Keep in mind you pay for the agent nodes but not the master nodes. AKS is not free but does help keep the cost down.
  • Full managed K8s service
    • You will still be responsible for certain parts of your K8s cluster.
  • No need to understand Kubernetes
    • You definitely need to understand Kubernetes regardless if you have your own or a managed Kubernetes service. With AKS you will still need to manage certain aspects of your cluster. Also, you will need to understand K8s so you can deploy your apps to it etc.
  • Full control of master nodes
    • With AKS you will not have full control of the master nodes in the cluster. These are abstracted away.

Own Kubernetes cluster vs. Azure Kubernetes Service ^

The answer that no one wants to here is "It depends". However, in this case it really depends. Deploying and operating your own K8s cluster is going to be more complex and more work. Also, the ancillary technology needed such as networking, monitoring, identity management is going to be more complex to setup.

If you are worried about vendor lock-in with AKS its really a non-issue. You should be able to take your container workloads and even the additional items such as secrets, configmaps etc. can be taken to other K8s clusters you run yourself or even with other services. The cost of running AKS is actually going to be a little less as you won't pay for the master nodes. If you roll your own K8s cluster and run it on cloud you will be paying for the master node VMs and the agent node VMs.

It basically boils down to whether you require full control of the master nodes or not. If you do need full control of the master nodes you should roll your own K8s cluster. If you don’t need full control of the master nodes AKS is the best option to help you get going with K8s faster, offload most of the overhead of deploying and operating it, as well as being able to dedicate more energy to running your workloads vs management of the K8s cluster.

More information ^

By the end of this post if you have decided to jump into the Kubernetes space kudos. This is only the first step. There will be much more to learn. Here are some resources to help you along the way as you embark on your journey with K8s and AKS:

Subscribe to 4sysops newsletter!

0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account