updated versioning

Author: Nickomang

articles/aks/use-byo-cni.md

@@ -3,17 +3,19 @@ title: Bring your own Container Network Interface (CNI) plugin
 description: Learn how to utilize Azure Kubernetes Service with your own Container Network Interface (CNI) plugin
 services: container-service
 ms.topic: article
-ms.date: 05/16/2022
+ms.date: 3/30/2022
 ---
 
-# Bring your own Container Network Interface (CNI) plugin with Azure Kubernetes Service (AKS)
+# Bring your own Container Network Interface (CNI) plugin with Azure Kubernetes Service (AKS) (PREVIEW)
 
 Kubernetes does not provide a network interface system by default; this functionality is provided by [network plugins][kubernetes-cni]. Azure Kubernetes Service provides several supported CNI plugins. Documentation for supported plugins can be found from the [networking concepts page][aks-network-concepts].
 
 While the supported plugins meet most networking needs in Kubernetes, advanced users of AKS may desire to utilize the same CNI plugin used in on-premises Kubernetes environments or to make use of specific advanced functionality available in other CNI plugins.
 
 This article shows how to deploy an AKS cluster with no CNI plugin pre-installed, which allows for installation of any third-party CNI plugin that works in Azure.
 
+[!INCLUDE [preview features callout](./includes/preview/preview-callout.md)]
+
 ## Support
 
 BYOCNI has support implications - Microsoft support will not be able to assist with CNI-related issues in clusters deployed with BYOCNI. For example, CNI-related issues would cover most east/west (pod to pod) traffic, along with `kubectl proxy` and similar commands. If CNI-related support is desired, a supported AKS network plugin can be used or support could be procured for the BYOCNI plugin from a third-party vendor.
@@ -22,8 +24,8 @@ Support will still be provided for non-CNI-related issues.
 
 ## Prerequisites
 
-* For ARM/Bicep, use at least template version `2022-01-02-preview`
-* For Azure CLI, use at least version `2.37.0`
+* For ARM/Bicep, use at least template version 2022-01-02-preview
+* For Azure CLI, use at least version 0.5.55 of the `aks-preview` extension
 * The virtual network for the AKS cluster must allow outbound internet connectivity.
 * AKS clusters may not use `169.254.0.0/16`, `172.30.0.0/16`, `172.31.0.0/16`, or `192.0.2.0/24` for the Kubernetes service address range, pod address range, or cluster virtual network address range.
 * The cluster identity used by the AKS cluster must have at least [Network Contributor](../role-based-access-control/built-in-roles.md#network-contributor) permissions on the subnet within your virtual network. If you wish to define a [custom role](../role-based-access-control/custom-roles.md) instead of using the built-in Network Contributor role, the following permissions are required:
@@ -34,6 +36,15 @@ Support will still be provided for non-CNI-related issues.
 
 ## Cluster creation steps
 
+### Install the aks-preview CLI extension
+
+```azurecli-interactive
+# Install the aks-preview extension
+az extension add --name aks-preview
+# Update the extension to make sure you have the latest version installed
+az extension update --name aks-preview
+```
+
 ### Deploy a cluster
 
 # [Azure CLI](#tab/azure-cli)

articles/aks/use-multiple-node-pools.md

@@ -124,6 +124,9 @@ The following example output shows that *mynodepool* has been successfully creat
 
 A workload may require splitting a cluster's nodes into separate pools for logical isolation. This isolation can be supported with separate subnets dedicated to each node pool in the cluster. This can address requirements such as having non-contiguous virtual network address space to split across node pools.
 
+> [!NOTE]
+> Make sure to use Azure CLI version `2.35.0` or later.
+
 #### Limitations
 
 * All subnets assigned to nodepools must belong to the same virtual network.