Azure Container Services Docs – Weekly Update (2026-06-14 to 2026-06-21)
The most meaningful Azure Kubernetes Service, AKS Arc, Container Registry, Application Gateway for Containers, and Fleet Manager documentation changes from the last 7 days. AKS everywhere! Summaries are AI-filtered to skip trivial edits.
📊 Updates this week: ACR (5), AGC (1), AKS (36), Fleet (14)
|
||
|
Networking ✨ Update Modified: 2026-06-19 17:04 |
||
|
Summary Use the Application Routing add-on to automatically manage Azure DNS records and Azure Key Vault TLS certificates for ingress traffic on Azure Kubernetes Service (AKS) with the Kubernetes Gateway API. |
||
|
|
||
|
Compute 🆕 New Modified: 2026-06-18 22:15 |
||
|
Summary The documentation now includes a new section on prerequisites for using the Node Customization Preview, specifically requiring users to register the `AKSNodeCustomizationPreview` feature flag in their Azure subscription before utilizing the preview `kubeReserved` and `hardEvictionThreshold` kubelet settings. Users can now follow detailed steps to register this feature flag and verify its status using the Azure CLI commands, enabling them to configure CPU and memory reservations for Kubernetes system daemons on Linux node pools. Additionally, the documentation clarifies that these settings are only applicable to Linux node pools and outlines the necessary parameters and their constraints. |
||
|
|
||
|
Operations ✨ Update Modified: 2026-06-15 17:10 |
||
|
Summary The documentation now states that the control plane can be up to three minor versions ahead of node pools, an increase from the previous limit of two minor versions. For instance, if your control plane is at version 1.35.x, your node pools can now be at versions 1.32.x, 1.33.x, 1.34.x, or 1.35.x, providing users with greater flexibility in managing version compatibility. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-19 06:05 |
||
|
Summary The FAQ document has been updated with new content regarding cluster upgrade types and member selection strategies, providing clearer guidance for users. |
||
|
|
||
|
Compute ✨ Update Modified: 2026-06-17 22:10 |
||
|
Summary The documentation now specifies that the Ubuntu node images with FIPS are not supported for Ubuntu 24.04+, instead of 22.04+. Additionally, the compatibility notes for the Ubuntu node images with Trusted Launch have been clarified, indicating they cannot be combined with Arm64 or CVM. Users should be aware of these updates when selecting node images for their AKS deployments. |
||
|
|
||
|
Operations 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The document has been updated to include new features related to approval gates in Azure Kubernetes Fleet Manager Update Strategies. It now provides clearer instructions and applies to both the Azure portal and CLI, enhancing user guidance. |
||
|
|
||
|
Cost ✨ Update Modified: 2026-06-17 17:05 |
||
|
Summary The documentation now clarifies that when PDB auto-creation is enabled, the extension compares the PDB’s label selector with the deployment’s pod template labels to avoid duplicate PDBs. Additionally, for deployments with HPA or KEDA, the `minAvailable` value of auto-created PDBs aligns with the autoscaler’s minimum replica floor, ensuring better management of pod availability during scaling events. Users will also benefit from improved scaling behavior, as the extension will not proceed with scale-down if nodes are cordoned or if a drain is in progress, preventing unnecessary churn during multi-node drains. |
||
|
|
||
|
Compute 🆕 New Modified: 2026-06-18 22:15 |
||
|
Summary Updates include the introduction of the preview custom node configuration settings for `kubeReserved` and `hardEvictionThreshold` on Linux node pools, requiring the registration of the `AKSNodeCustomizationPreview` feature flag. |
||
|
|
||
|
Security ♻️ Rework Modified: 2026-06-18 17:09 |
||
|
Summary The document outlines the process for deploying AKS clusters with Trusted Launch and FIPS enabled, including necessary parameters and commands. It emphasizes the importance of security features like Secure Boot and vTPM, providing detailed examples and instructions for users to follow. |
||
|
|
||
|
Networking ✨ Update Modified: 2026-06-19 06:05 |
||
|
Summary This document has been refreshed to ensure the integrity and retrievability of the content related to outbound rules and egress control. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-19 15:11 |
||
|
Summary Updated the article to include new ACR API request limits, enhancing the understanding of service capabilities and limitations. |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-19 06:05 |
||
|
Summary This document has been updated with significant content additions and deletions, enhancing the understanding of placement in Kubernetes fleet management. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-16 03:43 |
||
|
Summary This document introduces how to create an Azure Kubernetes Service (AKS) cluster on bare metal using an ARM template. It includes prerequisites and detailed steps for deployment, emphasizing that the feature is currently in preview. |
||
|
|
||
|
Networking ♻️ Rework Modified: 2026-06-17 22:10 |
||
|
Summary The document has been updated to include information about FIPS support on Ubuntu 22.04 nodes when using Advanced Container Networking Services. |
||
|
|
||
|
Networking 🆕 New Modified: 2026-06-16 22:11 |
||
|
Summary The documentation now includes important notes regarding the use of Azure Load Balancer annotations with the Istio add-on for the `Gateway` Service. Users must unset specific health probe annotations in the `GatewayClass` or per-`Gateway` ConfigMap when setting `spec.externalTrafficPolicy` to "Local." This clarification helps ensure proper configuration and functionality of health probes in their deployments. |
||
|
|
||
|
Networking ✨ Update Modified: 2026-06-15 17:10 |
||
|
Summary File: articles/aks/includes/ingress-nginx-retirement.md Subjects: – Merging changes synced from https://github.com/MicrosoftDocs/azure-aks-docs-pr (branch live) – Merge pull request #3335 from MicrosoftDocs/main – Merge pull request #3323 from nshankar13/nshankar/update-istio-gateway-api-ga Patch excerpt: -> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to Istio Gateway API support when it becomes GA. +> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to the Istio Gateway API, which is now GA. -> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to Istio Gateway API support when it becomes GA. +> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to the Istio Gateway API, which is now GA. -> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to Istio Gateway API support when it becomes GA. +> – **Service mesh users**: If you plan to adopt a service mesh, consider the [Istio-based service mesh add-on](/azure/aks/istio-about). Use Istio Ingress today, and plan to migrate to the Istio Gateway API, which is now GA. |
||
|
|
||
|
Operations ♻️ Rework Modified: 2026-06-17 22:10 |
||
|
Summary This document provides updated instructions for upgrading the OS version in Azure Kubernetes Service, including verification steps. |
||
|
|
||
|
Networking 🆕 New Modified: 2026-06-19 17:04 |
||
|
Summary New documentation has been added for DNS/TLS integration with App Routing Istio, providing users with essential details for secure configurations. |
||
|
|
||
|
Networking ♻️ Rework Modified: 2026-06-17 22:10 |
||
|
Summary The documentation now reflects updated compatibility ranges for various AKS versions. Specifically, the compatible AKS range for Istio 1.3 has been corrected to include versions 1.30 to 1.34, and the range for Istio 1.4 has been expanded to include 1.36. Additionally, users can expect the release of Istio 1.5 to be compatible with AKS versions 1.30 through 1.36. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-19 22:04 |
||
|
Summary File: AKS-Arc/aks-bare-metal-create-cluster-portal.md Subjects: – Repo sync for protected branch – Merging changes synced from https://github.com/MicrosoftDocs/azure-stack-docs-pr (branch live) – Merge pull request #21049 from MicrosoftDocs/main – Merge pull request #21036 from RishiMody7/aks_bm_ip_fix – LAA suggested fix – Modify documentation to reflect control plane IP is an optional field during cluster create Patch excerpt: -| Control plane IP | An IP address in the same subnet as your edge machine. This **cannot** be the same as the machine’s IP address. | +| Control plane IP | (Optional) If you leave this field blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom control plane IP and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| Control plane IP | An IP address in the same subnet as your edge machine. This **cannot** be the same as the machine’s IP address. | +| Control plane IP | (Optional) If you leave this field blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom control plane IP and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| Control plane IP | An IP address in the same subnet as your edge machine. This **cannot** be the same as the machine’s IP address. | +| Control plane IP | (Optional) If you leave this field blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom control plane IP and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| Control plane IP | An IP address in the same subnet as your edge machine. This **cannot** be the same as the machine’s IP address. | +| Control plane IP | (Optional) If you leave this field blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom control plane IP and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| Control plane IP | (Optional) If left blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | +| Control plane IP | (Optional) If you leave this field blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -| Control plane IP | An IP address in the same subnet as your edge machine. This **cannot** be the same as the machine’s IP address. | +| Control plane IP | (Optional) If left blank, the control plane IP defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host machine. If provided, it must be in the same subnet as your edge machine. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom control plane IP and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| Cluster name | Enter a name for your cluster. Don’t use spaces. | +| Cluster name | Enter a name for your cluster. Name must be 1-27 characters long, start and end with a letter or number, and can only contain letters, numbers, hyphens, or underscores. | |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The documentation now includes a breaking changes table for Kubernetes version 1.36, detailing updates to AKS managed add-ons and components, which users should review to understand potential impacts on their deployments. Additionally, the end-of-life date for Kubernetes version 1.33 has been updated to July 2026, and a release calendar entry for Kubernetes version 1.37 has been added, indicating its preview in September 2026 and general availability in October 2026. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-18 22:04 |
||
|
Summary The document has been updated with new information regarding the disabling of Windows node pools in AKS-Arc, enhancing operational guidance. |
||
|
|
||
|
Compute 🆕 New Modified: 2026-06-15 22:13 |
||
|
Summary The documentation for GPU profiling in AKS has been updated to reflect changes in command usage, specifically switching from `helm install` to `helm upgrade –install` for the Inspektor Gadget installation. Additionally, users are now instructed to use the `AMP_RESOURCE_GROUP` variable instead of `RESOURCE_GROUP` when listing Azure Monitor workspace information, which clarifies the resource group context for users. New sample flame graph images have been added, along with tips for using Grafana’s features to enhance the analysis of GPU memory allocation call stacks. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-19 22:04 |
||
|
Summary File: AKS-Arc/aks-bare-metal-create-cluster-bicep.md Subjects: – Repo sync for protected branch – Merging changes synced from https://github.com/MicrosoftDocs/azure-stack-docs-pr (branch live) – Merge pull request #21049 from MicrosoftDocs/main – Merge pull request #21036 from RishiMody7/aks_bm_ip_fix – Modify documentation to reflect control plane IP is an optional field during cluster create Patch excerpt: -| `controlPlaneIp` | IP address | Must be in the same subnet as the host IP **but cannot be the same as the host IP**. | +| `controlPlaneIp` | IP address | If omitted, defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host. If provided, it must be in the same subnet as the host IP. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom controlPlaneIp and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| `controlPlaneIp` | IP address | Must be in the same subnet as the host IP **but cannot be the same as the host IP**. | +| `controlPlaneIp` | IP address | If omitted, defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host. If provided, it must be in the same subnet as the host IP. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom controlPlaneIp and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| `controlPlaneIp` | IP address | Must be in the same subnet as the host IP **but cannot be the same as the host IP**. | +| `controlPlaneIp` | IP address | If omitted, defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host. If provided, it must be in the same subnet as the host IP. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom controlPlaneIp and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| `controlPlaneIp` | IP address | Must be in the same subnet as the host IP **but cannot be the same as the host IP**. | +| `controlPlaneIp` | IP address | If omitted, defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host. If provided, it must be in the same subnet as the host IP. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom controlPlaneIp and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. -| `controlPlaneIp` | IP address | Must be in the same subnet as the host IP **but cannot be the same as the host IP**. | +| `controlPlaneIp` | IP address | If omitted, defaults to the host machine’s IP address. Only specify a custom IP if you need the control plane to be reachable on a different address than the host. If provided, it must be in the same subnet as the host IP. | -> If your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. +> If you specify a custom controlPlaneIp and your machine uses DHCP, you must reserve the control plane IP address so it remains permanently assigned to this machine. If the control plane IP changes, the Kubernetes cluster becomes unreachable and must be redeployed. |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-18 06:02 |
||
|
Summary The documentation has been updated to clarify the use of update strategies in Azure Kubernetes Fleet Manager, specifically regarding the assignment of clusters to update groups and stages. Users can now utilize member labels for grouping clusters, allowing for more flexible update sequences and the ability to manage large fleets with dynamic membership. Additionally, the maximum number of update groups per stage is explicitly stated as 50, enhancing user awareness of configuration limits. |
||
|
|
||
|
Networking 🆕 New Modified: 2026-06-17 22:10 |
||
|
Summary The documentation now indicates that users can utilize Ubuntu 22.04 node pools for FIPS compliance, in addition to Azure Linux node pools, as FIPS is not available on Ubuntu 20.04 due to kernel restrictions. This change provides users with more options for deploying compliant environments in Azure Kubernetes Service (AKS). |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-18 06:02 |
||
|
Summary The documentation now emphasizes the use of member labels as the recommended method for selecting clusters in update strategies, providing users with greater flexibility. Users can apply labels to fleet members using the `az fleet member create` and `az fleet member update` commands, allowing for more precise control over cluster selection during updates. Additionally, the update strategy creation process has been clarified, detailing how to define stages and groups in a JSON file, including the use of `maxConcurrency` settings for managing upgrade concurrency. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-18 22:04 |
||
|
Summary This article has been modified to include new information regarding the upgrade process for Windows OS in AKS-Arc, improving clarity and guidance. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-19 15:11 |
||
|
Summary File: articles/container-registry/container-registry-dedicated-data-endpoints.md Subjects: – Merge branch ‘MicrosoftDocs:main’ into ritaylor/update-release-status – Merging changes synced from https://github.com/MicrosoftDocs/azure-management-docs-pr (branch live) – Merge pull request #2599 from MicrosoftDocs/main – Merge pull request #2581 from johnsonshi/docs-editor/container-registry-dedicated-d-1781198359 Patch excerpt: -author: rayoef -ms.author: rayoflores +author: KumudD +ms.author: kumud -> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for 20 minutes, providing a secure, short-lived URL for downloading the layer. After 20 minutes, the link expires, and the client simply requests a new one if it needs to download another layer when pulling images. +> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for at least 20 minutes and up to 30 minutes, providing a secure, short-lived URL for downloading the layer. After the link expires, the client simply requests a new one if it needs to download another layer when pulling images. -> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for 20 minutes, providing a secure, short-lived URL for downloading the layer. After 20 minutes, the link expires, and the client simply requests a new one if it needs to download another layer when pulling images. +> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for at least 20 minutes and up to 30 minutes, providing a secure, short-lived URL for downloading the layer. After the link expires, the client simply requests a new one if it needs to download another layer when pulling images. -> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for 20 minutes, providing a secure, short-lived URL for downloading the layer. After 20 minutes, the link expires, and the client simply requests a new one if it needs to download another layer when pulling images. +> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for at least 20 minutes and up to 30 minutes, providing a secure, short-lived URL for downloading the layer. After the link expires, the client simply requests a new one if it needs to download another layer when pulling images. -> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for 20 minutes, providing a secure, short-lived URL for downloading the layer. After 20 minutes, the link expires, and the client simply requests a new one if it needs to download another layer when pulling images. +> During image pulls, if dedicated data endpoints are enabled, ACR gives the client a temporary download link each time it needs to fetch an image layer. This link points to the dedicated data endpoint and is valid for at least 20 minutes and up to 30 minutes, providing a secure, short-lived URL for downloading the layer. After the link expires, the client simply requests a new one if it needs to download another layer when pulling images. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-19 15:11 |
||
|
Summary Significant updates made to the import images article, including fixes to code examples and a review of the content for clarity. |
||
|
|
||
|
Security ♻️ Rework Modified: 2026-06-17 22:10 |
||
|
Summary The documentation has been updated to reflect the change from FIPS 140-2 to FIPS 140-3, which is the current standard for cryptographic modules. It also specifies that Trusted Launch with FIPS is only supported with Ubuntu 22.04 on Gen2 VM sizes, and clarifies the behavior of FIPS-enabled node images. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-18 22:04 |
||
|
Summary This article has been modified to remove outdated reviewer metadata, streamlining the content for better clarity. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-15 17:10 |
||
|
Summary The documentation now includes important notes regarding the inability to enable Windows support on clusters created without it. It also clarifies the requirements for adding Windows node pools and the constraints on changing VM sizes and max pods settings. |
||
|
|
||
|
Security 🆕 New Modified: 2026-06-15 06:03 |
||
|
Summary The documentation now includes a warning about the audience for Microsoft Entra Workload Identity, emphasizing that changing the audience value may break compatibility with existing configurations and is not recommended unless necessary. Additionally, it clarifies that users should add a slight delay after adding a federated identity credential to avoid potential token request failures due to propagation delays. |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-17 06:02 |
||
|
Summary The overview of Azure Kubernetes Fleet Manager has been updated to reflect the latest statistics and improvements, including the number of clusters and update runs. It now provides a more comprehensive description of the service’s capabilities. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The documentation now reflects that both Managed Namespaces and Managed Namespace RBAC have reached General Availability (GA), indicating that users can rely on these features for production use. Previously, these features were only in Preview, which may have limited their adoption and usage in live environments. |
||
|
|
||
|
Security 🆕 New Modified: 2026-06-19 22:04 |
||
|
Summary Added a new guide on how to use Azure RBAC for AKS on Azure Local multi-rack, providing detailed instructions and examples. |
||
|
|
||
|
Operations 🆕 New Modified: 2026-06-17 22:10 |
||
|
Summary The document has been enhanced to clarify how to associate existing capacity reservation groups with new and existing node pools. It includes updated commands and emphasizes the need for the `aks-preview` Azure CLI extension for certain operations. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The documentation now clarifies that users can utilize the `–target-kubernetes-version` parameter to specify a defined target Kubernetes minor version for upgrades, with Fleet Manager Auto-upgrade automatically applying the latest patch release of that version when available. Additionally, the section title has been updated to remove the "preview" designation, indicating that this feature is now fully supported. Users can also expect improved guidance on how auto-upgrade runs respect planned maintenance windows set at the AKS cluster level. |
||
|
|
||
|
Compliance ♻️ Rework Modified: 2026-06-18 22:15 |
||
|
Summary The document has been updated to clarify that Azure Confidential Compute SGX is not supported with AKS long-term support. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The documentation for creating and configuring Managed Fleet Namespaces has been updated to remove the "preview" designation, indicating that this feature is now generally available. Users can now utilize this feature without the previous limitations associated with preview features, enhancing their ability to manage namespaces effectively. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary The documentation now clarifies that users can select either the Stable or Rapid Kubernetes release channels to automatically increment the Kubernetes minor version upon new releases. Additionally, users seeking only patch releases for a minor version can utilize the Target Kubernetes minor version channel, which is currently in preview. This update enhances user understanding of version management options within the Fleet Manager and Fleet Manager with hub cluster. |
||
|
|
||
|
Operations 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary This update includes significant changes to the update orchestration concepts for Azure Kubernetes Fleet Manager, enhancing the clarity and detail of update runs, stages, and groups. It introduces new terminology and clarifies the behavior of update strategies, including maximum concurrency and approval gates. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-17 06:02 |
||
|
Summary Updated the documentation to reflect the latest date and changes regarding Managed Fleet Namespaces, including a preview note. This enhances clarity on accessing these namespaces and their features. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-18 06:02 |
||
|
Summary This document received a freshness review, updating the date and improving the clarity of the deployment instructions for Kubernetes using PowerShell. Changes include reordering steps and updating the command syntax for better user experience. |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-17 06:02 |
||
|
Summary This article has been revised to clarify the use of Managed Fleet Namespaces for multi-cluster multi-tenancy, including updates to the date and author information. It emphasizes the importance of resource quotas and network policies across multiple clusters. |
||
|
|
||
|
Networking ♻️ Rework Modified: 2026-06-15 14:41 |
||
|
Summary The documentation now clarifies that using a Bring Your Own Azure Container Registry (BYO ACR) with the `authentication-as-arm` feature disabled is not supported. This change impacts users by providing clearer guidance on the limitations of BYO ACR configurations in network-isolated environments. |
||
|
|
||
|
Networking 🆕 New Modified: 2026-06-17 07:57 |
||
|
Summary File: articles/application-gateway/for-containers/application-gateway-for-containers-components.md Subjects: – Merge branch ‘MicrosoftDocs:main’ into krkutser-au-senderid-jun11 Patch excerpt: -ms.date: 5/20/2026 +ms.date: 6/5/2026 -For associations created on or after **April 23, 2026**, Network Security Groups (NSGs) are fully supported on the Application Gateway for Containers association subnet. This includes both **inbound and outbound** rules. +For associations created on or after **April 23, 2026**, Network Security Groups (NSGs) are fully supported on the Application Gateway for Containers association subnet, including both **inbound and outbound** rules. -For associations created **before April 23, 2026**, inbound NSG rules can be configured; however, inbound traffic on **ports 80 and 443** is always allowed, regardless of the configured rules. +"Deny all" rules are supported, but without explicit allow exceptions, they can impact traffic in the following ways: -"Deny all" rules are supported on the association subnet. However, without explicit allow exceptions, these rules can affect both inbound and outbound traffic: +- **Deny all inbound** rules will block traffic on **ports 80 and 443** unless allow rules are added, preventing access to the frontend. +- **Deny all inbound** rules will block the _AzureLoadBalancer_ service tag, which is created by default for NSGs. You must ensure the _AzureLoadBalancer_ tag is allowed to ensure smooth operations of your gateway. +- **Deny all outbound** rules will block traffic from Application Gateway for Containers to your AKS cluster, including health probes. Be sure to allow outbound access to your pod IP ranges. — **Deny all inbound** rules will block traffic on ports **80 and 443** unless explicit allow rules are defined, preventing access to the frontend. — **Deny all outbound** rules may block traffic egressing from the proxy to the AKS cluster unless required outbound exceptions are configured. +> [!Note] +> In addition to NSG rules on the association subnet, **Deny all outbound** rules on an NSG applied to the AKS subnet can block traffic from the Application Gateway for Containers ALB controller. To ensure ALB Controller can properly reconcile load balancing intent, ensure outbound traffic is allowed to [these endpoints](application-gateway-for-containers-components.md#alb-controller-outbound-connectivity). + +For associations created **before April 23, 2026**, inbound NSG rules can be configured; however, traffic on **ports 80 and 443** is always allowed, regardless of the rules defined. |
||
|
|
||
|
General ✨ Update Modified: 2026-06-19 15:11 |
||
|
Summary Updates include documentation on static-IP private endpoint geo-replication limitations, enhancing the understanding of geo-replication features. |
||
|
|
||
|
Networking ♻️ Rework Modified: 2026-06-18 22:14 |
||
|
Summary The document has been updated to correct the query for public IP ID in the NAT gateway instructions. |
||
|
|
||
|
Compute ♻️ Rework Modified: 2026-06-16 22:11 |
||
|
Summary This update refines the documentation for Linux OS settings in AKS, detailing custom OS configuration settings that affect node behavior. It emphasizes the importance of careful configuration and testing in non-production environments. |
||
|
|
||
|
Security ♻️ Rework Modified: 2026-06-19 15:11 |
||
|
Summary File: articles/container-registry/container-registry-rbac-built-in-roles-overview.md Subjects: – Merge branch ‘MicrosoftDocs:main’ into ritaylor/update-release-status Patch excerpt: -author: rayoef -ms.author: rayoflores +author: KumudD +ms.author: kumud — **Scenario: Developers and command line scripts that use `az` CLI to authenticate and login to the registry (via the `az acr login` command), as well as to run other `az` CLI control plane commands on a registry.** Take note that identities that only need image pull, push, or delete permissions do not need the following role. This scenario is strictly about clarifying the role that grants permissions to enable running `az` CLI on a registry, including `az acr login` and other `az` CLI control plane commands on a registry. Take note that this role also grants permissions to create, update, or delete ACR registries, as well as granting control plane permissions to maange registry configuration (see below). Take note that this role does not grant data plane permissions, which are granted separately (see above). +- **Scenario: Developers and command line scripts that use `az` CLI to authenticate and login to the registry (via the `az acr login` command), as well as to run other `az` CLI control plane commands on a registry.** Take note that identities that only need image pull, push, or delete permissions do not need the following role. This scenario is strictly about clarifying the role that grants permissions to enable running `az` CLI on a registry, including `az acr login` and other `az` CLI control plane commands on a registry. This role also grants permissions to create, update, or delete ACR registries, as well as control plane permissions to manage registry configuration. This role does not grant data plane permissions to pull, push, or delete images; those are granted by the separate data plane roles. – – authenticate and login to the registry using `az` CLI via the `az acr login` command + – authenticate and login to the registry using `az` CLI via the `az acr login` command. Note that on an ABAC-enabled registry, `az acr login` succeeds with this role, but the identity is still not granted any data plane operations (pull, push, delete) unless it also holds an ABAC-compatible data plane role. — **Scenario: Developers and command line scripts that use `az` CLI to authenticate and login to the registry (via the `az acr login` command), as well as to run other `az` CLI control plane commands on a registry.** Take note that identities that only need image pull, push, or delete permissions do not need the following role. This scenario is strictly about clarifying the role that grants permissions to enable running `az` CLI on a registry, including `az acr login` and other `az` CLI control plane commands on a registry. Take note that this role also grants permissions to create, update, or delete ACR registries, as well as granting control plane permissions to maange registry configuration (see below). Take note that this role does not grant data plane permissions, which are granted separately (see above). + +- **Scenario: Developers and command line scripts that use `az` CLI to authenticate and login to the registry (via the `az acr login` command), as well as to run other `az` CLI control plane commands on a registry.** Take note that identities that only need image pull, push, or delete permissions do not need the following role. This scenario is strictly about clarifying the role that grants permissions to enable running `az` CLI on a registry, including `az acr login` and other `az` CLI control plane commands on a registry. This role also grants permissions to create, update, or delete ACR registries, as well as control plane permissions to manage registry configuration. This role does not grant data plane permissions to pull, push, or delete images; those are granted by the separate data plane roles. |
||
|
|
||
|
Networking 🆕 New Modified: 2026-06-19 17:04 |
||
|
Summary This document has been updated to include new information regarding DNS/TLS integration with App Routing Istio, enhancing the guidance for users implementing these features. |
||
|
|
||
|
Security ✨ Update Modified: 2026-06-17 06:02 |
||
|
Summary This document has been enhanced with additional details on configuring events for approval gates in Azure Kubernetes Fleet Manager, including examples of integration scenarios and the necessary RBAC roles. |
||
|
|
||
|
General 🆕 New Modified: 2026-06-18 22:15 |
||
|
Summary The documentation now includes a critical note advising users not to impose a TCP connection cap on their upstream custom DNS server before enabling LocalDNS. This change highlights that enabling LocalDNS opens long-lived TCP connections, which could be rejected if the DNS server has a fixed limit on concurrent TCP connections, potentially leading to cluster-wide DNS resolution failures. Users are encouraged to leave TCP connection limits at a generous default and validate connection counts after enabling LocalDNS before making any adjustments. |
||
|
|
||
|
General ♻️ Rework Modified: 2026-06-18 17:09 |
||
|
Summary Updated the article to reflect the latest end-of-support notifications for AKS, ensuring users are informed about critical timelines. |
||
|
Full tracker with filters: Azure Container Services Docs Tracker
