Merge pull request #228717 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/aks/command-invoke.md

@@ -7,7 +7,7 @@ ms.date: 1/14/2022
 
 # Use `command invoke` to access a private Azure Kubernetes Service (AKS) cluster
 
-Accessing a private AKS cluster requires that you connect to that cluster either from the cluster virtual network, from a peered network, or via a configured private endpoint. These approaches require configuring a VPN, Express Route, deploying a *jumpbox* within the cluster virtual network, or creating a private endpoint inside of another virtual network. Alternatively, you can use `command invoke` to access private clusters without having to configure a VPN or Express Route. Using `command invoke` allows you to remotely invoke commands like `kubectl` and `helm` on your private cluster through the Azure API without directly connecting to the cluster. Permissions for using `command invoke` are controlled through the `Microsoft.ContainerService/managedClusters/runcommand/action` and `Microsoft.ContainerService/managedclusters/commandResults/read` roles.
+Accessing a private AKS cluster requires that you connect to that cluster either from the cluster virtual network, from a peered network, or via a configured private endpoint. These approaches require configuring a VPN, Express Route, deploying a *jumpbox* within the cluster virtual network, or creating a private endpoint inside of another virtual network. Alternatively, you can use `command invoke` to access private clusters without having to configure a VPN or Express Route. Using `command invoke` allows you to remotely invoke commands like `kubectl` and `helm` on your private cluster through the Azure API without directly connecting to the cluster. Permissions for using `command invoke` are controlled through the `Microsoft.ContainerService/managedClusters/runcommand/action` and `Microsoft.ContainerService/managedclusters/commandResults/read` actions.
 
 ## Prerequisites
 

articles/aks/workload-identity-migrate-from-pod-identity.md

@@ -120,7 +120,7 @@ If your application is using managed identity and still relies on IMDS to get an
 To update or deploy the workload, add these pod annotations only if you want to use the migration sidecar. You inject the following [annotation][pod-annotations] values to use the sidecar in your pod specification:
 
 * `azure.workload.identity/inject-proxy-sidecar` - value is `true` or `false`
-* `azure.workload.identity/proxy-sidecar-port` - value is the desired port for the proxy sidecar. The default value is `8080`.
+* `azure.workload.identity/proxy-sidecar-port` - value is the desired port for the proxy sidecar. The default value is `8000`.
 
 When a pod with the above annotations is created, the Azure Workload Identity mutating webhook automatically injects the init-container and proxy sidecar to the pod spec.
 
@@ -148,7 +148,7 @@ spec:
       runAsUser: 0
     env:
     - name: PROXY_PORT
-      value: "8080"
+      value: "8000"
   containers:
   - name: nginx
     image: nginx:alpine
@@ -157,7 +157,7 @@ spec:
   - name: proxy
     image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v0.13.0
     ports:
