The documentation now highlights that on AKS Automatic clusters, Node Auto Provisioning (NAP) is preconfigured and supported by a pod readiness SLA that ensures 99.9% of qualifying pod readiness operations are completed within 5 minutes. This enhancement allows users to have their workloads running on appropriately sized nodes quickly, eliminating the need for manual VM selection or capacity planning.

The documentation now includes a new FAQ section clarifying that only label exclusion is supported for the Cilium ConfigMap in Azure CNI Powered by Cilium. Users can add labels to the ConfigMap, which will persist across cluster restarts, upgrades, and reconciliation, but changes to other values are not permitted. This update provides clearer guidance on the limitations and capabilities regarding the modification of the Cilium ConfigMap.

This update includes new author information and clarifications on attaching Azure Container Registry to AKS, which is essential for users looking to manage container images effectively.

The document provides important information on updating tags for existing Azure Disk volumes. It explains that after a PersistentVolume is created, its spec is immutable, and details the process for updating tags on the underlying managed disk without interrupting existing mounts.

The document has been updated with new author information and clarifications regarding scale-down modes in AKS, which is important for users managing resource allocation and cost efficiency.

The documentation now specifies that Application Network requires AKS version 1.30 or higher, providing users with clear compatibility requirements. Users can refer to the "Application Network supported versions" section for detailed information on compatibility with different AKS versions. This update ensures that users are aware of the necessary version to utilize Application Network effectively.

This update provides detailed instructions on how to upgrade an AKS cluster to use a user-assigned managed identity instead of a service principal. It includes a command example for upgrading the node pool, highlighting the implications of this change on the control plane and pods, as well as potential downtime during the upgrade process.

The documentation for deploying the NVIDIA device plugin on Azure Linux has been updated to emphasize that when using a custom DaemonSet manifest instead of Helm, users must include the environment variable `NVIDIA_MIG_MONITOR_DEVICES=all` in the device plugin container. This clarification ensures that users correctly configure their deployments for optimal functionality.

The documentation now specifies that the pod readiness SLA for Azure Kubernetes Service (AKS) Automatic guarantees that 99.9% of qualifying pod readiness operations will complete within 5 minutes, enhancing the reliability of self-healing infrastructure for applications. This clarification helps users understand the performance expectations and reliability of AKS Automatic in managing their Kubernetes environments.

The documentation for the HTTP proxy in Azure Kubernetes Service has been updated to clarify that users can specify no more than 20 Trusted CA certificates. The `trustedCa` parameter description now explicitly states this limit, ensuring users are aware of the maximum number of certificates they can include.

The document now emphasizes the implications of rolling back node pool versions, including vulnerability exposure and service disruption. It advises using rollback only temporarily while resolving issues, highlighting the importance of security and service continuity.

The documentation now clarifies that AKS clusters running Kubernetes versions earlier than 1.33 cannot update the service address range, pod address range, or cluster virtual network address range after creation. However, starting with Kubernetes 1.33, users can extend the service IP range post-creation using the `ServiceCIDR` resource, providing greater flexibility in managing IP ranges for their clusters.

The document has undergone several updates to improve clarity and organization, including rephrasing sections and addressing review comments. These changes enhance the overall usability and effectiveness of the best practices outlined.

The documentation now includes important information regarding the `tags` storage class parameter for Azure Files when using the CSI driver. Users are informed that once a persistent volume is created, its spec is immutable, meaning that tags or other attributes cannot be changed directly on the PersistentVolume. Instead, users can update tags on the underlying storage account without interrupting existing mounts or data access, with an example command provided for updating tags using the Azure CLI.

The title and description of the article have been updated to reflect the correct name of the Container Network Insights Agent. The content has been enhanced to provide clearer instructions on deploying the agent and its functionalities, including troubleshooting networking issues in AKS clusters.

This document introduces how to deploy a production-ready Azure Kubernetes Service (AKS) cluster using Terraform with an Azure Verified Module (AVM). It emphasizes the importance of using AVMs for consistent and secure Kubernetes environments.

The document has been updated to clarify the customer intent regarding Kubernetes deployments using Automated Deployments in a code editor. This change enhances the understanding of the deployment process and its benefits for scalability and updates.

This file has been updated with new author information and clarifications regarding pod sandboxing considerations, which is important for users focused on security and isolation in their AKS deployments.

