Back at Build, Microsoft announced a new feature for running Kubernetes in Azure: AKS Automatic. This feature aims to simplify and make using Kubernetes in Azure less overwhelming. Let’s look at this service and see how it works and whether it will be useful for you.

What is AKS Automatic

AKS Automatic is an extension to the existing AKS service. When you deploy an AKS cluster, you get a control plane instance and then several worker nodes to run your pods. The user needs to manage these resources in terms of updating, setting up auto-scaling, managing upgrades, and configuring settings for security and operations. Many different services in AKS can help manage these tasks, but it’s up to you to set these up and configure the cluster as you need.

With AKS automatic, it’s not a brand-new product. Instead, it’s an opinionated configuration of AKS that uses the existing services and pre-configures these to remove a lot of the decisions and work from the end user needed to manage the cluster. We’ll dive into these choices in a minute, but let’s look at an example.

For a default AKS cluster, Kubernetes upgrades are handled by the user by clicking the upgrade button in the portal (or CLI) to move from one Kubernetes version to another. An auto-upgrade feature is available, but it is off by default and down to the user to configure it. In AKS Automatic, auto upgrades are turned on by default, so the user does not need to do anything about Kubernetes updates; it will be handled for them. This also means that the user has no choice in getting upgrades, which is the trade-off you are buying into with AKS automatic.

How does AKS Automatic Work

As mentioned, AKS Automatic uses AKS’s existing functionality but in an opinionated configuration that reduces the management and operational complexity of working with Kubernetes. Let’s take a look at how some of these are configured.

• Monitoring is automatically configured with Container Insights turned on, and managed Prometheus and Grafana are set up and configured in the cluster.
• Nodes are provisioned using the Node Autoprovisioner and will scale up and down with demand (including scaling to zero). No manual provisioning is required. The horizontal and vertical autoscale are also automatically configured.
• AKS Automatic clusters use the standard tier for AKS, which includes an SLA and has a cost. No free option is available.
• All nodes use the Azure Linux OS. There is no choice to use a different OS.
• Nodes are configured in a restricted resource group, with resource locks to prevent manual changes and node auto-repair enabled to repair failing nodes.
• Cluster upgrades are configured using auto upgrades, with breaking change detection and maintenance windows enabled
• Azure RBAC is turned on, and workload identity and OIDC connect are automatically configured.
• Virtual Network integration is configured for the API server to ensure communication from nodes to the API server is over the private network.
• Image cleaner and AKS policy are configured.
• Managed NGINX is configured for ingress, and Azure NAT gateway is configured for egress, with the option to enable Istio.

As you can see, enabling all of these services on your own AKS cluster without AKS Automatic is possible. The benefit of AKS Automatic is that it configures them all for you, with an opinionated configuration designed to follow best practices and keep clusters secure and operating efficiently.

Why would I want to use AKS Automatic?

The primary use case for AKS automatic is when you want to hand over some of the configuration and management of your AKS cluster to Microsoft without the need to do all this work yourself. AKS and Kubernetes can be very complex solutions that require skills to manage, secure, and operate.

If you don’t need the full capabilities of Kubernetes, then one choice is to look at Azure Container Apps (ACA), which provides a managed Kubernetes-based solution without much of the management overhead. However, ACA abstracts many of the Kubernetes features and provides a more Azure-focused service; there is no Kubernetes API, no support for Custom Resource Definitions, etc. If you still need access to these Kubernetes primitives but want to reduce your management overhead, then AKS automatic could help you achieve this,

What issues does AKS Automatic have?

As with many new services, this one is in preview at the time of writing, and it has all the limitations of a preview service.

The biggest downside that AKS Automatic may have, depending on your viewpoint, is that it has an opinionated configuration for all the services mentioned above. If you agree with how these are configured, it’s no problem; however, if you disagree with these opinions and want to deviate from some of them, this may not be possible. By using AKS Automatic, you are buying into this pre-configured setup, and most settings cannot be changed. For example, nodes are provisioned only by utilising the auto-provisioner, and they will scale up and down based on the number of pods deployed and resources consumed. If you need to have a static amount of nodes deployed at all times, then this isn’t easily possible.

Finally, AKS Automatic may be more expensive, depending on your setup. AKS Automatic uses the standard SKU of AKS, so you will pay a monthly fee for the API server. It also deploys managed Prometheus and Grafana, which add to the cost. If you are already using these, then this may be fine, but for those trying to keep costs low, it may be an issue. Some of this may be offset by using the node auto-provisioner to scale down nodes when they are not in use.