Azure Kubernetes New (Preview) Features — Dec’20

4 min readDec 31, 2020

Our state (California) is still in lockdown state and as I continue to catch up on Azure updates, here are some AKS GA and preview features that came to my mind.

Support for Ephemeral OS Disks

Ephemeral OS disks are stored only on the host machine (node VM), just like a temporary disk. This provides lower read/write latency, along with faster node scaling and cluster upgrades. More importantly an ephemeral OS disk is already included in the VM’s price so you don’t incur any additional storage costs.

Using Ephemeral Disks on new AKS Clusters

az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --enable-managed-identity --node-osdisk-type Ephemeralaz aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --enable-managed-identity --node-osdisk-type managed

When the cluster is successfully provisioned, you should see the following output stating that the node pool is using ephemeral OS disks.

You can also add ephemeral disks to existing clusters too

az aks nodepool add --name ephemeral-nodepool --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type Ephemeral

GA: Ubuntu 18.04

AKS support for Ubuntu 18.04 as the Node Operating System (OS) is now generally available. Ubuntu 18.04 is a Long Term Support (LTS) release and contains important improvements and fixes at the OS level.

Node pools created on Kubernetes v1.18 or greater will now default to a required AKS Ubuntu 18.04 node image. Node pools on a supported Kubernetes version less than 1.18 will receive AKS Ubuntu 16.04 as the node image, but will be updated to AKS Ubuntu 18.04 once the node pool Kubernetes version is updated to v1.18 or greater.

GA: Mutate Default Storage Class

We can now use a different storage class in place off the default storage class to better fit your workload needs. For example, the scheduler could use a different storage class (LRS, GRS, ZRS etc..) instead of built-in default storage class to lower the cost for the targeted scenario. Refer to https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv#create-a-storage-class

Preview: AKS Cluster Start/Stop feature

Before introducing the AKS cluster start/stop feature you could still stop the VMSS-based or VM-based worker nodes to save compute costs. But this procedure was neither officially supported nor you had the guarantee that the cluster would be in a healthy state afterwards.

az aks start -g {resource-group} -n {cluster-name}az aks stop  -g {resource-group} -n {cluster-name}

This solution looks much cleaner and is fully supported.

GA: Azure Policy add on for AKS

This feature allows customers to audit and enforce policies to their Kubernetes resources. We can now set policies beyond the Azure Resource Manager level and drive in-depth compliance across pods, namespaces, ingress, and other Kubernetes resources.

Enable Azure Policy add-on to your AKS Cluster

#If you haven't already, register the following resource providers
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.PolicyInsights#enable the policy add-on
az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup#validate the add-on installation was successful.# azure-policy pod is installed in kube-system namespace 
kubectl get pods -n kube-system  # gatekeeper pod is installed in gatekeeper-system namespace 
kubectl get pods -n gatekeeper-systembash-3.2$ az aks show --query addonProfiles.azurepolicy -g myResourceGroup -n myAKSCluster
The behavior of this command has been altered by the following extension: aks-preview
{
  "config": {
    "version": "v2"
  },
  "enabled": true,
  "identity": {
    "clientId": "",
    "objectId": "",
    "resourceId": ""
  }
}

Refer to How to secure Pods with Azure Policy

Preview: Azure RBAC for Kubernetes Authorization

Today we can already leverage integrated authentication between Azure Active Directory (Azure AD) and AKS. With Azure role-based access control (RBAC) for Kubernetes Authorization, we can achieve unified management and access control across Azure Resources, AKS, and Kubernetes resources. When enabled, Azure AD users will be validated exclusively by Azure RBAC while regular Kubernetes service accounts are exclusively validated by Kubernetes RBAC.

Refer to this page for a deep dive

Preview: Azure Kubernetes Service Extension for Visual Studio Code

View your AKS clusters in the Kubernetes extension cloud explorer
Add AKS clusters to kubeconfig
Perform AKS Diagnostics checks on your AKS cluster
Run AKS Periscope within VS Code
Configure a CI/CD Pipeline targeting AKS cluster from within VSCode
Browse to all CI/CD Pipelines targeting AKS cluster

Refer to this page to know more https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-aks-tools

Conclusion

AKS Team continues to add exciting features for developers, administrators and Security teams. Check out the documentation for quick-starts, tutorials, and how-to guides. Read AKS best practices to understand the technical details, get hands-on with AKS, and learn about the options for setting up Kubernetes in production. Deepen your expertise by joining other AKS users on GitHub, at KubeCon, or at a Kubernetes Meetup near you. I can’t wait to see the new stuff in CY’2021.