The file has been updated to reflect changes in authorship, indicating a shift in responsibility for the content. This may suggest updates or improvements in best practices for Azure AKS extensions.

The documentation for Azure Kubernetes Service (AKS) has been updated to clarify that AKS is a mix of Infrastructure as a Service (IaaS) and Platform as a Service (PaaS), enhancing user understanding of its deployment options. Additionally, the language has been refined for consistency, particularly regarding the management of the control plane and the shared responsibility model for agent nodes, ensuring users are aware of their role in maintaining the AKS cluster.

The documentation now emphasizes that for a production AKS cluster with a single system node pool, it is recommended to have at least three nodes to enhance fault tolerance and availability. Additionally, it clarifies that while it is possible to schedule application pods on a system node pool, it is not recommended; users are encouraged to create a user node pool for their applications instead. This guidance helps users better manage their AKS clusters and optimize their configurations.

Updated the documentation to include information about extending the service IP range after cluster creation starting with Kubernetes 1.33, which is crucial for users managing their own CNI.

The authorship has been updated in this file, potentially indicating revisions or improvements related to KEDA (Kubernetes Event-driven Autoscaling) within Azure AKS, which is crucial for scaling applications.

The documentation has been updated to improve clarity regarding the use of Azure Bastion for secure access to private hub clusters. This includes updated links and instructions for setting up Azure Bastion hosts.

The documentation now includes a new section on DNS resolution performance, highlighting its impact on application response times in microservices architectures. Users are encouraged to enable LocalDNS on their node pools to deploy a per-node DNS proxy, which reduces network hops and alleviates `conntrack` table pressure, while also providing cached stale responses during upstream DNS outages to maintain workload connectivity. For further details, users can refer to the linked resources on LocalDNS and DNS concepts in AKS.

The documentation now clarifies that for disks and files created through a `StorageClass`, the `tags` parameter is applied to the underlying Azure resource at provisioning time, and changes to the `StorageClass` will only affect newly provisioned volumes. Additionally, it specifies that the `PersistentVolume` spec is immutable after creation, meaning users cannot edit or patch existing persistent volumes to change tags or attributes. To update tags for existing volumes, users must modify the tags directly on the underlying Azure resources, which does not disrupt existing mounts or data access.

The documentation now specifies that clusters must run Kubernetes version 1.32 or above to utilize Advanced Container Networking Services (ACNS) with Cilium enabled. Additionally, it clarifies that ACNS sets the Cilium version and enabled features, which cannot currently be modified directly by users. Users can also confirm that a cross-cluster network can support up to 255 member clusters.

New page added.

This document has been updated to reflect changes in authorship and metadata, ensuring that the content remains accurate and up-to-date for users seeking information on KEDA workload identity in AKS.

Updated the service CIDR documentation to reflect the support for extending the service IP range after cluster creation starting with Kubernetes 1.33. This includes a note about the service address range requirements and the ability to reuse ranges across different AKS clusters.

The documentation for the artifact cache overview has been updated to reorder the list of upstream registries, clarifying the support for authenticated and unauthenticated pulls for each registry. Users can now more easily identify which registries support specific pull methods, enhancing their understanding of the capabilities of Docker Hardened Images, Azure Container Registry, and NVIDIA NGC Container Registry. Additionally, minor adjustments were made to the formatting of the service account key instructions.

New page added.

Updates to the API Server VNet Integration documentation include new limitations and requirements for dual-stack networking. It specifies that to use dual-stack networking, the cluster must have Kubernetes version 1.26.3 or later and the Azure network plugin in overlay mode.

Revised the Kubernetes service address range documentation to clarify that the range can be extended after cluster creation using the ServiceCIDR resource starting with Kubernetes 1.33. This change enhances the understanding of service address range management.

This article outlines common issues encountered when deploying and using the Container Network Insights Agent on AKS. It follows a structured format for troubleshooting, detailing symptoms, causes, and resolutions, and includes updated links for deployment instructions.

The documentation for the Azure Kubernetes Service (AKS) Automatic quickstart has been updated to highlight the Pod Readiness SLA, which guarantees that 99.9% of qualifying pod readiness operations complete within 5 minutes, ensuring reliable infrastructure for applications. Additionally, the Terraform configuration examples have been refined, including the creation of an AKS Automatic cluster with a system-assigned managed identity and a system node pool, allowing users to better manage their Kubernetes infrastructure.

