Incorp changes

Author: sethmanheim

AKS-Hybrid/aks-hci-ip-address-planning.md

@@ -50,9 +50,32 @@ Continuing with this example, and adding it to the following table, you get:
 | AKS Arc VMs, K8s version upgrade and control plane IP  | Reserve 16 IP addresses | Make this reservation through IP pools in the Azure Local logical network. |
 | Load balancer IPs | 3 IP address for Kubernetes services, for Jane's voting application. | These IP addresses are used when you install a load balancer on cluster A. You can use the MetalLB Arc extension, or bring your own 3rd party load balancer. Ensure that this IP is in the same subnet as the Arc logical network, but outside the IP pool defined in the Arc VM logical network. |
 
+#### Example CLI commands for IP address reservation for Kubernetes clusters and applications
+
+This section describes the set of commands Jane runs for her scenario. First, create a logical network with an IP pool that has at least 16 IP addresses. We created the IP pool with 20 IP addresses to provide the option to scale on day N. For detailed information about parameter options in logical networks, see [`az stack-hci-vm network lnet create`](/cli/azure/stack-hci-vm/network/lnet#az-stack-hci-vm-network-lnet-create):
+
+```azurecli
+$ipPoolStart = "10.220.32.18"
+$ipPoolEnd = "10.220.32.37"
+az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
+```
+
+Next, create an AKS Arc cluster with the previous logical network:
+
+```azurecli
+az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
+```
+
+Now you can enable MetalLB load balancer with an IP pool of 3 IP addresses, in the same subnet as the Arc VM logical network. You can add more IP pools later if your application needs an increase. For detailed requirements, see the [MetalLB Arc extension overview](load-balancer-overview).
+
+```azurecli
+az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 172.25.28.145-172.25.28.147 --advertise-mode ARP
+```
+
 ### LNETs considerations for AKS clusters and Arc VMs
 
 Logical networks on Azure Local are used by both AKS clusters and Arc VMs. You can configure logical networks in one of the following 2 ways:
+
 - Share a logical network between AKS and Arc VMs.
 - Define separate logical networks for AKS clusters and Arc VMs.
 
@@ -66,7 +89,6 @@ Sharing a logical network between AKS and Arc VMs on Azure Local offers the bene
 | **Security considerations**    | Increased risk of cross-communication vulnerabilities if not properly segmented.  | Better security as each network can be segmented and isolated more strictly. |
 | **Impact of network failures** | A failure in the shared network can affect both AKS and Arc VMs simultaneously.   | A failure in one network affects only the workloads within that network, reducing overall risk. |
 
-
 ## IP address range allocation for pod CIDR and service CIDR
 
 ### Pod network CIDR

AKS-Hybrid/aks-hci-network-system-requirements.md

@@ -37,6 +37,8 @@ The following parameters are required in order to use a logical network for AKS
 | `--gateway`         | Gateway. The gateway IP address must be within the scope of the address prefix. Usage: `--gateway 10.220.32.16`. | ![Supported](media/aks-hybrid-networks/check.png) |
 | `--ip-allocation-method`         | The IP address allocation method. Supported values are "Static". Usage: `--ip-allocation-method "Static"`. | ![Supported](media/aks-hybrid-networks/check.png) |
 | `--vm-switch-name`     | The name of the VM switch. Usage: `--vm-switch-name "vm-switch-01"`. | ![Supported](media/aks-hybrid-networks/check.png) |
+| `--ip-pool-start`     | If you use MetalLB or any other third party load balancer in L2/ARP mode, we highly recommend using IP pools to separate AKS Arc IP requirements from load balancer IPs. This recommendation is to help avoid IP address conflicts that can lead to unintended and hard-to-diagnose failures. This value is the start IP address of your IP pool. The address must be in the range of the address prefix. Usage: `--ip-pool-start "10.220.32.18"`.  | Optional, but highly recommended. |
+| `--ip-pool-end`       | If you use MetalLB or any other third party load balancer in L2/ARP mode, we highly recommend using IP pools to separate AKS Arc IP requirements from load balancer IPs. This recommendation is to help avoid IP address conflicts that can lead to unintended and hard-to-diagnose failures. This value is the end IP address of your IP pool. The address must be in the range of the address prefix. Usage: `--ip-pool-end "10.220.32.38"`.  | Optional, but highly recommended. |
 
 ### Control plane IP
 

AKS-Hybrid/arc-gateway-aks-arc.md

@@ -38,7 +38,8 @@ For more information, see [how the Azure Arc gateway works](/azure/azure-arc/kub
 
 ## Before you begin
 
-- Ensure you've completed the [pre-requisites for creating AKS clusters on Azure Local](aks-hci-network-system-requirements.md)
+- Ensure you complete the [prerequisites for creating AKS clusters on Azure Local](aks-hci-network-system-requirements.md).
+- This article requires version 1.4.23 or later of Azure CLI. If you use Azure CloudShell, the latest version is already installed.
 - The following Azure permissions are required to create Arc gateway resources and manage their association with AKS Arc clusters:
   - `Microsoft.Kubernetes/connectedClusters/settings/default/write`
   - `Microsoft.hybridcompute/gateways/read`
@@ -64,23 +65,23 @@ Ensure your Arc gateway URL and all of the URLs below are allowed through your e
 
 ## Create an AKS Arc cluster with Arc gateway enabled
 
-Run the following command to create AKS Arc clusters with Arc gateway enabled
+Run the following command to create an AKS Arc cluster with the Arc gateway enabled:
 
 ```azurecli
 az aksarc create -n $clusterName -g $resourceGroup --custom-location $customlocationID --vnet-ids $arcVmLogNetId --aad-admin-group-object-ids $aadGroupID --gateway-id $gatewayId --generate-ssh-keys
 ```
 
 ## Update an AKS Arc cluster and enable Arc gateway
 
-Run the following command to create AKS Arc clusters with Arc gateway enabled:
+Run the following command to update an AKS Arc cluster and enable the Arc gateway:
 
 ```azurecli
 az aksarc update -n $clusterName -g $resourceGroup --gateway-id $gatewayId
 ```
 
 ## Disable Arc gateway on an AKS Arc cluster
 
-Run the following command to create AKS Arc clusters with Arc gateway enabled:
+Run the following command to disable an AKS Arc cluster:
 
 ```azurecli
 az aksarc update -n $clusterName -g $resourceGroup --disable-gateway

AKS-Hybrid/disable-windows-nodepool.md

@@ -22,28 +22,28 @@ This how-to article walks you through how to disable the Windows nodepool featur
 
 Before you begin, make sure you have the following prerequisites in place:
 
-- **Azure Local deployed**: This article is only applicable if you already deployed Azure Local. You cannot run the commands in this article before you deploy Azure Local. We currently do not support the ability to make this change before the initial Azure Local deployment.
-- **Custom Location ID**: Azure Resource Manager ID of the custom location. The custom location is configured during the Azure Local deployment. If you're in the Azure portal, go to the **Overview > Server** page in the Azure Stack HCI system resource. You should see a custom location for your cluster.
-- **Azure resource group**: The Azure resource group where Azure Local is deployed.
-- Azure RBAC permissions to update Azure Stack HCI configuration. Make sure you have the following roles. For more information, see [required permissions for deployment](/azure/azure-local/deploy/deployment-arc-register-server-permissions?tabs=powershell#assign-required-permissions-for-deployment):
+- **Azure Local deployed**. This article is only applicable if you already deployed Azure Local, release 2411. You cannot run the commands in this article before you deploy Azure Local release 2411. We currently do not support the ability to make this change before the initial Azure Local release 2411 deployment.
+- **Azure RBAC permissions to update Azure Local configuration**. Make sure you have the following roles. To learn more, visit [required permissions for deployment](/hci/deploy/deployment-arc-register-server-permissions?tabs=powershell#assign-required-permissions-for-deployment):
   - Azure Stack HCI Administrator
   - Reader
+- **Custom Location**. Name of the custom location. The custom location is configured during the Azure Local deployment. If you're in the Azure portal, go to the **Overview > Server** page in the Azure Local system resource. You should see a custom location for your cluster.
+- **Azure resource group**. The Azure resource group in which Azure Local is deployed.
 
-## Set environment variables
+## Recommended option: disable Windows nodepool from an Azure CloudShell session
 
 To help simplify configuration, the following steps define environment variables that are referenced in this article. Remember to replace the values shown with your own values.
 
-Set the custom location and the resource group values in environment variables.\:
+Set the custom location and the resource group values in environment variables:
 
 ```azurecli
-$customlocationID = <The custom location ARM ID for Azure Local>
-$resourceGroup = <The Azure resource group where Azure Local is deployed>
+$customlocationName = <The custom location name for Azure Local>
+$resourceGroup = <The Azure resource group in which Azure Local is deployed>
 ```
 
 Next, run the following command to obtain the `clusterName` parameter. This parameter is the name of the Arc Resource Bridge that you deployed on Azure Local:
 
 ```azurecli
-az customlocation show -n $customlocationID -g $resourceGroup --query hostResourceId
+az customlocation show -n $customlocationName -g $resourceGroup --query hostResourceId
 ```
 
 Expected output:
@@ -77,22 +77,23 @@ You should have two extensions installed on your custom location: AKS Arc and Ar
 $extensionName = <Name of AKS Arc extension you deployed on the custom location>
 ```
 
-Once you have the extension name, create variables for the following parameters.
+After you have the extension name, create variables for the following parameters, and then disable the Windows nodepool feature:
 
 ```azurecli
 $extensionVersion = "$(az k8s-extension show -n $extensionName  -g $resourceGroup -c $clusterName --cluster-type appliances --query version -o tsv)"
 $releaseTrain = "$(az k8s-extension show -n $extensionName -g $resourceGroup -c $clusterName --cluster-type appliances --query releaseTrain -o tsv)"
+az k8s-extension update --resource-group $resourceGroup --cluster-name $clusterName --cluster-type appliances --name $extensionName --version $extensionVersion --release-train $releaseTrain --config disable-windows-nodepool=true --yes
 ```
 
-## Update the AKS Arc extension to disable the Windows nodepool feature
+## Alternate option: disable Windows nodepool after connecting to an Azure Local physical node via Remote Desktop
 
-After you set the environment variables, you can run the following command from an Azure CloudShell session to update the AKS Arc k8s extension. This command disables the Windows nodepool feature and deletes any associated VHDs:
+If for some reason you're not able to use Azure CloudShell or a machine with connectivity to Azure in order to disable Windows nodepool, you can disable Windows nodepool after connecting to any one of the Azure Local physical nodes with Remote Desktop. You must first sign in to Azure:
 
 ```azurecli
 az k8s-extension update --resource-group $resourceGroup --cluster-name $clusterName --cluster-type appliances --name $extensionName --version $extensionVersion --release-train $releaseTrain --config disable-windows-nodepool=true --yes 
 ```
 
-## Validate if the Windows nodepool feature is disabled
+### Validate if the Windows nodepool feature is disabled
 
 You can check if the configuration settings were applied by running `az k8s-extension show`, as follows:
 
@@ -111,7 +112,7 @@ Expected output:
 Next, check if Windows nodepools were disabled by running the following command:
 
 ```azurecli
-az aksarc get-versions --resource-group $resourceGroup --custom-location $customlocationID
+az aksarc get-versions --resource-group $resourceGroup --custom-location $customlocationName
 ```
 
 The output for `osType=Windows` should say "Windows nodepool feature is disabled" and the `ready` state should be `false`, for each Kubernetes version option:
@@ -154,5 +155,5 @@ The Windows VHDs that were previously downloaded are automatically deleted if th
 
 ## Next steps
 
-- [What's new in AKS on Azure Stack HCI](aks-overview.md)
+- [What's new in AKS on Azure Local](aks-overview.md)
 - [Create AKS clusters](aks-create-clusters-cli.md)