The documentation now includes updated guidance on running Ray AI workloads with Kueue on Azure Kubernetes Service (AKS), replacing the previous focus on configuring and deploying a Ray cluster. Users can refer to the new section for detailed instructions on leveraging Kueue to enhance their AI workload management on AKS.

The documentation has been updated to reflect a change in the command for retrieving credentials for an Azure Kubernetes Service (AKS) cluster. Users should now use the command `az aksarc get-credentials –name <clusterName> –resource-group <RESOURCE_GROUP>` instead of the previous `az connectedk8s proxy` command. This change simplifies the process of accessing cluster credentials.

The documentation now clarifies that Kubernetes Event-driven Autoscaling (KEDA) is available in both AKS Automatic and AKS Standard modes, with KEDA preconfigured in AKS Automatic for immediate use, while AKS Standard requires enabling the KEDA managed add-on. Additionally, users are informed about a breaking change in KEDA version 2.15+, which removes pod identity support, and are advised to transition to workload identity for authentication. The updated content also emphasizes the benefits of using AKS Automatic for production workloads, highlighting reduced management overhead and built-in autoscaling capabilities.

The overview of deploying a Ray cluster on AKS has been revised to include updated descriptions and instructions for running AI workloads, emphasizing the use of Kueue for workload management.

The documentation for enabling the OIDC Issuer URL on existing AKS clusters has been updated to clarify the specific section for standard clusters. Users can now refer to the updated link for instructions on enabling the OIDC Issuer, ensuring they follow the correct procedure for their cluster type.

Learn how to connect to Azure Kubernetes Service (AKS) clusters, view cluster resources, deploy new applications, and manage existing applications using AKS desktop.

A new article detailing how to fine-tune the Qwen2.5-7B model using Ray on AKS. It includes prerequisites, setup instructions, and a comprehensive guide on submitting RayJobs for distributed training.

The documentation now includes clearer instructions for creating an AKS cluster by presenting two distinct options: **AKS Automatic** and **AKS Standard**. Users can choose the recommended AKS Automatic option for a fully managed experience or the AKS Standard option for more control over cluster configuration, with specific command blocks provided for each choice. Additionally, the tutorial emphasizes the need for an **Owner** or **Azure account administrator** role to create billable AKS resources.

The documentation for the AKS tutorial has been updated to clarify that users need permissions such as **Contributor** or **Owner** to create Azure resources, including a resource group and an Azure Container Registry. Additionally, the tutorial now specifies that users should use versioned image tags (e.g., `1.0` instead of `latest`) when building images for the services, which enhances version control and stability in deployments.

Significant updates were made to the NVIDIA GPU Operator documentation, including the replacement of references to the retired NCv3 SKU with the NC T4 GPU VM size. Additionally, broken links were fixed, enhancing the usability of the documentation.

Learn how to install, configure, and remove the Inspektor Gadget cluster extension on Azure Kubernetes Service (AKS) by using the Azure CLI.

This article provides updated documentation on deploying a Ray cluster on Azure Kubernetes Service (AKS), including new prerequisites and configurations for using Kueue for workload management. It emphasizes the integration of Ray with Azure services for efficient AI workload management.

The documentation for the AKS tutorial has been updated to include detailed steps for creating and managing Azure Service Bus resources, which are now essential for the tutorial. Users can now follow specific commands to create a Service Bus namespace and queue, set up authorization rules, and retrieve credentials necessary for their deployments. Additionally, the tutorial emphasizes the importance of using secure methods for handling sensitive information, such as API keys, in Kubernetes manifest files.

Learn how to use the kubectl gadget plugin to run gadgets and inspect DNS, file, process, and network activity on Azure Kubernetes Service (AKS).

The documentation now includes updated instructions for deploying a sample application to an AKS cluster using the AKS desktop application, allowing users to manage application health, logs, and metrics more easily. Users can also deploy applications directly from their workstation or through automation pipelines, with specific guidance on using Azure Pipelines, GitHub Actions, and Cloud Native GitOps. Additionally, the tutorial emphasizes the importance of using the correct image tags for container deployments, specifying version numbers instead of using the latest tag.