-    - containerPort: 8080
+    - containerPort: 8000
 ```
 
 This configuration applies to any configuration where a pod is being created. After updating or deploying your application, you can verify the pod is in a running state using the [kubectl describe pod][kubectl-describe] command. Replace the value `podName` with the image name of your deployed pod.
@@ -210,4 +210,4 @@ This article showed you how to set up your pod to authenticate using a workload
 
 <!-- EXTERNAL LINKS -->
 [kubectl-describe]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#describe
-[kubelet-logs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs
+[kubelet-logs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs

articles/azure-monitor/app/statsbeat.md

@@ -46,7 +46,8 @@ Statsbeat supports EU Data Boundary for Application Insights resources in the fo
 | Sweden                    | Sweden Central         | 
 | Switzerland               | Switzerland North      |
 | Switzerland               | Switzerland West       | 
-
+| United Kingdom            | United Kingdom South   |
+| United Kingdom            | United Kingdom West    |
 
 #### [Node](#tab/eu-node)
 
@@ -63,7 +64,9 @@ Statsbeat supports EU Data Boundary for Application Insights resources in the fo
 | Norway                    | Norway West            | 
 | Sweden                    | Sweden Central         | 
 | Switzerland               | Switzerland North      |
-| Switzerland               | Switzerland West       | 
+| Switzerland               | Switzerland West       |
+| United Kingdom            | United Kingdom South   |
+| United Kingdom            | United Kingdom West    |
 
 #### [Python](#tab/eu-python)
 
@@ -80,7 +83,9 @@ Statsbeat supports EU Data Boundary for Application Insights resources in the fo
 | Norway                    | Norway West            | 
 | Sweden                    | Sweden Central         | 
 | Switzerland               | Switzerland North      |
-| Switzerland               | Switzerland West       | 
+| Switzerland               | Switzerland West       |
+| United Kingdom            | United Kingdom South   |
+| United Kingdom            | United Kingdom West    |
 
 
 ---

articles/container-registry/monitor-service.md

@@ -15,9 +15,9 @@ When you have critical applications and business processes relying on Azure reso
 
 ## Monitor overview
 
-The **Overview** page in the Azure portal for each registry includes a brief view of recent resource usage and activity, such as push and pull operations. This high-level information is useful, but only a small amount of data is shown there. 
+The **Overview** page in the Azure portal for each registry includes a brief view of recent resource usage and activity, such as push and pull operations. This high-level information is useful, but only a small amount of data is shown there.
 
-:::image type="content" source="media/monitor-service/metrics-overview.png" alt-text="Registry metrics overview"::: 
+:::image type="content" source="media/monitor-service/metrics-overview.png" alt-text="Registry metrics overview":::
 
 ## What is Azure Monitor?
 
@@ -33,9 +33,9 @@ Start with the article [Monitoring Azure resources with Azure Monitor](../azure-
 
 The following sections build on this article by describing the specific data gathered for Azure Container Registry and providing examples for configuring data collection and analyzing this data with Azure tools.
 
-## Monitoring data 
+## Monitoring data
 
-Azure Container Registry collects the same kinds of monitoring data as other Azure resources that are described in [Monitoring data from Azure resources](../azure-monitor/essentials/monitor-azure-resource.md#monitoring-data). 
+Azure Container Registry collects the same kinds of monitoring data as other Azure resources that are described in [Monitoring data from Azure resources](../azure-monitor/essentials/monitor-azure-resource.md#monitoring-data).
 
 See [Monitoring Azure Container Registry data reference](monitor-service-reference.md) for detailed information on the metrics and logs created by Azure Container Registry.
 
@@ -56,12 +56,12 @@ The following image shows the options when you enable diagnostic settings for a
 
 The metrics and logs you can collect are discussed in the following sections.
 
-## Analyzing metrics (preview)
+## Analyzing metrics
 
-You can analyze metrics for an Azure container registry with metrics from other Azure services using metrics explorer by opening **Metrics** from the **Azure Monitor** menu. See [Getting started with Azure Metrics Explorer](../azure-monitor/essentials/metrics-getting-started.md) for details on using this tool. 
+You can analyze metrics for an Azure container registry with metrics from other Azure services using metrics explorer by opening **Metrics** from the **Azure Monitor** menu. See [Getting started with Azure Metrics Explorer](../azure-monitor/essentials/metrics-getting-started.md) for details on using this tool.
 
 > [!TIP]
-> You can also go to the metrics explorer by navigating to your registry in the portal. In the menu, select **Metrics (preview)** under **Monitoring**.
+> You can also go to the metrics explorer by navigating to your registry in the portal. In the menu, select **Metrics** under **Monitoring**.
 
 For a list of the platform metrics collected for Azure Container Registry, see [Monitoring Azure Container Registry data reference metrics](monitor-service-reference.md#metrics)  
 
@@ -74,7 +74,7 @@ The following Azure CLI commands can be used to get information about the Azure
 * [az monitor metrics list-definitions](/cli/azure/monitor/metrics#az-monitor-metrics-list-definitions) - List metric definitions and dimensions
 * [az monitor metrics list](/cli/azure/monitor/metrics#az-monitor-metrics-list) - Retrieve metric values
 
-### REST API 
+### REST API
 
 You can use the Azure Monitor REST API to get information programmatically about the Azure Container Registry metrics.
 
@@ -109,7 +109,7 @@ The following image shows sample output:
 
 :::image type="content" source="media/monitor-service/azure-monitor-query.png" alt-text="Query log data":::
 
-Following are queries that you can use to help you monitor your registry resource. 
+Following are queries that you can use to help you monitor your registry resource.
 
 ### Error events from the last hour
 
@@ -161,12 +161,10 @@ ContainerRegistryLoginEvents
 | project TimeGenerated, Identity, CallerIpAddress, ResultDescription
 ```
 