The documentation for AKS Automatic has been updated to include a comprehensive list of regions where AKS Automatic is now available, enhancing user awareness of deployment options. Additionally, the explanation regarding the preconfigured node resource group lockdown has been clarified, emphasizing its impact on virtual network links and guiding users on how to handle cross-VNet or custom DNS scenarios.

Updated links for Trident installation guides to point to the latest quickstart documentation. This change enhances the clarity and accessibility of installation resources for users.

The documentation now specifies that the Azure Kubernetes Application Network’s minor version 1.1 is expected to be compatible with AKS version 1.26 until April 2026, and version 1.2 will be compatible with AKS version 1.27, expected around May 2026. Additionally, an important note has been added clarifying that Application Network does not manage AKS cluster upgrades, emphasizing the need for users to select compatible versions during onboarding and to regularly upgrade to maintain support.

The documentation now includes the new outbound type `managedNATGatewayV2`, which is currently in preview, allowing users to configure AKS clusters with enhanced NAT gateway options. Users can select `managedNATGatewayV2` for managed virtual networks, which provisions a StandardV2 NAT gateway, recommended for its zone redundancy and higher bandwidth. Additionally, the migration paths for outbound types have been clarified, emphasizing that changes to the outbound type will disrupt network connectivity and alter the cluster’s egress IP address, necessitating updates to any firewall rules.

Added a note regarding the ability to extend the service IP range after cluster creation with Kubernetes 1.33, improving the clarity of network configuration options for users.

The document has been updated with new author information and clarifications on starting and stopping node pools in AKS, which is essential for managing cluster resources effectively.

The documentation now highlights the Pod Readiness SLA as a key differentiator for AKS Automatic, emphasizing that it guarantees 99.9% of qualifying pods are ready within 5 minutes during scale-ups. Users are encouraged to consider AKS Automatic for a fully managed experience with production-ready defaults and built-in security. This addition provides clearer guidance on the benefits of using AKS Automatic for users seeking reliability in pod readiness.

This update includes new author information and clarifications on the GitHub workflow for AKS extensions, which is important for developers integrating CI/CD practices.

The documentation has been updated to clarify the optional nature of the `certificateAuthority` field for TLS verification when connecting to the issuer URL. This change enhances the understanding of configuration options for users.

The documentation now includes a detailed section on DNS resolution in AKS, highlighting the use of LocalDNS for improved performance and reliability. Users can benefit from LocalDNS, which deploys a DNS proxy on each node to reduce latency, alleviate `conntrack` table pressure, and provide cached responses during upstream DNS outages, making it particularly advantageous for large clusters or high DNS query environments. For configuration guidance, users are directed to the "Configure LocalDNS" section.

The document has been updated with new author information and includes important changes related to compliance and security for Azure Linux containers, which is critical for maintaining security standards.

The documentation now includes a new section on static node pools, which allows users to create a fixed number of nodes using the `replicas` field. Users can specify a minimum number of nodes that will always be maintained, regardless of pending pod pressure, and can also set a maximum number of nodes for scaling by using the `nodes` field in the `limits` section. Additionally, it clarifies that when using the `limits` field, only the `nodes` field is adjustable, and resources cannot be set.

The document has been revised to clarify the importance of periodic token rotation for Kubernetes service account tokens, enhancing security practices for users implementing workload identity federation.

The documentation was modified to clarify the usage of labels for node pools in load balancer configurations. This change enhances the technical accuracy and usability of the documentation for users configuring load balancers.

This document has been updated with new author information and includes significant changes to the content structure. The updates may enhance clarity and usability for users working with AKS extensions.

The document has been updated with new author information and clarifications regarding GitHub Copilot plugins for AKS extensions, which is beneficial for developers looking to enhance their development workflow.

The managed namespaces documentation has been revised to improve clarity and organization. This includes updates to the authorship and potentially the content structure, which may aid users in understanding managed namespaces in AKS.

Modified links for Trident installation resources to direct users to the updated quickstart guide. This change is significant for maintaining up-to-date documentation.

The documentation has been updated to provide detailed considerations for blue-green upgrades, including the need for double node capacity and careful planning for stateful workloads. This enhances the guidance for users planning upgrades.