The documentation now reflects a change in the command for retrieving credentials for an Azure Kubernetes Service (AKS) cluster. Users should use the updated command `az aksarc get-credentials –name <clusterName> –resource-group <RESOURCE_GROUP>` instead of the previous `az connectedk8s proxy` command to access their cluster credentials. This change simplifies the process of connecting to AKS clusters.

The documentation now clarifies the differences between AKS Automatic and AKS Standard regarding Vertical Pod Autoscaler (VPA) setup. Users can now understand that in AKS Automatic, VPA is preconfigured and ready for production use, while in AKS Standard, users must configure VPA explicitly. Additionally, the guidance on deployment patterns for VPA has been refined to emphasize the importance of establishing observability through resource utilization telemetry.

This article has been updated to include new monitoring capabilities and best practices for AKS, particularly focusing on the integration of AKS Automatic features. It provides users with enhanced insights into monitoring their AKS clusters effectively.

The document explains how to use Image Cleaner on AKS to remove unused images with vulnerabilities. It highlights the differences in functionality between AKS Automatic and AKS Standard, ensuring users can maintain security effectively.

An article focused on configuring Kueue queues for managing Ray workloads on AKS. It explains the setup of ClusterQueues and LocalQueues, providing examples for both single and team queue configurations.

The documentation now specifies that starting with AKS version 1.36, new AKS Automatic clusters will use the Kubernetes Gateway API via the application routing add-on by default, making it the recommended ingress model for production workloads. Additionally, users are informed that they cannot enable both the application routing Gateway API and the Istio service mesh add-on simultaneously, and must delete specific Istio resources when transitioning between the two. The document also clarifies that the application routing Gateway API implementation supports managed ingress with operational safeguards, while certain features like TLSRoute-based SNI passthrough and egress traffic management remain unsupported.

Learn how to troubleshoot and recover from infrastructure errors when MOC is unreachable during AKS on Azure Local cluster or node pool creation or deletion.

This update includes detailed instructions on applying Azure Policy definitions to AKS clusters, emphasizing the importance of the Azure Policy add-on and the necessary prerequisites such as Terraform and Azure CLI versions. It also clarifies the process for verifying policy assignments and includes Terraform configuration examples.

The documentation has been updated to reflect changes in the memory size for the NVIDIA RTX Pro 6000 Blackwell GPU, now listed as 96 GiB instead of 48 GiB. Users can now utilize the `Standard_NC16_RTX6000Pro_1` and `Standard_NC32_RTX6000Pro_1` configurations with the increased memory capacity, enhancing their GPU resource allocation for workloads.

The documentation for using Microsoft Entra ID authorization for the Kubernetes API in Azure Kubernetes Service (AKS) has been updated to clarify that AKS Automatic clusters are preconfigured with Azure RBAC for Kubernetes authorization, eliminating the need to enable it manually. Additionally, the prerequisites section now specifies the required versions for Azure CLI and kubectl, and emphasizes that managed Microsoft Entra integration must be enabled on the cluster before adding Microsoft Entra ID authorization. Users can now better understand the setup process and requirements for both AKS Automatic and AKS Standard clusters.

The documentation now specifies that users can edit the scaling configuration for the order-service to set the number of replicas to 5, and it introduces a YAML autoscaler manifest for the store-front deployment, allowing users to define minimum and maximum replica counts. Additionally, the command to scale the AKS Standard cluster has been updated to increase the node count to 5 instead of 3, reflecting changes in cluster management practices. Users are also reminded that scaling operations can increase compute costs and require appropriate permissions.

The documentation for AKS private clusters has been enhanced to clarify the behavior of the Kubernetes API server when creating a private cluster using the `–enable-private-cluster` command. Users are now informed that by default, a public DNS name (public FQDN) may still be created unless the `–disable-public-fqdn` option is specified, which restricts access to private connectivity methods. Additionally, guidance is provided on when to keep or disable the public FQDN based on administrative preferences and security requirements.

The documentation now clarifies that the `SecurityPatch` channel is incompatible with Azure Policies that enforce a `deny` effect for customer-managed keys (CMK) for OS disk encryption. Users attempting to apply a security patch under such a policy will encounter a `RequestDisallowedByPolicy` error due to the temporary creation of a virtual machine scale set. For those needing to maintain a `deny` policy for CMK OS disk encryption, it is recommended to use the `NodeImage` channel instead.

This article has been updated to reflect the latest practices for deploying a Ray cluster for tuning with BlobFuse on AKS, emphasizing the integration of scalable storage for high-throughput data access.

Troubleshoot common installation, configuration, and runtime errors with the Inspektor Gadget cluster extension on Azure Kubernetes Service (AKS).

The documentation has been updated to reflect the use of the OpenID Connect (OIDC) issuer in Azure Kubernetes Service (AKS), replacing references to the OIDC provider. Users can now configure the OIDC issuer in both AKS Automatic, where it is preconfigured, and AKS Standard, where it may need to be enabled based on the cluster version. Additionally, the documentation clarifies that for newly created AKS Standard clusters on Kubernetes version 1.34 or later, the OIDC issuer is enabled by default, streamlining the setup process for users.

The Azure CNI Powered by Cilium documentation has been revised to clarify the steps required based on the AKS cluster mode. This change improves the clarity and usability of the documentation for users setting up their AKS clusters.

The documentation for AKS node auto-repair has been updated to clarify the functionality and behavior of the feature, including health detection, repair actions, limitations, and monitoring guidance for production workloads. Users can now better understand that both AKS Automatic and AKS Standard clusters come preconfigured with node auto-repair, and they are informed about the specific scenarios where automatic repair may not occur. Additionally, the article emphasizes the importance of combining node auto-repair with workload-level resiliency practices to minimize user-visible impact.

This update includes clarifications on the Encryption in Transit (EiT) feature for NFS file shares and managed identity support for Azure Files in AKS, ensuring users are informed about the latest capabilities and limitations. It also corrects the heading capitalization for better readability.

This article describes how to run batch inference using Ray on AKS, detailing the setup for Kueue and the necessary environment configurations. It provides practical examples for submitting RayJobs for inference tasks.

The documentation has been updated to replace all mentions of the retired NCv3 SKU with the NC T4 GPU VM size in the commands for configuring AKS managed GPU nodes. Users will now see the updated command syntax using `–node-vm-size Standard_NC4as_T4_v3`, ensuring they are using the current VM size for their GPU workloads. Additionally, broken links have been fixed to improve access to relevant resources.

The document updates the guidance on using KEDA for event-driven autoscaling in AKS, replacing references to retired SKUs with current options. It emphasizes the preconfiguration of KEDA in AKS Automatic, enhancing the autoscaling capabilities for users.

Learn how to deploy the AKS cluster, KubeRay operator, Kueue controller, and Azure Blob storage for running Ray AI workloads.

The document provides an overview of Azure RBAC integration with AKS, detailing how to manage access to AKS resources and Kubernetes API. It emphasizes the importance of enabling Azure RBAC during cluster creation and outlines the roles available for managing access.

The document has been updated to correct a typo regarding the node subnet in the VNet, improving the technical accuracy of the content. This change is important for users relying on precise networking information.

The documentation now clarifies that AKS Automatic clusters come preconfigured with LocalDNS, enhancing DNS performance and resiliency without additional setup. In contrast, LocalDNS is optional for AKS Standard, requiring users to enable and configure it separately. Additionally, the article provides updated insights on LocalDNS capabilities, including reduced DNS resolution latency and customizable DNS behavior, which users can leverage to optimize their AKS workloads.

The documentation now clarifies that node resource group lockdown is preconfigured in AKS Automatic clusters, eliminating the need for a separate enable command. Users can also configure lockdown levels in AKS Standard clusters, with specific commands provided for creating, updating, and removing lockdown settings using the `az aks create` and `az aks update` commands. Additionally, the section on restriction levels has been expanded to detail the behaviors associated with ReadOnly and Unrestricted settings.

The documentation now clarifies that AKS Automatic clusters are preconfigured to use the Standard tier during creation, which is recommended for most production workloads. Additionally, users can now see detailed comparisons of the Free, Standard, and Premium pricing tiers, including specific use cases and limitations for each tier, such as node support and uptime SLA coverage. The commands for creating and updating AKS clusters have also been updated for clarity, including examples for setting the tier and support plan.