-
 ## Alerts
 
 Azure Monitor alerts proactively notify you when important conditions are found in your monitoring data. They allow you to identify and address issues in your system before your customers notice them. You can set alerts on [metrics](../azure-monitor/alerts/alerts-metric-overview.md), [logs](../azure-monitor/alerts/alerts-unified-log.md), and the [activity log](../azure-monitor/alerts/activity-log-alerts.md). Different types of alerts have benefits and drawbacks.
 
-
 <!-- only include next line if applications run on your service and work with App Insights. 
 
 If you are creating or running an application which run on <*service*> [Azure Monitor Application Insights](../azure-monitor/overview.md#application-insights) may offer additional types of alerts.
@@ -183,7 +181,7 @@ The following table lists common and recommended alert rules for Azure Container
 ### Example: Send email alert when registry storage used exceeds a value
 
 1. In the Azure portal, navigate to your registry.
-1. Select **Metrics (preview)** under **Monitoring**.
+1. Select **Metrics** under **Monitoring**.
 1. In the metrics explorer, in **Metric**, select **Storage used**.
 1. Select **New alert rule**.
 1. In **Scope**, confirm the registry resource for which you want to create an alert rule.
@@ -202,4 +200,4 @@ The following table lists common and recommended alert rules for Azure Container
 
 - See [Monitoring Azure Container Registry data reference](monitor-service-reference.md) for a reference of the metrics, logs, and other important values created by Azure Container Registry.
 - See [Monitoring Azure resources with Azure Monitor](../azure-monitor/essentials/monitor-azure-resource.md) for details on monitoring Azure resources.
-- See [Show registry usage](container-registry-skus.md#show-registry-usage) for information about how to get a snapshot of storage usage and other resource consumption in your registry.
+- See [Show registry usage](container-registry-skus.md#show-registry-usage) for information about how to get a snapshot of storage usage and other resource consumption in your registry.

articles/load-balancer/components.md

@@ -120,7 +120,7 @@ Basic load balancer doesn't support outbound rules.
 - Outbound flow from a backend VM to a frontend of an internal Load Balancer will fail.
 - A load balancer rule cannot span two virtual networks. All load balancer frontends and their backend instances must be in a single virtual network.  
 - Forwarding IP fragments isn't supported on load-balancing rules. IP fragmentation of UDP and TCP packets isn't supported on load-balancing rules. 
-- You can only have 1 Public Load Balancer and 1 internal Load Balancer per availability set
+- You can only have 1 Public Load Balancer (NIC based) and 1 internal Load Balancer (NIC based) per availability set. However, this constraint doesn't apply to IP-based load balancers.  
 
 ## Next steps
 

articles/logic-apps/logic-apps-gateway-install.md

@@ -44,22 +44,7 @@ For information about how to use the gateway with these services, see these arti
 
   * Later in the Azure portal, you need to use the same Azure account to create an Azure gateway resource that's associated with your gateway installation. You can link only one gateway installation and one Azure gateway resource to each other. However, you can use your Azure account to set up different gateway installations that are each associated with an Azure gateway resource. Your logic app workflows can then use these gateway resources in triggers and actions that can access on-premises data sources.
 
-* Local computer requirements:
-
-  **Minimum requirements**
-
-  * .NET Framework 4.8
-  * 64-bit version of Windows 7 or Windows Server 2008 R2 (or later)
-
-  **Recommended requirements**
-
-  * An eight-core CPU
-  * 8 GB of memory
-  * 64-bit version of Windows Server 2012 R2 or later
-  * Solid-state drive (SSD) storage for spooling
-
-  > [!NOTE]
-  > The gateway doesn't support Windows Server Core.
+* For local computer operating system and hardware requirements, see the [main guide for how to install the on-premises data gateway](/data-integration/gateway/service-gateway-install).
 
 * Related considerations: