Merge pull request #233783 from MicrosoftDocs/main

4/7/2023 AM Publish

Author: Taojunshen

articles/active-directory/enterprise-users/licensing-service-plan-reference.md

@@ -52,7 +52,7 @@ Azure CNI powered by Cilium currently has the following limitations:
 
 ## Prerequisites
 
-* Azure CLI version 2.41.0 or later. Run `az --version` to see the currently installed version. If you need to install or upgrade, see [Install Azure CLI][/cli/azure/install-azure-cli].
+* Azure CLI version 2.41.0 or later. Run `az --version` to see the currently installed version. If you need to install or upgrade, see [Install Azure CLI](/cli/azure/install-azure-cli).
 * Azure CLI with aks-preview extension 0.5.135 or later.
 * If using ARM templates or the REST API, the AKS API version must be 2022-09-02-preview or later.
 
@@ -113,19 +113,19 @@ az network vnet subnet create -g <resourceGroupName> --vnet-name <vnetName> --na
 az network vnet subnet create -g <resourceGroupName> --vnet-name <vnetName> --name podsubnet --address-prefixes <address prefix, example: 10.241.0.0/16> -o none 
 ```
 
-Create the cluster using `--network-dataplane=cilium`:
+Create the cluster using `--network-dataplane cilium`:
 
 ```azurecli-interactive
 az aks create -n <clusterName> -g <resourceGroupName> -l <location> \
   --max-pods 250 \
   --network-plugin azure \
   --vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
   --pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
-  --network-dataplane=cilium
+  --network-dataplane cilium
 ```
 
 > [!NOTE]
-> The `--network-dataplane=cilium` flag replaces the deprecated `--enable-ebpf-dataplane` flag used in earlier versions of the aks-preview CLI extension.
+> The `--network-dataplane cilium` flag replaces the deprecated `--enable-ebpf-dataplane` flag used in earlier versions of the aks-preview CLI extension.
 
 ### Option 2: Assign IP addresses from an overlay network
 
@@ -136,7 +136,7 @@ az aks create -n <clusterName> -g <resourceGroupName> -l <location> \
   --network-plugin azure \
   --network-plugin-mode overlay \
   --pod-cidr 192.168.0.0/16 \
-  --network-dataplane=cilium
+  --network-dataplane cilium
 ```
 
 ## Frequently asked questions

articles/aks/azure-cni-powered-by-cilium.md

@@ -1,5 +1,5 @@
 ---
-title: Abort an Azure Kubernetes Service (AKS) long running operation (preview)
+title: Abort an Azure Kubernetes Service (AKS) long running operation 
 description: Learn how to terminate a long running operation on an Azure Kubernetes Service cluster at the node pool or cluster level.
 ms.topic: article
 ms.date: 3/23/2023
@@ -10,7 +10,7 @@ ms.date: 3/23/2023
 
 Sometimes deployment or other processes running within pods on nodes in a cluster can run for periods of time longer than expected due to various reasons. While it's important to allow those processes to gracefully terminate when they're no longer needed, there are circumstances where you need to release control of node pools and clusters with long running operations using an *abort* command.
 
-AKS now supports aborting a long running operation, which is currently in public preview. This feature allows you to take back control and run another operation seamlessly. This design is supported using the [Azure REST API](/rest/api/azure/) or the [Azure CLI](/cli/azure/).
+AKS now supports aborting a long running operation, which is now generally available. This feature allows you to take back control and run another operation seamlessly. This design is supported using the [Azure REST API](/rest/api/azure/) or the [Azure CLI](/cli/azure/).
 
 The abort operation supports the following scenarios:
 
@@ -20,11 +20,7 @@ The abort operation supports the following scenarios:
 
 ## Before you begin
 
-- The Azure CLI version 2.40.0 or later. Run `az --version` to find the version, and run `az upgrade` to upgrade the version. If you need to install or upgrade, see [Install Azure CLI][install-azure-cli].
-
-- The `aks-preview` extension version 0.5.102 or later.
-
-[!INCLUDE [preview features callout](./includes/preview/preview-callout.md)]
+- The Azure CLI version 2.47.0 or later. Run `az --version` to find the version, and run `az upgrade` to upgrade the version. If you need to install or upgrade, see [Install Azure CLI][install-azure-cli].
 
 ## Abort a long running operation
 