The tutorial has been updated to clarify that it only applies to AKS Standard clusters and includes important notes about permissions and resource creation.

This newly added catalog provides an overview of the Inspektor Gadget extension for AKS, detailing various gadgets available for monitoring and troubleshooting workloads. It categorizes gadgets based on their functionality, enhancing user understanding and accessibility.

This document outlines the configuration and management of LocalDNS in Azure Kubernetes Service, detailing its benefits for DNS resolution performance and resiliency. It includes guidance on enabling and customizing LocalDNS for different AKS cluster modes.

The documentation has been updated to remove the 90-day limit comment regarding Node Auto-Provisioning (NAP). Users can now understand that NAP will always force the latest image version to be picked up, regardless of the age of the existing node image version, thereby bypassing any existing maintenance window. This change clarifies the behavior of NAP for users managing their AKS clusters.

This article explains how Azure Kubernetes Service (AKS) can automatically block cluster upgrades when deprecated Kubernetes API usage is detected. It provides guidance on how to remediate or bypass validation, ensuring smoother upgrade processes and reducing unexpected disruptions.

The documentation for restricting SSH access has been updated to reflect changes in the link structure. This ensures users are directed to the correct resources for managing SSH access in AKS on Azure Local.

A new guide on fine-tuning the Aurora weather model using Ray on AKS, detailing the integration of Kueue for managing workloads and providing step-by-step instructions for setup and execution.

The documentation for using the Azure Linux Container Host on Azure Kubernetes Service (AKS) has been updated to clarify its integration with AKS Automatic and AKS Standard clusters. Users can now understand that Azure Linux is preconfigured as the default operating system for the system node pool in AKS Automatic, streamlining the setup for production workloads. Additionally, the documentation emphasizes the deployment options for Azure Linux, allowing users to choose it explicitly in AKS Standard based on their workload requirements.

The documentation now emphasizes that when scaling beyond 1,000 nodes without using the cluster autoscaler, users should scale in batches of 500-700 nodes at a time, with a recommended wait time of two to five minutes between scale-up operations to avoid Azure API throttling. This guidance is reiterated for clarity, ensuring users are aware of best practices for managing large-scale AKS clusters effectively.

The documentation now includes a critical note advising against the use of Azure Spot node pools for production-critical stateful workloads. It highlights that Spot VMs can be evicted unexpectedly, which may lead to abrupt node terminations and delays in volume recovery or pod rescheduling. Users are encouraged to utilize regular node pools and appropriate storage resiliency mechanisms for workloads that require persistent data and high availability.

This article provides updated instructions for serving models online using Ray on AKS, detailing the setup of RayService and the necessary configurations for persistent HTTP endpoints.

The documentation has been updated to recommend using the `Standard_NC4as_T4_v3` VM size for AKS node pools instead of the previously mentioned `Standard_NC6s_v3`. This change affects the command syntax, where users should now specify `–node-vm-size Standard_NC4as_T4_v3` to set the VM size for nodes in the pool. Additionally, the NVv4 series (based on AMD GPUs) remains unsupported on AKS.

Learn about the Inspektor Gadget cluster extension, an eBPF-based tool that helps you inspect and troubleshoot workloads on Azure Kubernetes Service (AKS) clusters.

The documentation now specifies that the only supported GPU model is the NVIDIA RTX Pro 6000 Blackwell with 96 GiB of memory, updated from the previous 48 GiB. This change impacts users by allowing them to utilize a more powerful GPU for compute-intensive workloads, enhancing performance capabilities in their deployments. For further details on supported GPU-enabled VM sizes and deployment steps, users can refer to the section on using GPUs for compute-intensive workloads.

The document details the use of API Server VNet Integration in Azure Kubernetes Service (AKS), highlighting its preconfiguration in AKS Automatic and the optional nature in AKS Standard. It emphasizes the benefits of using AKS Automatic for production workloads.

The documentation has been updated to refine the Valkey solution overview and deployment details, including the deployment of three Valkey primary pods across two availability zones with one replica pod per primary in a third zone. It emphasizes the use of `StatefulSet` resources with `spec.affinity` rules for high availability, and provides a comparison of key features between the Valkey solution and Azure Cache for Redis Premium tier.