Catégorie : Kubernetes (AKS)

AKS | Built-in policy for planned maintenance


Exciting news! Microsoft introduced a brand-new built-in Azure Policy tailored for planned maintenance. This cutting-edge feature empowers you to proactively manage your system’s upkeep. With Planned Maintenance, you gain the ability to seamlessly schedule weekly maintenance windows, strategically executing updates while mitigating any potential workload disruptions. Once scheduled, upgrades gracefully take place exclusively within the designated window you’ve chosen, ensuring optimal efficiency.


AKS | Bring your own keys (BYOK) with Azure disks


The « Bring your own keys » (BYOK) capability for Azure disks is now supported in preview within AKS.

By default, data is safeguarded using Microsoft-managed keys, ensuring a high level of protection. For enhanced control over encryption keys, the option exists to provide customer-managed keys. This empowers you to utilize your chosen keys for encrypting both the operating system and data disks associated with your AKS clusters, thereby granting you an added layer of encryption customization.

Enabling encryption with customer-managed keys for the OS disk is exclusively possible during the initial creation phase of an AKS cluster. When opting to encrypt a node pool equipped with ephemeral OS disks using customer-managed keys, a key rotation process within Azure Key Vault necessitates the following steps:

  1. Decrease the node pool count to 0.
  2. Initiate the key rotation process.
  3. Restore the node pool count to its original value.

By adhering to these steps, you can effectively ensure the secure rotation of keys for enhanced encryption within your AKS environment.

Register the preview feature
az extension add --name aks-preview
az extension update --name aks-preview
az feature register --namespace "Microsoft.ContainerService" --name "EnableBYOKOnEphemeralOSDiskPreview"
az feature show --namespace "Microsoft.ContainerService" --name "EnableBYOKOnEphemeralOSDiskPreview"
az provider register --namespace Microsoft.ContainerService

Create a KeyVault
az group create -l myAzureRegionName -n myResourceGroup
az keyvault create -n myKeyVaultName -g myResourceGroup -l myAzureRegionName  --enable-purge-protection true

Create an instance of a DiskEncryptionSet
keyVaultId=$(az keyvault show --name myKeyVaultName --query "[id]" -o tsv)
keyVaultKeyUrl=$(az keyvault key show --vault-name myKeyVaultName --name myKeyName --query "[key.kid]" -o tsv)
az disk-encryption-set create -n myDiskEncryptionSetName  -l myAzureRegionName  -g myResourceGroup --source-vault $keyVaultId --key-url $keyVaultKeyUrl

Create a new AKS cluster and encrypt the OS disk
diskEncryptionSetId=$(az disk-encryption-set show -n mydiskEncryptionSetName -g myResourceGroup --query "[id]" -o tsv)
az group create -n myResourceGroup -l myAzureRegionName
az aks create -n myAKSCluster -g myResourceGroup --node-osdisk-diskencryptionset-id $diskEncryptionSetId --generate-ssh-keys --node-osdisk-type Managed
az aks create -n myAKSCluster -g myResourceGroup --node-osdisk-diskencryptionset-id $diskEncryptionSetId --generate-ssh-keys --node-osdisk-type Ephemeral --node-vm-size Standard_DS3_v2
az aks nodepool add --cluster-name $CLUSTER_NAME -g $RG_NAME --name $NODEPOOL_NAME --node-osdisk-type Ephemeral

Encrypt your AKS cluster data disk
kind: StorageClass
  name: byok
provisioner: # replace with "" if aks version is less than 1.21
  skuname: StandardSSD_LRS
  kind: managed
  diskEncryptionSetID: "/subscriptions/{myAzureSubscriptionId}/resourceGroups/{myResourceGroup}/providers/Microsoft.Compute/diskEncryptionSets/{myDiskEncryptionSetName}"

az aks get-credentials --name myAksCluster --resource-group myResourceGroup --output table
kubectl apply -f byok-azure-disk.yaml



AKS | Operation Abort


AKS now supports aborting a long running operation. The abort operation supports the following scenarios:

  • If a long running operation is stuck or suspected to be in a bad state or failing, the operation can be aborted provided it’s the last running operation on the Managed Cluster or agent pool.
  • If a long running operation is stuck or failing, that operation can be aborted.
  • An operation that was triggered in error can be aborted as long as the operation doesn’t reach a terminal state first.

The following example terminates an operation on a node pool on a specified cluster:

az aks nodepool operation-abort --resource-group myResourceGroup --cluster-name myAKSCluster --name myNodePool

The following example terminates an operation on a specified cluster:

az aks operation-abort --name myAKSCluster --resource-group myResourceGroup