articles/aks/manage-abort-operations.md

@@ -49,7 +49,7 @@ For the past release history, see [Kubernetes history](https://en.wikipedia.org/
 | 1.23  | Dec 2021 | Jan 2022   | Apr 2022  | Apr 2023 |
 | 1.24 | Apr-22-22 | May 2022 | Jul 2022 | Jul 2023
 | 1.25 | Aug 2022 | Oct 2022 | Dec 2022 | Dec 2023
-| 1.26 | Dec 2022 | Feb 2023 | Mar 2023 | Mar 2024
+| 1.26 | Dec 2022 | Feb 2023 | Apr 2023 | Mar 2024
 | 1.27 | Apr 2023 | May 2023 | Jun 2023 | Jun 2024
 
 ## Alias minor version

articles/aks/supported-kubernetes-versions.md

@@ -299,6 +299,8 @@
           href: event-messaging-bindings.md
         - name: Event-driven scaling
           href: event-driven-scaling.md
+        - name: Target-based scaling
+          href: functions-target-based-scaling.md
         - name: Reliable event processing
           href: functions-reliable-event-processing.md
         - name: Concurrency

articles/azure-functions/TOC.yml

@@ -1,7 +1,7 @@
 ---
 title: Event-driven scaling in Azure Functions
 description: Explains the scaling behaviors of Consumption plan and Premium plan function apps.
-ms.date: 10/29/2020
+ms.date: 04/04/2023
 ms.topic: conceptual
 ms.service: azure-functions
 
@@ -10,33 +10,33 @@ ms.service: azure-functions
 
 In the Consumption and Premium plans, Azure Functions scales CPU and memory resources by adding more instances of the Functions host. The number of instances is determined on the number of events that trigger a function. 
 
-Each instance of the Functions host in the Consumption plan is limited to 1.5 GB of memory and one CPU.  An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. Function apps that share the same Consumption plan scale independently.  In the Premium plan, the plan size determines the available memory and CPU for all apps in that plan on that instance.  
+Each instance of the Functions host in the Consumption plan is limited, typically to 1.5 GB of memory and one CPU. An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. Function apps that share the same Consumption plan scale independently.  In the Premium plan, the plan size determines the available memory and CPU for all apps in that plan on that instance.  
 
 Function code files are stored on Azure Files shares on the function's main storage account. When you delete the main storage account of the function app, the function code files are deleted and can't be recovered.
 
 ## Runtime scaling
 
-Azure Functions uses a component called the *scale controller* to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.
+Azure Functions uses a component called the *scale controller* to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it uses [target-based scaling](functions-target-based-scaling.md).
 
-The unit of scale for Azure Functions is the function app. When the function app is scaled out, more resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually "scaled in" to zero when no functions are running within a function app.
+The unit of scale for Azure Functions is the function app. When the function app is scaled out, more resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually "scaled in" when no functions are running within a function app.
 
 ![Scale controller monitoring events and creating instances](./media/functions-scale/central-listener.png)
 
 ## Cold Start
 
-After your function app has been idle for a number of minutes, the platform may scale the number of instances on which your app runs down to zero. The next request has the added latency of scaling from zero to one. This latency is referred to as a _cold start_. The number of dependencies required by your function app can affect the cold start time. Cold start is more of an issue for synchronous operations, such as HTTP triggers that must return a response. If cold starts are impacting your functions, consider running in a Premium plan or in a Dedicated plan with the **Always on** setting enabled.   
+After your function app has been idle for a number of minutes, the platform may scale the number of instances on which your app runs down to zero. The next request has the added latency of scaling from zero to one. This latency is referred to as a _cold start_. The number of dependencies required by your function app can affect the cold start time. Cold start is more of an issue for synchronous operations, such as HTTP triggers that must return a response. If cold starts are impacting your functions, consider running in a [Premium plan](functions-premium-plan.md#eliminate-cold-starts) or in a Dedicated plan with the **Always on** setting enabled.
 
 ## Understanding scaling behaviors
 
-Scaling can vary based on several factors, and apps scale differently based on the trigger and language selected. There are a few intricacies of scaling behaviors to be aware of:
+Scaling can vary based on several factors, and apps scale differently based on the triggers and language selected. There are a few intricacies of scaling behaviors to be aware of:
 
-* **Maximum instances:** A single function app only scales out to a maximum of 200 instances. A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions.  You can [specify a lower maximum](#limit-scale-out) to throttle scale as required.
+* **Maximum instances:** A single function app only scales out to a [maximum allowed by the plan](functions-scale.md#scale). A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions.  You can [specify a lower maximum](#limit-scale-out) to throttle scale as required.
 * **New instance rate:** For HTTP triggers, new instances are allocated, at most, once per second. For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. Scaling is faster when running in a [Premium plan](functions-premium-plan.md).
-* **Scale efficiency:** For Service Bus triggers, use _Manage_ rights on resources for the most efficient scaling. With _Listen_ rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. To learn more about setting rights in Service Bus access policies, see [Shared Access Authorization Policy](../service-bus-messaging/service-bus-sas.md#shared-access-authorization-policies). For Event Hubs triggers, see the [this scaling guidance](#event-hubs-triggers). 
+* **Target-based scaling:** Target-based scaling provides a fast and intuitive scaling model for customers and is currently supported for Service Bus Queues and Topics, Storage Queues, Event Hubs, and Cosmos DB extensions. Make sure to review target-based scaling to understand their scaling behavior.
 
 ## Limit scale-out
 
-You may wish to restrict the maximum number of instances an app used to scale out.  This is most common for cases where a downstream component like a database has limited throughput.  By default, Consumption plan functions scale out to as many as 200 instances, and Premium plan functions will scale out to as many as 100 instances.  You can specify a lower maximum for a specific app by modifying the `functionAppScaleLimit` value.  The `functionAppScaleLimit` can be set to `0` or `null` for unrestricted, or a valid value between `1` and the app maximum.
+You may wish to restrict the maximum number of instances an app used to scale out. This is most common for cases where a downstream component like a database has limited throughput. By default, Consumption plan functions scale out to as many as 200 instances, and Premium plan functions will scale out to as many as 100 instances.  You can specify a lower maximum for a specific app by modifying the `functionAppScaleLimit` value.  The `functionAppScaleLimit` can be set to `0` or `null` for unrestricted, or a valid value between `1` and the app maximum.
 
 ```azurecli
 az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>
@@ -57,27 +57,6 @@ The following considerations apply for scale-in behaviors:
 * For Consumption plan function apps running on Windows, only apps created after May 2021 have drain mode behaviors enabled by default.
 * To enable graceful shutdown for functions using the Service Bus trigger, use version 4.2.0 or a later version of the [Service Bus Extension](functions-bindings-service-bus.md).
 
-## Event Hubs triggers
-
-This section describes how scaling behaves when your function uses an [Event Hubs trigger](functions-bindings-event-hubs-trigger.md) or an [IoT Hub trigger](functions-bindings-event-iot-trigger.md). In these cases, each instance of an event triggered function is backed by a single [EventProcessorHost](/dotnet/api/microsoft.azure.eventhubs.processor) instance. The trigger (powered by Event Hubs) ensures that only one [EventProcessorHost](/dotnet/api/microsoft.azure.eventhubs.processor) instance can get a lease on a given partition.
-
-For example, consider an event hub as follows:
-
-* 10 partitions
-* 1,000 events distributed evenly across all partitions, with 100 messages in each partition
-
-When your function is first enabled, there's only one instance of the function. Let's call the first function instance `Function_0`. The `Function_0` function has a single instance of [EventProcessorHost](/dotnet/api/microsoft.azure.eventhubs.processor) that holds a lease on all 10 partitions. This instance is reading events from partitions 0-9. From this point forward, one of the following happens:
-
-* **New function instances are not needed**: `Function_0` is able to process all 1,000 events before the Functions scaling logic take effect. In this case, all 1,000 messages are processed by `Function_0`.
-
-* **An additional function instance is added**: If the Functions scaling logic determines that `Function_0` has more messages than it can process, a new function app instance (`Function_1`) is created. This new function also has an associated instance of [EventProcessorHost](/dotnet/api/microsoft.azure.eventhubs.processor). As the underlying event hub detects that a new host instance is trying read messages, it load balances the partitions across the host instances. For example, partitions 0-4 may be assigned to `Function_0` and partitions 5-9 to `Function_1`.
-
-* **N more function instances are added**: If the Functions scaling logic determines that both `Function_0` and `Function_1` have more messages than they can process, new `Functions_N` function app instances are created.  Apps are created to the point where `N` is greater than the number of event hub partitions. In our example, Event Hubs again load balances the partitions, in this case across the instances `Function_0`...`Functions_9`.
-
-As scaling occurs, `N` instances is a number greater than the number of event hub partitions. This pattern is used to ensure [EventProcessorHost](/dotnet/api/microsoft.azure.eventhubs.processor) instances are available to obtain locks on partitions as they become available from other instances. You're only charged for the resources used when the function instance executes. In other words, you aren't charged for this over-provisioning.
-
-When all function execution completes (with or without errors), checkpoints are added to the associated storage account. When check-pointing succeeds, all 1,000 messages are never retrieved again.
-
 ## Best practices and patterns for scalable apps
 
 There are many aspects of a function app that impacts how it scales, including host configuration, runtime footprint, and resource efficiency.  For more information, see the [scalability section of the performance considerations article](performance-reliability.md#scalability-best-practices). You should also be aware of how connections behave as your function app scales. For more information, see [How to manage connections in Azure Functions](manage-connections.md).
@@ -97,5 +76,9 @@ Useful queries and information on how to understand your consumption bill can be
 
 ## Next steps
 
+To learn more, see the following articles:
+
++ [Improve the performance and reliability of Azure Functions](./performance-reliability.md)
++ [Azure Functions reliable event processing](./functions-reliable-event-processing.md)
 + [Azure Functions hosting options](functions-scale.md)
 

articles/azure-functions/event-driven-scaling.md

@@ -2,7 +2,7 @@
 title: Azure Cosmos DB trigger for Functions 2.x and higher
 description: Learn to use the Azure Cosmos DB trigger in Azure Functions.
 ms.topic: reference
-ms.date: 03/03/2023
+ms.date: 04/04/2023
 ms.devlang: csharp, java, javascript, powershell, python
 ms.custom: devx-track-csharp, devx-track-python, ignite-2022
 zone_pivot_groups: programming-languages-set-functions-lang-workers
@@ -14,6 +14,8 @@ The Azure Cosmos DB Trigger uses the [Azure Cosmos DB change feed](../cosmos-db/
 
 For information on setup and configuration details, see the [overview](./functions-bindings-cosmosdb-v2.md).
 
+Cosmos DB scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).
+
 ::: zone pivot="programming-language-python"
 Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.
 
@@ -372,7 +374,7 @@ For Python v2 functions defined using a decorator, the following properties on t
 |-------------|-----------------------------|
 |`arg_name` | The variable name used in function code that represents the list of documents with changes. |
 |`database_name`  | The name of the Azure Cosmos DB database with the collection being monitored. |
-|`collection_name`  | The name of the Azure CosmosDB collection being monitored. |
+|`collection_name`  | The name of the Azure Cosmos DB collection being monitored. |
 |`connection` | The connection string of the Azure Cosmos DB being monitored. |
 
 For Python functions defined by using *function.json*, see the [Configuration](#configuration) section.

articles/azure-functions/functions-bindings-cosmosdb-v2-trigger.md

@@ -3,7 +3,7 @@ title: Azure Service Bus trigger for Azure Functions
 description: Learn to run an Azure Function when as Azure Service Bus messages are created.
 ms.assetid: daedacf0-6546-4355-a65c-50873e74f66b
 ms.topic: reference
-ms.date: 03/06/2023
+ms.date: 04/04/2023
 ms.devlang: csharp, java, javascript, powershell, python
 ms.custom: "devx-track-csharp, devx-track-python"
 zone_pivot_groups: programming-languages-set-functions-lang-workers
@@ -16,6 +16,8 @@ Starting with extension version 3.1.0, you can trigger on a session-enabled queu
 
 For information on setup and configuration details, see the [overview](functions-bindings-service-bus.md).
 
+Service Bus scaling decisions for the Consumption and Premium plans are made based on target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).
+
 ::: zone pivot="programming-language-python"
 Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.