Top freshness pass for AKS Arc

sethmanheim · sethmanheim · commit caa1f9544a5c · 2025-07-03T09:58:01.000-07:00
diff --git a/AKS-Arc/concepts-security-access-identity.md b/AKS-Arc/concepts-security-access-identity.md
@@ -3,7 +3,7 @@ title: Access and identity options for Azure Kubernetes Service (AKS) Arc
 description: Learn about options in access and identity management on a Kubernetes cluster in AKS on Azure Local.
 author: sethmanheim
 ms.topic: how-to
-ms.date: 07/30/2024
+ms.date: 07/03/2025
 ms.author: sethm
 ms.lastreviewed: 07/30/2024
 ms.reviewer: leslielin
@@ -41,7 +41,7 @@ For more information, see [Using Kubernetes RBAC authorization](https://kubernet
 
 #### Roles
 
-Before assigning permissions to users with Kubernetes RBAC, you define user permissions as a *role*. Grant permissions within a Kubernetes namespace using roles.
+Before assigning permissions to users with Kubernetes RBAC, you define user permissions as a role. Grant permissions within a Kubernetes namespace using roles.
 
 Kubernetes roles grant permissions; they don't deny permissions. To grant permissions across the entire cluster or to cluster resources outside a given namespace, you can use *ClusterRoles*.
 
@@ -51,7 +51,7 @@ A ClusterRole grants and applies permissions to resources across the entire clus
 
 ### RoleBindings and ClusterRoleBindings
 
-Once you define roles to grant permissions to resources, you assign those Kubernetes RBAC permissions with a *RoleBinding*. If your AKS cluster [integrates with Microsoft Entra ID](#microsoft-entra-integration), RoleBindings grant permissions to Microsoft Entra users to perform actions within the cluster. See [Control access using Microsoft Entra ID and Kubernetes RBAC](kubernetes-rbac-local.md)
+Once you define roles to grant permissions to resources, you assign those Kubernetes RBAC permissions with a *RoleBinding*. If your AKS cluster [integrates with Microsoft Entra ID](#microsoft-entra-integration), RoleBindings grant permissions to Microsoft Entra users to perform actions within the cluster. See [Control access using Microsoft Entra ID and Kubernetes RBAC](kubernetes-rbac-local.md).
 
 #### RoleBindings
 
@@ -82,7 +82,7 @@ Azure Role-based Access Control (RBAC) is an authorization system built on [Azur
 
 With Azure RBAC, you create a *role definition* that outlines the permissions to be applied. You then assign a user or group this role definition via a *role assignment* for a particular *scope*. The scope can be an individual resource, a resource group, or across the subscription.
 
-For more information, see [What is Azure role-based access control (Azure RBAC)?](/azure/role-based-access-control/overview)
+For more information, see [What is Azure role-based access control (Azure RBAC)?](/azure/role-based-access-control/overview).
 
 There are two required levels of access to fully operate an AKS Arc cluster:
 
@@ -113,7 +113,7 @@ In this scenario, you use Azure RBAC mechanisms and APIs to assign users built-i
 With this feature, you not only give users permissions to the AKS resource across subscriptions, but you also configure the role and permissions for inside each of those clusters controlling Kubernetes API access. There are four built-in roles available for this data plane action, each with its own scope of permissions, [as described in the built-in roles](#built-in-roles) section.
 
 > [!IMPORTANT]
-> You must enable Azure RBAC for Kubernetes authorization before doing role assignment. For more details and step by step guidance, see [Use Azure RBAC for Kubernetes authorization](azure-rbac-local.md).
+> You must enable Azure RBAC for Kubernetes authorization before doing role assignment. For more details and step-by-step guidance, see [Use Azure RBAC for Kubernetes authorization](azure-rbac-local.md).
 
 ### Built-in roles
 
diff --git a/AKS-Arc/includes/built-in-roles.md b/AKS-Arc/includes/built-in-roles.md
@@ -3,13 +3,13 @@ author: sethmanheim
 ms.author: sethm
 ms.service: azure-stack
 ms.topic: include
-ms.date: 07/31/2024
+ms.date: 07/03/2025
 ms.reviewer: leslielin
 ms.lastreviewed: 07/31/2024
 
 ---
 
-AKS enabled by Arc provides the following five built-in roles. They are similar to the [Kubernetes built-in roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) with a few differences, such as supporting CRDs. See the full list of actions allowed by each [Azure built-in role](/azure/role-based-access-control/built-in-roles).
+AKS Arc provides the following five built-in roles. They are similar to the [Kubernetes built-in roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles), with a few differences, such as supporting CRDs. See the full list of actions allowed by each [Azure built-in role](/azure/role-based-access-control/built-in-roles).
 
 | Role                                                     | Description                                              |
 | ------------------------------------------------------------ | ------------------------------------------------------------ |
diff --git a/AKS-Arc/known-issues-installation.yml b/AKS-Arc/known-issues-installation.yml
@@ -7,7 +7,7 @@ metadata:
   ms.service: azure-kubernetes-service-hybrid
   ms.custom: devx-track-azurepowershell
   ms.topic: faq
-  ms.date: 07/26/2024
+  ms.date: 07/03/2025
 title: Resolve issues and errors during an AKS Arc installation
 summary: |
   **Applies to: AKS on Windows Server**
diff --git a/AKS-Arc/load-balancer-overview.md b/AKS-Arc/load-balancer-overview.md
@@ -2,7 +2,7 @@
 title: Overview of MetalLB for Kubernetes clusters
 description: Learn the basic concepts of MetalLB load balancing for AKS enabled by Arc Kubernetes clusters.
 ms.topic: concept-article
-ms.date: 07/17/2024
+ms.date: 07/03/2025
 author: sethmanheim
 ms.author: sethm
 ms.reviewer: xinyuhe
@@ -13,12 +13,12 @@ ms.lastreviewed: 04/02/2024
 
 [!INCLUDE [hci-applies-to-23h2](includes/hci-applies-to-23h2.md)]
 
-When you set up your AKS Arc cluster, you need a way to make your services accessible outside the cluster. The `LoadBalancer` type is ideal for this accessibility, but the external IP remains pending. The **extension for MetalLB for Azure Arc enabled Kubernetes** is a tool that allows you to generate external IPs for your applications and services. Arc-enabled Kubernetes clusters can integrate with [MetalLB](https://metallb.universe.tf/configuration/) using the extension for MetalLB for Azure Arc enabled Kubernetes.
+When you set up your AKS Arc cluster, you need a way to make your services accessible outside the cluster. The `LoadBalancer` type is ideal for this accessibility, but the external IP remains pending. The *MetalLB extension for Azure Arc enabled Kubernetes* is a tool that allows you to generate external IPs for your applications and services. Arc-enabled Kubernetes clusters can integrate with [MetalLB](https://metallb.universe.tf/configuration/) using the extension for MetalLB for Azure Arc enabled Kubernetes.
 
-To make your services accessible outside the cluster, MetalLB needs IP addresses. MetalLB takes care of assigning and releasing these addresses as needed when you create services, but it only distributes IPs that are in its configured pools. When MetalLB assigns an external IP address to a service, it informs the network outside the cluster that this IP belongs to the cluster. This communication is done using standard network protocols like ARP or BGP.
+To make your services accessible outside the cluster, MetalLB needs IP addresses. MetalLB takes care of assigning and releasing these addresses as needed when you create services, but it only distributes IPs that are in its configured pools. When MetalLB assigns an external IP address to a service, it informs the network outside the cluster that this IP belongs to the cluster. This communication is done using standard network protocols like Address Resolution Protocol (ARP) or Border Gateway Protocol (BGP).
 
 - Layer 2 mode (ARP): In layer 2 mode, one K8s node in the cluster takes ownership of the service, and uses standard address discovery protocols (ARP for IPv4) to make those IPs reachable on the local network. From the LAN's point of view, the announcing machine simply has multiple IP addresses.
-- BGP: In BGP mode, all machines in the cluster establish BGP peering sessions with nearby routers that you control, and tell those routers how to forward traffic to the service IPs. Using BGP enables true load balancing across multiple nodes, and fine-grained traffic control due to BGP's policy mechanisms.
+- BGP: In BGP mode, all machines in the cluster establish BGP peering sessions with nearby routers that you control, and the machines tell those routers how to forward traffic to the service IPs. Using BGP enables true load balancing across multiple nodes, and fine-grained traffic control due to BGP policy mechanisms.
 
 MetalLB has two components:
 
@@ -33,7 +33,7 @@ MetalLB has two components:
 :::image type="content" source="media/load-balancer-overview/metallb-architecture.png" alt-text="MetalLB Architecture" lightbox="media/load-balancer-overview/metallb-architecture.png":::
 
 - In ARP mode, one of the speaker pods is selected as the leader. It then advertises the IP using an ARP broadcast message, binding the IP with the MAC address of the node it lives in. Thus, all traffic first hits one node, and then kube-proxy spreads it evenly to all the backend pods of the service.
-- In BGP mode, all cluster nodes establish connections with all BGP peers created in the `BGP Peers` tab. Typically a BGP peer is a TOR switch. In order to broadcast the BGP routing information, the BGP peers must be configured so that they recognize the IP and ASN of cluster nodes. When you use BGP with ECMP (Equal-Cost MultiPath), traffic hits evenly across all nodes, and therefore achieves true load balancing.
+- In BGP mode, all cluster nodes establish connections with all BGP peers created in the **BGP Peers** tab. Typically a BGP peer is a TOR switch. In order to broadcast the BGP routing information, the BGP peers must be configured so that they recognize the IP and ASN of cluster nodes. When you use BGP with ECMP (Equal-Cost MultiPath), traffic hits evenly across all nodes, and therefore achieves true load balancing.
 
 ## Compare MetalLB L2 (ARP) and BGP modes
 
@@ -42,7 +42,7 @@ The choice between L2 and BGP mode with MetalLB depends on your specific require
 | Aspect                      | MetalLB in L2 (ARP) mode          | MetalLB in BGP mode            |
 |-----------------------------|----------------------------------|----------------------------------|
 | Overview | In layer 2 mode, one K8s node assumes the responsibility of advertising a service to the local network. From the network perspective, it looks like the K8s node has multiple IP addresses assigned to its network interface. | In BGP mode, each K8s node in your cluster establishes a BGP peering session with your network routers, and uses that peering session to advertise the IPs of external cluster services. |
-| IP address assignment       | MetallLB IP address pools must be in the same subnet as the K8s nodes.   | MetallLB IP address pools can be in a different network than the K8s nodes. |
+| IP address assignment       | MetalLB IP address pools must be in the same subnet as the K8s nodes.   | MetalLB IP address pools can be in a different network than the K8s nodes. |
 | Configuration complexity    | Low. Since you're providing IP addresses in the same network as your Kubernetes nodes, you only need to specify an IP CIDR or IP pool while setting up MetalLB. | High. Configuring BGP requires knowledge of BGP protocol and an understanding of your network infrastructure. |
 | Scalability                 | Limited to Layer 2 networks, suitable for small to medium-sized K8s deployments. | Suitable for complex network topologies and large-scale K8s deployments. |
 | Compatibility with infrastructure network | Works with any network, but can cause ARP flooding in large K8s clusters, since a single IP is used for all services, and the service's ingress bandwidth is limited to the bandwidth of a single node. | Requires BGP support in the network infrastructure. |
@@ -53,7 +53,7 @@ The choice between L2 and BGP mode with MetalLB depends on your specific require
 
 ### Can a MetalLB instance be reused across AKS Arc clusters?
 
-No, MetalLB can't be reused across AKS Arc clusters. MetalLB lives as pods in a Kubernetes cluster, and load balancers are Custom Resources (CRs). You must install the MetalLB Arc k8s-extension using Azure CLI, the Azure portal or Azure Resource Manager templates, and create load balancers for every AKS Arc cluster. 
+No, MetalLB can't be reused across AKS Arc clusters. MetalLB lives as pods in a Kubernetes cluster, and load balancers are custom resources (CRs). You must install the MetalLB Arc **k8s-extension** using Azure CLI, the Azure portal or Azure Resource Manager templates, and create load balancers for every AKS Arc cluster.
 
 ## Next steps
 
