Hi,

In this article, I would like to share with you, how you can enable ephemeral os disk with your AKS cluster. This feature is still in public preview. Please don’t use use this feature with your production cluster.

By default, the operating system disk for an Azure virtual machine is automatically replicated to Azure storage to avoid data loss should the VM need to be relocated to another host. However, since containers aren’t designed to have local state persisted, this behavior offers limited value while providing some drawbacks, including slower node provisioning and higher read/write latency.

az feature register --name EnableEphemeralOSDiskPreview --namespace Microsoft.ContainerService

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableEphemeralOSDiskPreview')].{Name:name,State:properties.state}"

az provider register --namespace Microsoft.ContainerService

az extension add --name aks-preview

az extension update --name aks-preview

Configure the cluster to use Ephemeral OS disks when the cluster is created. Use the --aks-custom-headers flag to set Ephemeral OS as the OS disk type for the new cluster.

az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --aks-custom-headers EnableEphemeralOSDisk=true

Configure a new node pool to use Ephemeral OS disks. Use the --aks-custom-headers flag to set as the OS disk type as the OS disk type for that node pool.

az aks nodepool add --name ephemeral --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --aks-custom-headers EnableEphemeralOSDisk=true

Maxime.

[English below]

Bonjour,

Dans cet article je vais vous présenter comment changer le nom du deuxième ressource group créé pour les nodes de votre cluster AKS.

Par défaut, AKS nomme le groupe de ressources de noeuds: MC_resourcegroupname_clustername_location, mais avec l’aide de la commande ci-dessous vous pouvez changer ce nom :

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Je vous recommande fortement d’utiliser des conventions de nommage de vos ressources, notamment afin d’assurer une bonne gouvernance de votre infastructure. Pour cela vous pouvez utiliser le service Azure Policy afin d’appliquer vos conventions de nommage (tagging stategy).

Maxime.

—

Hi,

In this article, I would like to share with you, how you can customize the name of the AKS node resource group. When you deploy an Azure Kubernetes Service cluster in Azure, a second resource group gets created for the worker nodes.

By default, AKS will name the node resource group: MC_resourcegroupname_clustername_location but you can also provide your own name.

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

I recommend you to use a tagging strategy for all your Azure ressources, this can help you to manage your cost and security governance. Please do not hesitate to use the Azure policy to enforce your tagging strategy.

Maxime.

Hi,

In this article, I would like to share with you how we can create an AKS cluster with Containerd.

Containerd is an OCI compliant core container runtime designed to be embedded into larger systems. It provides the minimum set of functionality to execute containers and manages images on a node. It was initiated by Docker Inc. and donated to CNCF in March of 2017.

A container runtime is software that executes containers and manages container images on a node. The runtime helps abstract away sys-calls or operating system (OS) specific functionality to run containers on Linux or Windows. Today AKS is using Moby (upstream docker) as its container runtime.

With a containerd-based node and node pools, instead of talking to the dockershim, the kubelet will talk directly to containerd via the CRI (container runtime interface) plugin, removing extra hops on the flow when compared to the Docker CRI implementation. As such, you’ll see better pod startup latency and less resource (CPU and memory) usage.

By using containerd for AKS nodes, pod startup latency improves and node resource consumption by the container runtime decreases. These improvements are enabled by this new architecture where kubelet talks directly to containerd through the CRI plugin while in Moby/docker architecture kubelet would talk to the dockershim and docker engine before reaching containerd, thus having extra hops on the flow.

# - Requirements
az extension add --name aks-preview 
az extension list

az feature register --name UseCustomizedContainerRuntime --namespace Microsoft.ContainerService 
az feature register --name UseCustomizedUbuntuPreview --namespace Microsoft.ContainerService

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/UseCustomizedContainerRuntime')].{Name:name,State:properties.state}" 
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/UseCustomizedUbuntuPreview')].{Name:name,State:properties.state}"

az provider register --namespace Microsoft.ContainerService

# - Ressource Group + AKS Cluster creation
az group create --name aksmaxime --location eastus

az aks create --name aksclustermax --resource-group aksmaxime --aks-custom-headers CustomizedUbuntu=aks-ubuntu-1804,ContainerRuntime=containerd

az aks get-credentials --resource-group aksmaxime --name aksclustermax --overwrite-existing

kubectl get nodes -o wide

Maxime.