Merge pull request #273628 from MicrosoftDocs/main

Publish to live, Sunday 4 AM PST, 4/28

Author: ttorble

.openpublishing.redirection.azure-kubernetes-service.json

@@ -351,12 +351,6 @@
             "redirect_url": "/cli/azure/aks#az_aks_create",
             "redirect_document_id": false
         },
-        {
-            "source_path_from_root": "/articles/aks/delete-cluster.md",
-            "redirect_url": "/cli/azure/aks#az_aks_delete",
-            "redirect_document_id": false
-        },
-
         {
             "source_path": "articles/aks/view-master-logs.md",
             "redirect_url": "/azure/aks/view-control-plane-logs",

.openpublishing.redirection.sentinel.json

@@ -246,6 +246,8 @@
           href: scale-cluster.md
         - name: Stop and start an AKS cluster
           href: start-stop-cluster.md
+        - name: Delete an AKS cluster
+          href: delete-cluster.md
         - name: Configure private clusters
           items:
            - name: Create a private cluster

articles/ai-services/openai/concepts/use-your-data.md

@@ -0,0 +1,67 @@
+---
+title: Delete an Azure Kubernetes Service (AKS) cluster
+description: Learn about deleting a cluster in Azure Kubernetes Service (AKS).
+ms.topic: overview
+ms.author: schaffererin
+author: schaffererin
+ms.date: 04/16/2024
+---
+
+# Delete an Azure Kubernetes Service (AKS) cluster
+
+This article outlines cluster deletion in Azure Kubernetes Service (AKS), including what happens when you delete a cluster, alternatives to deleting a cluster, and how to delete a cluster.
+
+## What happens when you delete a cluster?
+
+When you delete a cluster, the following resources are deleted:
+
+* The [node resource group][node-resource-group] and its resources, including:
+  * The virtual machine scale sets and virtual machines (VMs) for each node in the cluster
+  * The virtual network and its subnets for the cluster
+  * The storage for the cluster
+* The control plane and its resources
+* Any node instances in the cluster along with any pods running on those nodes
+
+## Alternatives to deleting a cluster
+
+Before you delete a cluster, consider **stopping the cluster**. Stopping an AKS cluster stops the control plane and agent nodes, allowing you to save on compute costs while maintaining all objects except standalone pods. When you stop a cluster, its state is saved and you can restart the cluster at any time. For more information, see [Stop an AKS cluster][stop-cluster].
+
+If you want to delete a cluster to change its configuration, you can instead use the [AKS cluster upgrade][upgrade-cluster] feature to upgrade the cluster to a different Kubernetes version or change the node pool configuration. For more information, see [Upgrade an AKS cluster][upgrade-cluster].
+
+## Delete a cluster
+
+> [!IMPORTANT]
+> **You can't recover a cluster after it's deleted**. If you need to recover a cluster, you need to create a new cluster and redeploy your applications.
+### [Azure CLI](#tab/azure-cli)
+
+Delete a cluster using the [`az aks delete`][az-aks-delete] command. The following example deletes the `myAKSCluster` cluster in the `myResourceGroup` resource group:
+
+```azurecli-interactive
+az aks delete --name myAKSCluster --resource-group myResourceGroup
+```
+
+### [Azure PowerShell](#tab/azure-powershell)
+
+Delete a cluster using the [`Remove-AzAks`][remove-azaks] command. The following example deletes the `myAKSCluster` cluster in the `myResourceGroup` resource group:
+
+```azurepowershell-interactive
+Remove-AzAksCluster -Name myAKSCluster -ResourceGroupName myResourceGroup
+```
+
+### [Azure portal](#tab/azure-portal)
+
+You can delete a cluster using the Azure portal. To delete a cluster, navigate to the **Overview** page for the cluster and select **Delete**. You can also delete a cluster from the **Resource group** page by selecting the cluster and then selecting **Delete**.
+
+---
+
+## Next steps
+
+For more information about AKS, see [Core Kubernetes concepts for AKS][core-concepts].
+
+<!-- LINKS -->
+[node-resource-group]: ./concepts-clusters-workloads.md#node-resource-group
+[stop-cluster]: ./start-stop-cluster.md
+[upgrade-cluster]: ./upgrade-cluster.md
+[az-aks-delete]: /cli/azure/aks#az_aks_delete
+[remove-azaks]: /powershell/module/az.aks/remove-azakscluster
+[core-concepts]: ./concepts-clusters-workloads.md

articles/ai-services/openai/media/use-your-data/azure-databases-and-ai-search.png

@@ -1,12 +1,12 @@
 ---
 title: Use a service principal with Azure Kubernetes Services (AKS)
 description: Learn how to create and manage a Microsoft Entra service principal with a cluster in Azure Kubernetes Service (AKS).
+author: tamram
+
 ms.topic: conceptual
 ms.subservice: aks-security
 ms.date: 06/27/2023
-author: schaffererin
-ms.author: schaffererin
-
+ms.author: tamram
 ms.custom: devx-track-azurepowershell, devx-track-azurecli
 
 #Customer intent: As a cluster operator, I want to understand how to create a service principal and delegate permissions for AKS to access required resources. In large enterprise environments, the user that deploys the cluster (or CI/CD system), may not have permissions to create this service principal automatically when the cluster is created.

articles/aks/TOC.yml

@@ -4,7 +4,7 @@ description: Learn how to migrate your App Service Environment v2 to App Service
 author: seligj95
 ms.topic: tutorial
 ms.custom: devx-track-azurecli
-ms.date: 4/12/2024
+ms.date: 4/26/2024
 ms.author: jordanselig
 ---
 # Use the side-by-side migration feature to migrate App Service Environment v2 to App Service Environment v3
@@ -258,7 +258,7 @@ az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties
 
 This step is your opportunity to test and validate your new App Service Environment v3. By default, traffic is sent to your App Service Environment v2 front ends. If you're using an ILB App Service Environment v3, you can test your App Service Environment v3 front ends by updating your private DNS zone with the new inbound IP address. If you're using an ELB App Service Environment v3, the process for testing is dependent on your specific network configuration. One simple method to test for ELB environments is to update your hosts file to use your new App Service Environment v3 inbound IP address. If you have custom domains assigned to your individual apps, you can alternatively update their DNS to point to the new inbound IP. Testing this change allows you to fully validate your App Service Environment v3 before initiating the final step of the migration where your old App Service Environment is deleted. If you're able to access your apps without issues that means you're ready to complete the migration.
 
-Once you confirm your apps are working as expected, you can redirect customer traffic to your new App Service Environment v3 by running the following command. This command also deletes your old environment.
+Once you confirm your apps are working as expected, you can redirect customer traffic to your new App Service Environment v3 by running the following command. This command also deletes your old environment. You have 14 days to complete this step. If you don't complete this step in 14 days, your migration is automatically reverted back to an App Service Environment v2. If you need more than 14 days to complete this step, contact support.
 
 If you find any issues or decide at this point that you no longer want to proceed with the migration, contact support to revert the migration. Don't run the DNS change command if you need to revert the migration. For more information, see [Revert migration](./side-by-side-migrate.md#redirect-customer-traffic-validate-your-app-service-environment-v3-and-complete-migration).
 

articles/aks/delete-cluster.md

@@ -204,7 +204,11 @@ The new inbound IP address is given so that you can set up new endpoints with se
 
 The final step is to redirect traffic to your new App Service Environment v3 and complete the migration. The platform does this change for you, but only when you initiate it. Before you do this step, you should review your new App Service Environment v3 and perform any needed testing to validate that it's functioning as intended. By default, traffic goes to your App Service Environment v2 front ends. If you're using an ILB App Service Environment v3, you can test your App Service Environment v3 front ends by updating your private DNS zone with the new inbound IP address. If you're using an ELB App Service Environment v3, the process for testing is dependent on your specific network configuration. One simple method to test for ELB environments is to update your hosts file to use your new App Service Environment v3 inbound IP address. If you have custom domains assigned to your individual apps, you can alternatively update their DNS to point to the new inbound IP. Testing this change allows you to fully validate your App Service Environment v3 before initiating the final step of the migration where your old App Service Environment is deleted.
 
-Once you're ready to redirect traffic, you can complete the final step of the migration. This step updates internal DNS records to point to the load balancer IP address of your new App Service Environment v3 and the front ends that were created during the migration. Changes are effective within a couple minutes. If you run into issues, check your cache and TTL settings. This step also shuts down your old App Service Environment and deletes it. Your new App Service Environment v3 is now your production environment.
+Once you're ready to redirect traffic, you can complete the final step of the migration. This step updates internal DNS records to point to the load balancer IP address of your new App Service Environment v3 and the front ends that were created during the migration. Changes are effective within a couple minutes. If you run into issues, check your cache and TTL settings. This step also shuts down your old App Service Environment and deletes it. Your new App Service Environment v3 is now your production environment. 
+
+> [!NOTE]
+> You have 14 days to complete this step. If you don't complete this step in 14 days, your migration is automatically reverted back to an App Service Environment v2. If you need more than 14 days to complete this step, contact support.
+>
 
 If you discover any issues with your new App Service Environment v3, don't run the command to redirect customer traffic. This command also initiates the deletion of your App Service Environment v2. If you find an issue, you can revert all changes and return to your old App Service Environment v2. The revert process takes 3 to 6 hours to complete. There's no downtime associated with this process. Once the revert process completes, your old App Service Environment is back online and your new App Service Environment v3 is deleted. You can then attempt the migration again once you resolve any issues.
 

articles/aks/kubernetes-service-principal.md

@@ -160,6 +160,7 @@ This table isn't an exhaustive list of changes.
 | `IDurableEntityContext.SignalEntity` | `TaskEntityContext.SignalEntity` |
 | `IDurableEntityContext.StartNewOrchestration` | `TaskEntityContext.ScheduleNewOrchestration` |
 | `IDurableEntityContext.DispatchAsync` | `TaskEntityDispatcher.DispatchAsync`. Constructor params removed. |
+| `IDurableOrchestrationClient.GetStatusAsync` | `DurableTaskClient.GetInstanceAsync` |
 
 #### Behavioral changes