The documentation now includes a new section on optimizing DNS resolution with LocalDNS for AKS node pools. Users are advised to enable LocalDNS to enhance DNS performance and reliability, reduce load on centralized CoreDNS pods, and prevent potential connection issues due to `conntrack` table exhaustion. Additionally, LocalDNS can serve stale cached responses during upstream DNS outages, improving service reliability for workloads that require high DNS availability.

The documentation now emphasizes that AKS Automatic manages system node pools and components, eliminating the need for manual user node pool creation. It introduces a guaranteed pod readiness SLA, ensuring that 99.9% of qualifying pod readiness operations complete within 5 minutes, which enhances responsiveness during scaling events. Additionally, the cluster upgrades are now automatically handled using the stable channel to minor version N-1, improving the upgrade process for users.

The documentation now includes details about the new `managedNATGatewayV2` option for creating AKS clusters, which is currently in preview. Users can utilize this option to create a zone-redundant NAT gateway that supports IPv6 and higher throughput, and they can choose between Azure-managed or customer-defined outbound IPs. Additionally, the instructions for creating AKS clusters with both managed and user-assigned NAT gateways have been updated to reflect the new parameters and requirements for the StandardV2 NAT gateway.

The documentation now includes detailed examples for creating maintenance configurations using Terraform for Azure Kubernetes Service (AKS). Users can define a default maintenance configuration that schedules maintenance every Saturday from 2:00 AM to 6:00 AM, as well as configurations for automatic upgrades and node OS upgrades on specific days and times. Additionally, users are guided on how to initialize Terraform, create execution plans, and apply configurations, enhancing their ability to manage AKS maintenance effectively.

Revised links for Trident installation methods, ensuring users have access to the most current installation guides. This update improves the documentation’s accuracy and usability.

New page added.

The document has been revised to enhance clarity on automated deployments in AKS Automatic, emphasizing the inclusion of a pod readiness SLA that guarantees high availability for applications.

The documentation now specifies that the pod readiness SLA for Azure Kubernetes Service (AKS) Automatic guarantees that 99.9% of qualifying pod readiness operations will complete within 5 minutes, enhancing the reliability of self-healing infrastructure for applications. This clarification helps users understand the performance expectations and differentiators of AKS Automatic more clearly.

The documentation for the Container Network Insight Agent has been updated to reflect a change in its name to "Container Network Insights Agent." Additionally, clarifications have been made regarding a backend migration, emphasizing that it is nondisruptive and does not affect user experience, workloads, data collection, or monitoring functionality. Users can continue to utilize the Azure CLI, Azure portal, and all client experiences without any changes.

This document highlights the retirement of the Key Manager for Kubernetes extension on April 15, 2026, indicating that it will no longer be available for deployment or support. Users are directed to the AKS enabled by Azure Arc GitHub repository for further inquiries.

The document provides an overview of the Container Network Insights Agent for Azure Kubernetes Service (AKS), detailing its capabilities in troubleshooting networking issues. It emphasizes the agent’s ability to gather host-level network statistics and its role in diagnosing complex networking problems within AKS clusters.

The documentation now includes a new section on enabling LocalDNS for improved DNS resolution reliability in Azure Kubernetes Service (AKS). Users are advised to enable LocalDNS on their node pools to maintain service connectivity during transient DNS outages, as it deploys a DNS proxy on each AKS node, reducing reliance on centralized CoreDNS pods and preventing dropped DNS queries. Additionally, LocalDNS can serve stale cached responses when upstream DNS is unavailable, enhancing pod connectivity during disruptions.

Updated the document to reflect the latest practices for scaling Application Gateway for Containers, ensuring minimal downtime during updates and maintenance.

This document has undergone modifications in authorship, which could imply updates or enhancements in the management of namespaces within Azure AKS, contributing to better practices.

This document has been updated to reflect changes in authorship and metadata, ensuring that the content remains accurate and up-to-date for users seeking information on pod sandboxing in AKS.

This update includes significant content additions regarding the connectivity requirements for Application Gateway for Containers, detailing both outbound and inbound connectivity needs, including specific endpoints and their purposes. The date metadata was also updated to reflect the current version.

The document was updated to change the topic classification from ‘conceptual’ to ‘concept-article’, which may improve its discoverability and relevance in search results.

This file was modified to change its topic classification from ‘conceptual’ to ‘how-to’, indicating a shift towards practical guidance, which enhances its utility for users seeking implementation instructions.