Use OS NodeImage channel to receive weekly VHD updates

07-bootstrap-validation.md

@@ -26,14 +26,31 @@ GitOps allows a team to author Kubernetes manifest files, persist them in their
    echo AKS_CLUSTER_NAME: $AKS_CLUSTER_NAME
    ```
 
+1. Validate the current day2 strategy this baseline follows to upagrade the AKS cluster
+
+   ```bash
+   az aks show  -n $AKS_CLUSTER_NAME -g rg-bu0001a0008 --query "autoUpgradeProfile"
+   ```
+
+   ```outcome
+   {
+     "nodeOsUpgradeChannel": "NodeImage",
+     "upgradeChannel": "node-image"
+   }
+   ```
+
+   > This cluster is now receiving OS and Kubernetes updates on weekly bassis. For some workloads where it is imperative to be running always on top of the most secure OS version available, it is possible to opt-in for regular updates picking up the `SecurityPatch` channel instead.
+
+   > The update phase of the AKS cluster lifecycle belongs to day2 operations. Cluster ops will update their node images as regular as required for two main reasons, the first one is for the Kubernetes cluster version and the second one is to keep up with node-level OS security updates. This can be achieved manually for the greatest degree of control by placing requests against the Azure control plane. Alternatevely, ops team could opt-in to automatically update to the latest available version by configuring an udpate channel following a desired cadence combining this with a planned maintenance window. AKS provides with two configurable auto-upgrade channels dedicated to the two oforementioned update types. For more information, please refer to  [Upgrade options for Azure Kubernetes Service (AKS) clusters](https://learn.microsoft.com/azure/aks/upgrade-cluster). Nodepools in this AKS cluster span into multiple availability zones, so an important consideration is that automatic updates are conducted based on a best-effort zone balancing in node groups. Pod Disruption Budget and Nodes Max Surge are configured in this baseline to increase the Availabilty of the workload and as another attempt to prevent from unbalance zones.
+
 1. Validate there are no available image upgrades. As this AKS cluster was recently deployed, only a race condition between publication of new available images and the deployment image fetch could result into a different state.
 
    ```bash
    az aks nodepool get-upgrades -n npuser01 --cluster-name $AKS_CLUSTER_NAME -g rg-bu0001a0008 && \
    az aks nodepool show -n npuser01 --cluster-name $AKS_CLUSTER_NAME -g rg-bu0001a0008 --query nodeImageVersion
    ```
 
-   > The update phase of the AKS cluster lifecycle bleongs to day2 operations, cluster ops will be regularly updating the node images for two main reasons, the first one is for the Kubernetes cluster version and the second one is to keep up with node-level OS security updates. This can be achieved manually for the greatest degree of control by placing requests against the Azure control plane or alternatevely ops team could opt-in to allways update to the latest available version by configuring a planned maintenance window to perform this automatically. AKS provides with two configurable auto-upgrade channels dedicated to the two oforementioned update types. For more information, please refer to  [Upgrade options for Azure Kubernetes Service (AKS) clusters](https://learn.microsoft.com/azure/aks/upgrade-cluster). Nodepools in this AKS cluster span into multiple availability zones, so an important consideration is that automatic updates are conducted based on a best-effort zone balancing in node groups. Pod Disruption Budget and Nodes Max Surge are configured in this baseline to increase the Availabilty of the workload and as another attempt to prevent from unbalance zones.
+   > Typically, base node iamges doesn't contain a suffix with a date (i.e. `AKSUbuntu-2204gen2containerd`). If the `nodeImageVersion` value looks like `AKSUbuntu-2204gen2containerd-202402.26.0` a SecurityPatch or NodeImage upgrade has been applied to the aks node.
 
 1. Get AKS `kubectl` credentials.
 

cluster-stamp.bicep

@@ -1817,6 +1817,7 @@ resource mc 'Microsoft.ContainerService/managedClusters@2024-01-02-preview' = {
       enabled: false // Using Microsoft Entra Workload IDs for pod identities.
     }
     autoUpgradeProfile: {
+      nodeOSUpgradeChannel: 'NodeImage'
       upgradeChannel: 'node-image'
     }
     azureMonitorProfile: {