Visual Studio Code AKS Tools

Introduction

Azure Kubernetes Service (AKS) Extension for Visual Studio Code helps enable AKS developers with one-click quick to deploy features with in vscode eco-system.

Features

See the Features index for the full list, grouped by task.

For an exhaustive, generated list of every command, setting and pinned tool version, see the Reference.

Development and Release

• Release notes
• How to release
• Development
• Webview Development

Installation

1. Download and install the Azure Kubernetes Service extension for Visual Studio Code.

2. Wait for the extension to finish installing then reload Visual Studio Code when prompted.

3. Once the installation is complete, you’ll see a section named Azure under Clouds.

4. Sign in to your Azure Account by clicking Sign in to Azure…, (Afternatively, user can use ctrl + shift + p or cmd + shift + p and choose AKS: Sign in to Azure) screenshot below could guide the switch for account as well. If your account has access to more than one Azure tenant, you will be prompted to pick one. To change the selected tenant later, you can run AKS: Select tenant... from the command palette ctrl + shift + p or cmd + shift + p.

Development

Guidance for working on the extension itself.

• Package Scripts — npm scripts to build, run, and test.
• Webview Development — developing the webview-ui front end.

Package Scripts

This gives an overview of the npm scripts available for development and release of the extension. See the scripts block in package.json.

These can all be run from the command line in the root of the repository (with npm installed), using npm run {script-name}.

Environment Initialization

• install:all: Installs npm dependencies for both the main extension project and the webview-ui sub-project. It’s recommended to use this instead of npm install, which will only install dependencies for the main project.

Development and Testing

• dev:webview: for concurrent development/debugging of webview UX.
• build:webview: bundles and minifies the webview UX for consumption by the extension.
• webpack: builds and packages the extension.
• test: runs automated tests.
• test:scripts: runs the unit tests for the scripts/ tooling. Plain node and mocha, so no compile step.

Documentation

These validate this book against what package.json actually contributes, so command IDs, setting names and menu paths in prose cannot drift from the extension.

• docs:check: runs all documentation checks. Pass names to run a subset, for example npm run docs:check menu-paths.
  • identifiers: flags an aks.* or azure.* identifier in prose that package.json does not contribute. Fenced code blocks are skipped, so a sample quoting another extension’s settings is not an error.
  • menu-paths: flags a menu breadcrumb that does not match the real menu.
  • menu-syntax: flags menu navigation written as prose instead of **A** > **B**. See below.
  • coverage: warns about a command documented nowhere in prose.
  • orphans: warns about an image no page references.
• docs:reference: regenerates the reference pages under src/reference/. These carry a DO NOT EDIT header — change the generator or package.json, not the output.
• docs:reference:check: fails if those pages are stale. Run docs:reference and commit the result.

Links, images, anchors and SUMMARY.md completeness are deliberately not checked here. lychee --offline --include-fragments covers the first three and handles raw HTML and URL fragments properly, and mdbook build with create-missing = false fails on a SUMMARY.md entry with no page.

Writing menu navigation

Write navigation with > between the steps, and bold each one:

Right-click your AKS cluster > **Troubleshoot & Diagnose** > **Troubleshoot Network Health** > **Collect TCP Dumps**

Not as prose:

Right-click your AKS cluster and select **Troubleshoot & Diagnose** and then
click on **Collect TCP Dumps**

menu-paths only recognises the first form, so an instruction written the second way is skipped rather than validated — the page can go stale and nothing reports it. menu-syntax exists to make that a visible error instead of silence.

The convention is not only for the tooling. > states where the menu ends, which prose cannot: “click Create Cluster and select Create Standard Cluster” reads as two menu levels, but the second is a button in the wizard the first opens. Writing the menu part with > and leaving the rest as prose keeps that boundary clear for readers too.

If a line mentions right-click without giving an instruction — naming the context menu, say — put this marker on the page:

<!-- docs-check: not-a-menu -->

Documenting the classic menu

The menu layout depends on the aks.simplifiedMenuStructure setting, which defaults to true. menu-paths validates breadcrumbs against that default.

A page that deliberately documents the classic layout (the setting turned off) opts out by including this marker anywhere in the file, usually in an HTML comment:

<!-- docs-check: classic-menu -->

Breadcrumbs on that page are then accepted if they match either menu. Use it only for pages genuinely about the classic layout — a breadcrumb that is simply out of date should be fixed, not marked.

Not for Running Directly

Some scripts are invoked by other scripts or tools, so need not be run directly, or are otherwise not required for general development tasks:

• vscode:prepublish: used by the vsce command for packaging the extension into a vsix file for distribution.
• webpack-dev: builds the webview-ui project and then bundles the extension code in development mode (--watch). This is the preLaunchTask for the Extension debug profile (F5).
• test-compile: compiles the extension typescript (after building the webview-ui project) without webpacking it. This is a prerequisite to running automated tests. It could be moved into test, but keeping it separate would allow it to be used in the future as a prelaunch task for debugging the extension without webpacking it.
• watch: not currently used as part of any workflow I’m aware of, but could potentially be useful for editing while debugging.

Local VSIX Sharing and How to Share via a GitHub Comment

Follow these steps to modify the package.json version, generate a VSIX file, and prepare it for sharing as a renamed file in a GitHub comment:

Step 1: Update the package.json Version

1. Open the package.json file in your project directory.
2. Find the "version" field.
3. Update it to a unique test version (e.g., 1.0.0-test.1 or include a timestamp for uniqueness).
   Example:

   {
     "name": "my-extension",
     "version": "1.0.0-test.1",
     "main": "extension.js"
   }
   

4. Save your changes.

Step 2: Generate the VSIX File

1. Open a terminal in your project directory.
2. Run the following command to package the extension: (How to install vsce)

   vsce package
   

3. A file like my-extension-1.0.0-test.1.vsix will be created in your project directory.

Step 3: Rename the File for Sharing

1. Rename the VSIX File: GitHub does not allow direct upload of files with the .vsix extension. To work around this:

   • Rename the file by appending .zip to the original name.
     Example:
     Rename filename.vsix to filename.vsix.zip.

2. Upload to GitHub:

   • Drag and drop the renamed file (filename.vsix.zip) into your GitHub comment or PR description.

Final Notes

• This renaming approach avoids additional steps like zipping or compressing the file.
• The development team is typically familiar with this process, making it a quick and effective way to share test versions.

Happy coding! 🚀

Webview Development

For commands that require a webview (see guidance on where this is appropriate), the webview-ui project provides the necessary tooling to develop the front end.

Initial Setup

Run npm run install:all to install package dependencies for both the extension and webview project.

Development/Debugging

File structure

• Webview source files are under /webview-ui/src.
• When built, bundled/minified webview assets are output to /webview-ui/dist.

When the extension is run (both in development and production), the webview assets are read from /webview-ui/dist.

Developing the UI

If you like to use your browser development tools for debugging, or you wish to open the web application in an existing browser window:

1. Run npm run dev:webview to start the development server.
2. Navigate to http://localhost:3000 in your browser.

Alternatively, if you are developing in VS Code and wish to use the inbuilt debugging functionality:

1. Hit F5 to launch the Webview UI debug profile in a new browser window. This will automatically run the development server and attach a debugger.

Developing the VS Code commands that launch the UI

Prerequisite: Run npm run install:all at least once before debugging (see Initial Setup). A plain npm install does not install the webview-ui dependencies, so the webview build produces no assets and panels render blank.

To debug the extension itself, hit F5 to launch the Extension debug profile in a new VS Code Window. This will automatically build the webview-ui project (via npm run build:webview) and bundle the extension, so the assets in /webview-ui/dist are always present.

The extension will not automatically update itself in response to code changes as you are debugging, so the best workflow here is to stop debugging, make changes, and launch the debugger again.

Custom UI Elements

Most input components have been intentionally designed to be theme-aware by default, inheriting VS Code’s global design tokens to stay in sync with the user’s selected theme. This includes buttons (which can be styled using our secondary-button and icon-button classes), anchor tags, <option> elements, and common input types like radio, checkbox, and text.

To keep things consistent while avoiding unnecessary dependencies, we also include a small set of custom components:

• <CustomDropdown> and <CustomDropdownOption> provide a theme-integrated dropdown experience.
• <ProgressRing> is a simple, consistent loading indicator that fits right in with VS Code’s UI.

These components help us maintain a clean, unified look without relying on external UI libraries — and give us more control over the details when we need it.

Building for release

The process for this is unaffected by the webview setup. The npm run webpack and vsce package commands will ensure the webview-ui project is built and bundled.

Features

Once you sign in with your Azure account, your AKS clusters appear under the Azure section of the Cloud Explorer. Right-click a cluster to reach these actions. Cluster commands are grouped under Develop & Deploy, Troubleshoot & Diagnose, and Manage Cluster — see Simplified AKS Menu Structure.

For the full list of commands and where each one lives, see the command reference.

Cluster access and properties

• Merge and Save Into Kubeconfig
• Show Properties, Show in Azure Portal
• Compare 2 AKS Clusters within the Same Subscription
• Manage Cluster Operations

Troubleshooting and diagnostics

• AKS Diagnostics
• Kubernetes API Health Endpoints
• Inspektor Gadget
• Collect TCP Dumps
• Run Retina Distributed Capture
• Garbage Collection Using Eraser Image Cleanup Tool

Develop and deploy

• Run Kubectl Commands
• Install Azure Service Operator
• Deployment Tools: Draft Tool Integration
• Argo CD GitOps Integration
• Container Assist (Preview)
  • Azure Resources and Permissions
  • AI Data Flow and Privacy
  • GitHub Workflow and OIDC Setup
• Containerization Assist Skills for Copilot Chat (Preview)

AI and models

• Install and Deploy KAITO Models
• Manage and Test KAITO Deployments
• AKS MCP Server
• Kickstart Agent for AKS Automatic (Preview)
• AKS Plugins for GitHub Copilot for Azure

Fleet and configuration

• AKS Fleet Manager
• Simplified AKS Menu Structure

Merge and Save Into Kubeconfig

These two commands are provided by the Kubernetes extension, not by this one. They are listed here because they appear on the same AKS cluster node in the Cloud Explorer, and because that extension is installed automatically as a dependency of this one.

Merge into Kubeconfig

Right-click your AKS cluster > Merge into Kubeconfig to add the cluster to your existing kubeconfig file, leaving any other contexts in place.

Save Kubeconfig

Right-click your AKS cluster > Save Kubeconfig to write the cluster’s kubeconfig to a file you choose, without touching your existing kubeconfig.

Because these commands come from the Kubernetes extension, their exact labels and menu placement are controlled by that extension and can change independently of this one.

AKS Diagnostics

AKS Diagnostics

Right-click your AKS cluster > Troubleshoot & Diagnose > Run AKS Diagnostics to display diagnostics information based on your AKS cluster’s backend telemetry for:

• Create, Upgrade, Delete and Scale
• Network Connectivity Issues
• Best Practices
• Identity and Security
• Node Health
• Cluster and Control Plane Availability and Performance
• Storage

To perform further checks on your AKS cluster to troubleshoot and get recommended solutions, click on the AKS Diagnostics link at the top of the page to open it for the selected cluster. For more information on AKS Diagnostics, visit AKS Diagnostics Overview.

Install Azure Service Operator

Install Azure Service Operator

Right-click your AKS cluster > Develop & Deploy > Install Azure Service Operator to easily deploy the latest version of Azure Service Operator (ASO) on your AKS cluster and provision and connect applications to Azure resources within Kubernetes. When you select this option, you’ll be prompted for a service principal for ASO to use when performing Azure resource operations. This service principal must have appropriate permissions (typically Contributor at suitable scope). Fill out the service principal details and click Submit to kick off the installation of Azure Service Operator.

Install Azure Service Operator can only be performed on an AKS cluster that has never had ASO installed before. If you have already initiated the installation manually, follow the instructions on Azure Service Operator to complete.

For more information on Azure Service Operator, visit Azure Service Operator (for Kubernetes). If you are experiencing issues with Azure Service Operator, visit Azure Service Operator (ASO) troubleshooting.

Show Properties, Show in Azure Portal

Show in Azure Portal

Right-click your AKS cluster > Show In Azure Portal to navigate to AKS cluster overview page in Azure Portal.

Show Properties

Right-click your AKS cluster > Show Properties to display the AKS cluster and agent pool properties like provisioning state, fqdn, k8s version, along with node properties like node version, vm type, vm size, o/s type, o/s disk size and nodes provisioning state.

This page also enables some useful cluster and node pool level operations like Abort Last Operation (at cluster and agent pool level) and Reconcile.

This page now also enable information box for the users to quickly see available kuberentes versions available for the cluster to upgrade and if the current version is out of support or not.

Create cluster from Azure Portal

Right-click your Azure subscription > Create Cluster > Create Cluster From Azure Portal to navigate to AKS create cluster page in Azure Portal.

Create cluster

Right-click your Azure subscription > Create Cluster > Create Cluster From VS Code, which starts a 2-step wizard for you to enter a valid cluster name and select an existing resource group. The VS Code experience will then notify user with the deployment progress and present you with the Navigate to Portal link when it completes successfully.

Start or Stop AKS cluster

Right-click your AKS cluster > Show Properties to display the AKS cluster properties. Within the page there will be Stop/Start Cluster button to perform the start or stop the cluster operation.

Run Kubectl Commands

Run Kubectl Commands from your AKS cluster

Right-click your AKS cluster > Develop & Deploy > Run Kubectl Commands to run common kubectl commands against your cluster. The panel groups them into two sections.

Resources

Health

User can also run custom commands by typing or editing kubectl command parameters in the text field. Custom commands can optionally be saved for future use..

Manage Cluster Operations

Run cluster operations from your AKS cluster

Right-click your AKS cluster > Manage Cluster to run cluster operations:

• Delete Cluster
• Reconcile Cluster
• Rotate Cluster Certificate

To abort an in-progress operation, open Show Properties and use the abort action on the cluster or agent pool.

Kubernetes API Health Endpoints

Run Kubernetes API Health Endpoints

Right-click your AKS cluster > Develop & Deploy > Run Kubectl Commands, then run a command from the Health section:

Inspektor Gadget

Deploy and Undeploy InspektorGadget

Right-click your AKS cluster > Troubleshoot & Diagnose > Show Inspektor Gadget to deploy the gadget into your cluster. You can deploy and undeploy the gadget from this page.

Profile, Top, Trace and Snapshot Inspektor Gadget Commands

Right-click your AKS cluster > Troubleshoot & Diagnose > Show Inspektor Gadget, then choose Gadget Commands to use non-interactive Top, Trace, Profile or Snapshot commands for your cluster.

Shortcuts for common troubleshooting scenarios

Alongside the general gadget commands, the menu offers shortcuts for the problems you are most likely to be investigating. If Inspektor Gadget is not yet deployed to the cluster, the extension offers to deploy it first.

Depending on the context, the appropriate gadget will be selected automatically and the gadget dialog will open with the relevant options.

Investigate DNS

Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Investigate DNS to troubleshoot DNS-related issues in your cluster. This provides specialized tools for monitoring DNS queries and identifying connectivity problems.

Real-time TCP Monitoring

Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Real-time TCP Monitoring to monitor TCP connections and network traffic in real-time. This helps identify network bottlenecks and connection issues.

Troubleshoot Resource Utilization

Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Resource Utilization to analyze CPU, memory, and other resource usage patterns across your cluster. This helps identify resource constraints and optimization opportunities.

The Troubleshoot Resource Utilization menu includes the following sub-options:

• Identify files being read and written to: Monitor file system operations to understand which processes are accessing specific files.
• Investigate Block I/O: a submenu containing Identify Block I/O intensive processes, which detects processes with high disk usage to identify potential performance bottlenecks.
• Profile CPU: Take samples of stack traces to analyze performance issues and identify resource-intensive processes.

Improve security of my cluster

Right-click your AKS cluster > Troubleshoot & Diagnose > Improve security of my cluster > View processes executed in the kernel to use the trace_exec gadget under the hood to monitor when new processes are executed.

Collect TCP Dumps from AKS Cluster Linux Nodes

Collect TCP Dumps

Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Collect TCP Dumps to capture TCP dumps for any Linux node and download them to your local machine with ease.

Added filters to the TCP Dump functionality, so that you can target traffic capture to specific network interfaces, ports or protocols, to or from specific pods, or craft custom pcap filter strings.

Compare 2 AKS Cluster within Same Subscription

Compare AKS Clusters

Right-click your Azure subscription > Compare AKS Cluster to use VS Code diff to compare json object of 2 AKS clusters.

Garbage collection Using Eraser Image Cleanup Tool

Run Eraser Image Cleanup

Right-click your AKS cluster > Troubleshoot & Diagnose > Run Eraser Image Cleanup to deploy the Eraser Tool to automatically clean images in a regular interval for the selected AKS Cluster.

Run Retina Distributed Capture from AKS Cluster Linux Nodes

Run Retina Capture

Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Run Retina Capture to capture logs like iptables-rules, ip-resources.txt and other key distributed captures from this Azure networking tool for any Linux nodes in your AKS cluster.

There are two options to run the capture:

Download the capture locally

Step 1: Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Run Retina Capture > Download Artifacts Locally

Step 2: Select the nodes on which you want to run the capture

Step 3: Download the capture locally after the capture is completed

Upload the capture to Azure Storage

Before uploading the capture to Azure Storage, ensure the following prerequisites are met:

1. A storage account exists in the same region as your AKS cluster.

2. The storage account is configured in the Diagnostic settings of your AKS cluster.

3. A container is created within the storage account to store the capture.

Step 1: Right-click your AKS cluster > Troubleshoot & Diagnose > Troubleshoot Network Health > Run Retina Capture > Upload Artifacts to Blob Storage

Step 2: Select the storage account where you want to upload the capture

Step 3: Select the container within the storage account where you want to upload the capture

Step 4: Select the nodes on which you want to run the capture

Step 5: Success message will be displayed once the capture is completed and uploaded to the selected storage account

Step 6: Check the storage account to access the uploaded capture files. The files will be stored in the selected container with a timestamp

Deployment Tools: Draft Tool Integration

The extension bundles the Draft tool to scaffold deployment assets for your project. The version is set by the aks.drafttool.releaseTag setting; for the version currently pinned, see Pinned versions.

Available commands

Creating a GitHub workflow and creating an Argo CD application both require an open workspace folder. The Argo CD command is also gated by aks.argoCDEnabled, which is on by default.

Create a GitHub Workflow

Generates a starter GitHub Actions workflow, pre-populated with the selected cluster and resource names, for deploying to AKS with either Helm or Kubernetes manifests.

Run Deployment Safeguards YAML Validation

Validates Kubernetes manifests against Deployment Safeguards and reports findings, so you can catch policy violations before applying them to a cluster.

Generating Dockerfiles and manifests

To scaffold a Dockerfile and Kubernetes manifests for an application, use Container Assist.

The older Draft Dockerfile and Draft Deployment screens are still present, but they are not in the Command Palette or on any menu. They open only from links inside other Draft screens — the GitHub workflow screen reaches both, from the Deployment Tools: Create a Dockerfile and Deployment Tools: Create a Deployment links in its opening paragraph.

Deploying Apps to AKS with GitHub Actions and Container Assist (Preview)

Please Note This is a preview feature. Behavior, prompts, and generated output may change between releases.

AI Notice Container Assist uses AI models to analyze project context and generate deployment files. Always review generated files before use, and do not include secrets or sensitive data in source files used for generation. See AI Data Flow and Privacy for details on what data is sent to AI models.

Technology Note This experience is built on Azure/containerization-assist, which combines AI generation with a specialized containerization toolchain and knowledge/policy guidance for Docker and Kubernetes workflows.

Container Assist is a preview workflow in the AKS VS Code extension that helps generate deployment assets for AKS directly from your project.

• Detailed documentation
• Problem this feature solves
• How this feature helps
• Why this is different from generic AI code generation
• Prerequisites
  • Required software
  • Required accounts
  • Azure resources that must already exist
  • Workspace requirements
  • Optional extensions
• Supported languages and project types
• Turning Container Assist off
• Where you can launch it
• User flow and options
  • Azure context selection
  • Deployment file generation
  • Workflow generation
• GitHub integration story
• Configuration reference
• Deployment annotations
  • Deployment annotations
• Screenshots
  • Menu entry points
  • Container Assist and GitHub integration flow
• Troubleshooting
  • “No Language Model available”
  • OIDC setup fails with “SAML SSO required”
  • Some role assignments failed
  • Azure RBAC is not enabled on the cluster
  • Project type not detected
  • “GitHub authentication failed”
  • Repository is archived or read-only
  • Partial secrets set
  • No Azure subscriptions found

Detailed documentation

For in-depth coverage of specific topics, see:

• Azure Resources and Permissions – Azure resources created, role assignments, and prerequisite permissions
• AI Data Flow and Privacy – What data is sent to AI models, blocked files, and security protections
• GitHub Workflow and OIDC Setup – Workflow template details, OIDC configuration, GitHub secrets, and post-generation flow

Problem this feature solves

Deploying an application to AKS with a GitHub Actions pipeline usually requires multiple manual steps:

• Creating and tuning a Dockerfile
• Authoring Kubernetes manifests for deployment and service resources
• Creating a CI/CD workflow for build, push, and deploy
• Wiring Azure authentication and repository workflow setup

This process is flexible, but often time-consuming and error-prone, especially when teams are setting up deployment automation for a new or existing project.

How this feature helps

Container Assist reduces setup friction by guiding you through:

• Repository analysis
• Dockerfile generation
• Kubernetes manifest generation
• Optional GitHub workflow generation
• Optional PR-ready Git staging flow

This gives teams a review-first starting point so they can iterate quickly while keeping full control over the final deployment configuration.

Why this is different from generic AI code generation

Container Assist is not a single free-form prompt that guesses deployment files from source code alone.

It uses a structured, workflow-driven approach based on containerization-assist capabilities:

• Repository-aware analysis first (analyze-repo) to detect language, framework, and module shape
• Knowledge-enhanced planning for Dockerfile and Kubernetes outputs
• Security and quality guidance in the tool flow (for example vulnerability and best-practice checks)
• Policy-driven extensibility so organization standards can shape recommendations
• Clear next-step/tool-chain guidance for staged execution from analysis to deployment verification

For AKS migration and onboarding scenarios, this helps teams move from app code to deployable AKS artifacts with better consistency and less manual trial-and-error.

Prerequisites

Before using Container Assist, make sure the following are in place.

Required software

Required accounts

Azure resources that must already exist

Container Assist does not create these for you – they must be provisioned before you start:

Workspace requirements

Optional extensions

Supported languages and project types

Container Assist uses the containerization-assist SDK to detect your project’s language and framework by scanning for specific files in your workspace. The following project types are supported:

Container Assist also reads additional files for context when present (such as Dockerfile, docker-compose.yml, application.properties, application.yml), but these are not required for language detection.

If your project type is not in the list above, it is treated as other, and the generated files may be less accurate.

Turning Container Assist off

Container Assist is available by default. If you would rather not see its commands, add this to your settings and reload the window:

{
  "aks.containerAssistEnabledPreview": false
}

You can also change this from the VS Code Settings UI.

Where you can launch it

Container Assist can be launched from:

• Explorer folder context menu: AKS: Migrate Application to AKS, AKS: Generate Dockerfiles and K8s Manifests for App, AKS: Deploy App with Automated Pipeline
• AKS cluster context menu, under Develop & Deploy: the same three commands

The Explorer entries require aks.containerAssistEnabledPreview (enabled by default) and a folder selection. On the cluster menu, AKS: Migrate Application to AKS needs only the setting; the other two also need an open workspace folder.

User flow and options

After launch, you can select one or both actions:

• Generate Deployment Files
• Generate GitHub Workflow

Azure context selection

Before generation begins, you are guided through Azure resource selection:

1. Subscription – select your Azure subscription (skipped if launched from AKS cluster tree)
2. AKS cluster – select the target cluster (skipped if launched from AKS cluster tree)
3. Namespace – select or enter a Kubernetes namespace on the cluster
4. Azure Container Registry – select an ACR from your subscription. If the ACR is not already attached to the cluster, you are prompted to assign the AcrPull role. See Azure Resources and Permissions for details.

Deployment file generation

If Generate Deployment Files is selected, the flow analyzes your project and generates:

• Dockerfile at project root (or selected module path)
• Kubernetes manifests under your configured manifests folder (default: k8s)

The analysis detects your project’s language, framework, ports, dependencies, and entry points. If existing Dockerfiles or manifests are found, the extension detects them and can enhance rather than overwrite. See AI Data Flow and Privacy for how AI models are used during generation.

Workflow generation

If Generate GitHub Workflow is selected, a GitHub Actions CI/CD workflow is configured for the selected AKS/Azure context. See GitHub Workflow and OIDC Setup for details on the generated workflow.

If both actions are selected, deployment file generation runs first, then workflow generation.

GitHub integration story

When generated files are ready, the post-generation flow is designed for PR-friendly collaboration:

1. OIDC setup prompt (when workflow is generated):
   • Configure Pipeline with Managed Identity – creates Azure managed identity, federated credentials, role assignments, and sets GitHub secrets. See GitHub Workflow and OIDC Setup for the full process and Azure Resources and Permissions for what is created.
   • Skip
2. Review prompt:
   • Stage & Review
   • Open Files
3. If you choose staging, files are staged and Source Control is focused with a suggested commit message.
4. After commit, you are prompted to create a pull request.
5. PR creation can run through the GitHub Pull Requests extension, with default branch and draft behavior from settings.

This supports a full path from local generation to reviewable GitHub PR with minimal manual glue steps.

Configuration reference

aks.containerAssistEnabledPreview : Enable/disable the Container Assist preview entry points. Default: true.

aks.containerAssist.k8sManifestFolder : Folder name for generated Kubernetes manifests. Default: k8s.

aks.containerAssist.enableGitHubIntegration : Enables Git/GitHub integration in the post-generation flow.

aks.containerAssist.promptForPullRequest : Reserved setting for PR prompting behavior.

aks.containerAssist.prDefaultBranch : Default base branch for PRs. Default: main.

aks.containerAssist.prCreateAsDraft : Create PRs as draft by default. Default: true.

aks.containerAssist.modelFamily : Default model family used by Container Assist. Default: gpt-5.2-codex.

aks.containerAssist.modelVendor : Default model vendor used by Container Assist. Default: copilot.

Deployment annotations

The generated workflow annotates resources in your cluster after each deployment. These annotations use the aks-project/ prefix, which is a shared schema read by both this extension and aks-desktop.

Deployment annotations

Applied to all deployments in the namespace via kubectl annotate deployment --all:

Screenshots

Menu entry points

Container Assist and GitHub integration flow

Troubleshooting

“No Language Model available”

Container Assist requires a language model provided by GitHub Copilot. If you see this error:

1. Install the GitHub Copilot extension.
2. Sign in with a GitHub account that has an active Copilot subscription.
3. Try launching Container Assist again.

If models are available but the preferred model (gpt-5.2-codex / copilot by default) is not found, the extension falls back to the first available model with a warning. You can change the preferred model via the aks.containerAssist.modelFamily and aks.containerAssist.modelVendor settings.

OIDC setup fails with “SAML SSO required”

If your GitHub repository belongs to an organization that enforces SAML single sign-on, you must authorize your GitHub token for that organization before the extension can set repository secrets. When this happens, the extension shows an Authorize Token button that opens the SSO authorization page in your browser. Complete the authorization and retry.

Some role assignments failed

During OIDC setup, role assignments are attempted individually. If some succeed and others fail, you see a warning listing the roles that could not be assigned. This can happen if:

• Your Azure account lacks sufficient permissions (you need Microsoft.Authorization/roleAssignments/write on the target scope).
• The target resource is locked or has a deny assignment.

The warning tells you which roles to assign manually. See Azure Resources and Permissions for the full list of roles and their scopes.

Azure RBAC is not enabled on the cluster

When Azure RBAC is disabled on the AKS cluster, the extension skips the AKS RBAC Writer role assignment for standard (user) namespaces. This is expected behavior – the role only applies to clusters with Azure RBAC enabled. ACR-related roles (AcrPush, Container Registry Tasks Contributor) are still assigned regardless.

For managed namespaces, AKS RBAC Writer is always assigned at namespace scope, regardless of the cluster-level Azure RBAC setting.

Project type not detected

If Container Assist does not detect your project’s language, ensure your workspace root contains one of the supported indicator files (see Supported languages and project types). Projects classified as other may produce less accurate Dockerfile and manifest output.

“GitHub authentication failed”

This error appears when the extension cannot obtain a GitHub token. Make sure:

1. You have a GitHub account with access to the target repository.
2. VS Code can authenticate with GitHub (the built-in GitHub Authentication provider should be available).
3. You grant the requested repo scope when prompted.

Repository is archived or read-only

OIDC setup cannot set secrets on archived GitHub repositories. If you see a message about the repository being archived, you need to unarchive it first in GitHub settings, or set the required secrets manually.

Partial secrets set

If some GitHub secrets were set but others failed, the extension reports which secrets could not be written. You can set the missing secrets manually in your repository’s Settings > Secrets and variables > Actions page. The required secrets are:

• AZURE_CLIENT_ID – client ID of the managed identity
• AZURE_TENANT_ID – Azure AD tenant ID
• AZURE_SUBSCRIPTION_ID – Azure subscription ID

See GitHub Workflow and OIDC Setup for details on how these secrets are used in the workflow.

No Azure subscriptions found

If the extension shows a warning about no subscriptions, verify that:

1. You are signed in to Azure in VS Code.
2. Your Azure account has at least one active subscription.
3. The subscription filter in the Azure extension is not hiding your subscriptions.

Azure Resources and Permissions

This page documents every Azure resource that Container Assist creates on your behalf, every role assignment it makes, and the Azure permissions you need to use the feature.

Prerequisites: Azure Account Permissions

Container Assist operates across multiple resource groups and requires both resource management and role assignment permissions. This section explains which built-in roles work, which don’t, and why.

Which built-in roles work?

Why Contributor alone is not enough: The Contributor role explicitly excludes Microsoft.Authorization/roleAssignments/write. Container Assist assigns up to 5 RBAC roles: one in stage 1, plus four in stage 2, whose user-namespace and managed-namespace paths are mutually exclusive (see Role Assignments below). Without role assignment permissions, the OIDC setup completes partially – the managed identity and federated credential are created, but the pipeline will fail at runtime because the identity lacks access to the cluster and ACR. The extension warns you which roles could not be assigned so you can request them from an admin.

Why subscription-level access is needed

Container Assist touches up to 4 separate resource groups during a single run:

The extension also lists all AKS clusters and ACRs across the subscription during the selection wizard, which requires subscription-level read access (Microsoft.Resources/subscriptions/resources/read).

If your account is scoped to a single resource group, the cluster/ACR listing fails before you can even start.

Detailed permission breakdown

For least-privilege or custom role setups, here are the specific permissions required:

These permissions must be granted at subscription scope (or across all relevant resource groups) for the full workflow to succeed.

Azure Resources Created

Container Assist may create the following Azure resources during the OIDC setup flow. These resources appear in your Azure subscription and may incur governance or cost implications.

Resource Group

User-Assigned Managed Identity

Note: If you select “Use existing managed identity”, no new identity is created. The selected identity is reused.

Federated Identity Credential

The subject uses your repository’s owner/repo from the git remote and the detected default branch (usually main).

Role Assignments

Container Assist assigns Azure RBAC roles at two distinct stages: ACR selection (during the main wizard) and OIDC setup (when configuring the GitHub workflow pipeline). The principals and scopes differ between these stages.

Stage 1: ACR Selection (Main Wizard)

When you select an Azure Container Registry that is not already attached to your AKS cluster, the extension offers to assign the AcrPull role:

Why: This allows your AKS cluster to pull container images from the selected ACR at runtime. Without this, pod image pulls will fail with authentication errors.

Principal: The AKS cluster’s kubelet identity (from identityProfile.kubeletidentity). For service-principal-based clusters, the service principal is used instead.

Stage 2: OIDC Setup (GitHub Workflow Pipeline)

When you run the OIDC setup to configure GitHub Actions authentication, role assignments are created for the OIDC managed identity (the identity that your GitHub Actions workflow uses to authenticate with Azure). The roles assigned depend on whether you are deploying to a user namespace or a managed namespace.

User Namespace Path

For standard (non-managed) Kubernetes namespaces:

Note on role #4: The AKS RBAC Writer role is only assigned when the cluster has Azure RBAC enabled (aadProfile.enableAzureRBAC). If the cluster uses Kubernetes-native RBAC instead, this role is skipped and you will need to create a Kubernetes ClusterRoleBinding or RoleBinding manually.

Managed Namespace Path

For AKS managed namespaces, roles are scoped to the specific namespace rather than the entire cluster:

AI Data Flow and Privacy

This page documents how Container Assist uses AI models, what data from your project is sent to cloud AI services, what data stays local, and the security protections in place.

Architecture: Local Analysis + Cloud AI Generation

Container Assist uses a two-phase architecture:

1. Phase 1 – Local analysis (no network calls): The containerization-assist-mcp/sdk runs entirely on your machine. It scans your project filesystem to detect languages, frameworks, dependencies, ports, and entry points. No data leaves your machine during this phase.

2. Phase 2 – Cloud AI generation: The results of that local analysis are formatted into prompts and sent to a VS Code Language Model (via the vscode.lm API) to generate Dockerfiles and Kubernetes manifests. This phase involves cloud AI calls.

What AI Models Are Used

• Container Assist uses the VS Code Language Model API (vscode.lm), which routes requests through GitHub Copilot’s infrastructure.
• On launch, you can choose “Use Default Model” or “Select Model…” to pick from any available VS Code language model.
• If the configured default model is not found, the first available model is used as a fallback.

What Data Is Sent to the AI Model

Per-Interaction Overview

Container Assist makes two AI calls per module in your project:

1. Dockerfile generation – one AI call
2. Kubernetes manifest generation – one AI call

Each call includes a system prompt, a user prompt, and tool definitions. The AI may then invoke tools to read additional files from your project (up to 20 rounds of tool calls per interaction).

System Prompts (Static, Hardcoded)

The system prompts are fixed strings that describe the AI’s role and workflow. They do not contain any of your project data. They instruct the AI to:

• Act as an expert at creating Dockerfiles or Kubernetes manifests
• Use tools (readProjectFile, listDirectory) to verify project details before generating
• Output content in a specific <content> marker format

User Prompts (Contain Project Data)

The user prompt is built from the local SDK analysis and includes:

For Dockerfile generation:

• Detected programming language (e.g., “typescript”, “python”, “java”)
• Framework names and versions (e.g., “Express v4.18.0”)
• Entry point path (e.g., “src/index.ts”)
• Detected ports (e.g., “3000, 8080”)
• First 15 dependency names (e.g., “express, pg, redis, …”)
• SDK recommendations: build strategy, base image suggestions, security considerations, optimizations
• Existing Dockerfile content (if present), including analysis and enhancement guidance
• Language-specific verification hints (what config files to check)

For Kubernetes manifest generation:

• All of the above, plus:
• Application name (e.g., “my-app”)
• Target Kubernetes namespace
• Full image repository URL (e.g., myacr.azurecr.io/my-app)

Tool Calls (AI Reads Your Files)

During generation, the AI can invoke two tools to inspect your project:

readProjectFile

Reads a file from your project. The AI decides which files to read based on the analysis.

• Input: Relative file path, optional line limit
• Output: File content (up to 200 lines)
• Typical files read: package.json, tsconfig.json, pom.xml, Dockerfile, go.mod, source entry points, configuration files

listDirectory

Lists files and subdirectories in your project.

• Input: Relative directory path, optional max depth
• Output: Tree listing of files and directories (up to 200 entries, max 3 levels deep)
• Excluded from listings: node_modules, .git, dist, build, target, bin, obj, __pycache__, venv, .next, .nuxt

The AI can make up to 20 rounds of tool calls per interaction. In each round, it may call multiple tools concurrently. After 20 rounds, a final request is sent without tools to force the AI to produce its output.

What Data Is NOT Sent

Blocked Sensitive Files

The following files are blocked from being read by the AI, even if it requests them:

If the AI requests a blocked file, the tool returns an error and the AI must proceed without that file’s content.

Path Traversal Protection

All file access tools enforce strict path boundaries:

• .. path segments are rejected (no escaping the project root)
• Absolute paths are rejected
• Windows drive paths and UNC paths are rejected
• The resolved path is verified to remain within the workspace root

What Stays Entirely Local

The following data is processed locally and never sent to any AI model:

• Your Azure subscription, cluster, ACR, and namespace selections
• Managed identity details, role assignments, federated credentials
• GitHub repository secrets
• Git history and commit data
• The workflow YAML template (generated from a local template, not AI)
• File write operations (Dockerfile, manifests, workflow files)

Summary: Data Flow by Destination

GitHub Workflow and OIDC Setup

This page documents the GitHub Actions workflow that Container Assist generates, the OIDC setup process for Azure authentication, and the GitHub secrets that are configured.

Generated Workflow Overview

Container Assist generates a GitHub Actions workflow file at .github/workflows/<name>.yml in your project. The workflow has two jobs:

1. buildImage – Builds the container image and pushes it to Azure Container Registry
2. deploy – Deploys the application to AKS using the generated Kubernetes manifests

The workflow uses OIDC (OpenID Connect) for passwordless authentication with Azure – no long-lived secrets like client secrets or certificates are stored in GitHub.

Workflow Template Variants

Two workflow templates exist, selected automatically based on your namespace type:

Every action in these templates is pinned to a commit SHA rather than a tag. The tables below name the actions without versions, because those move; for the version each one is currently pinned to, see Pinned versions, which is generated from the templates themselves.

Workflow Configuration Values

The following values are injected into the workflow template. All deployment-specific values are inlined as workflow-level env: variables, not secrets:

Workflow Jobs and Steps

Job: buildImage

Note: Images are built in the cloud using ACR Tasks (az acr build), not with a local Docker daemon. This is why the OIDC managed identity needs the Container Registry Tasks Contributor role in addition to AcrPush. See Azure Resources and Permissions for the full role assignment details.

Job: deploy (depends on buildImage)

GitHub Actions Permissions

Both jobs request these permissions:

GitHub Secrets

The workflow references three GitHub repository secrets for OIDC authentication:

These are not long-lived credentials. They are identifiers used together with the OIDC federated credential to obtain short-lived Azure AD tokens at workflow runtime.

OIDC Setup Process

When a GitHub workflow is generated, Container Assist prompts you to configure OIDC authentication. This is the process that creates the Azure managed identity, federated credential, and sets the GitHub secrets.

Step-by-Step Flow

Phase 1: Gather Information

1. Detect GitHub repository – reads git remote origin URL and parses owner/repo. Detects the default branch from refs/remotes/origin/HEAD, falling back to checking for origin/main or origin/master.

2. Prompt for Azure configuration:

   • Subscription – uses the subscription from the main wizard if available, otherwise prompts
   • Resource group – input box, default: rg-<appName>-oidc
   • Managed identity – choose “Create new” or “Use existing” (lists identities in the resource group)
     • If new: enter name (default: id-<appName>-github) and Azure region (default: eastus)

Phase 2: Azure Resource Creation

3. Create or retrieve managed identity:

   • If new: creates resource group (if needed), then creates managed identity with tags
   • If existing: retrieves the selected identity

4. Assign role permissions:

   • Roles differ by namespace type – see Azure Resources and Permissions for the complete list
   • Role assignments are idempotent (re-running OIDC setup will not create duplicate assignments)

5. Create federated identity credential:

   • Name: GitHubActions
   • Issuer: https://token.actions.githubusercontent.com
   • Subject: repo:<owner>/<repo>:ref:refs/heads/<branch>
   • Audiences: api://AzureADTokenExchange

Phase 3: Set GitHub Secrets

6. Display results with three options:
   • “Set secrets” – authenticates with GitHub (requires repo scope), encrypts secrets using the repository’s NaCl public key, and sets them via the GitHub API
   • “Copy secrets and set manually” – copies all three secret key-value pairs to your clipboard
   • “View Output” – logs the detailed summary to the VS Code output channel

GitHub Authentication for Setting Secrets

When you choose “Set secrets”, the extension:

1. Requests a GitHub session via vscode.authentication.getSession("github", ["repo"]) – you may see a GitHub OAuth consent prompt
2. Verifies repository access (checks you have push or admin permissions, and the repo is not archived)
3. Fetches the repository’s public encryption key
4. Encrypts each secret value using NaCl sealed-box encryption (libsodium-wrappers)
5. Sets each secret via the GitHub Actions API (createOrUpdateRepoSecret)

GitHub SSO Note: If your repository is in a GitHub organization that requires SAML SSO, the extension detects the X-GitHub-SSO response header and provides an authorization URL to complete SSO before retrying.

Managed vs. User Namespace Differences

The namespace type affects multiple aspects of the generated workflow and OIDC configuration:

See Azure Resources and Permissions for the complete role assignment matrix.

Post-Generation Flow

After files are generated, the post-generation flow guides you through:

1. OIDC Setup Prompt

Shown only when a workflow was generated:

“Your pipeline needs an Azure Managed Identity to connect to AKS…”

Options: “Configure Pipeline with Managed Identity” or “Skip”

2. Stage and Review

“{N} files generated. Stage them and open Source Control to review?”

Options: “Stage & Review” or “Open Files”

• Stage & Review: Stages all generated files via the Git extension API, pre-fills a commit message (e.g., "Add: Dockerfile, k8s manifests and GitHub Action workflow for myapp"), and focuses the Source Control panel.
• Open Files: Opens all generated files in editor tabs, then offers staging.

3. Pull Request Creation

After you commit (from the SCM view, terminal, or any method), a one-time event listener detects the commit and offers:

“Changes committed. Would you like to create a pull request?”

Options: “Create Pull Request” or “Dismiss”

PR creation requires the GitHub Pull Requests extension (github.vscode-pull-request-github). If not installed, the extension offers to install it.

The PR is created with:

• Title: "feat: Add container and K8s deployment files for <appName>"
• Base branch: configured via aks.containerAssist.prDefaultBranch (default: main)
• Draft: configured via aks.containerAssist.prCreateAsDraft (default: true)
• Body: Markdown template listing generated files with a description and next-steps checklist

Containerization Assist Skills for Copilot Chat (Preview)

Overview

The Containerization Assist (CA) skills are five agent skills that expose containerization capabilities directly inside GitHub Copilot chat, so users can containerize a workload and deploy it to AKS through a chat-first workflow. The skills are packaged from the containerization-assist-mcp npm dependency and shipped inside this extension — no separate MCP server, tool install, or extension is required.

Contributed skills (via contributes.chatSkills):

• analyze-repo — inspect the workspace and infer language, framework, and containerization needs.
• generate-dockerfile — produce a Dockerfile grounded in analyze-repo output and CA’s Dockerfile knowledge base.
• fix-dockerfile — validate an existing Dockerfile and apply fixes against CA’s policy set.
• generate-k8s-manifests — produce Kubernetes manifests (deployment, service, configmap) with production-safe defaults.
• deploy-to-aks — orchestrate the full analyze → generate → build → push → apply → verify loop against an AKS cluster.

The skills are a Preview feature and are available by default when the AKS extension is installed.

Motivation

CA already ships as a standalone MCP server that any editor can consume. Contributing the same skills through the AKS extension delivers three things that the standalone MCP server alone does not:

1. Zero setup for AKS users. CA’s containerization knowledge — Dockerfile generation, policy-driven fixes, K8s manifest generation, and the AKS deploy loop — becomes available the moment the AKS extension is installed. Users do not need to install a second extension, register an MCP server, or manage a separate process.
2. Chat-first workflow. The existing Container Assist features in this extension (enabled via aks.containerAssistEnabledPreview) are command- and panel-driven. The CA skills complement those by exposing the same underlying capabilities inside Copilot chat as agentic slash-command flows — better suited to iterative, conversational work.
3. A single AKS surface for containerization + deploy. Combined with the Kickstart agent, the AKS extension can now guide a user from an uncontainerized workspace to a running deployment on AKS entirely from chat, using one consistent set of AKS-specific defaults.

Availability

The five CA skills are included and registered automatically. No feature flag or additional setup is required. The aks.containerAssistEnabledPreview setting controls the separate command-based Container Assist flows, while aks.kickstartEnabledPreview controls the Kickstart agent and its supporting skills.

How the Skills Are Packaged

At build time, webpack.config.js copies node_modules/containerization-assist-mcp/skills/ into dist/skills/. Each of the five entries in contributes.chatSkills points at ./dist/skills/<name>/SKILL.md, so the packaged extension ships the skill definitions directly and stays in sync with the CA version pinned in package.json.

Related Documentation

• Use Container Assist (Preview) — the command-based Container Assist experience (separate preview flag).
• Kickstart Agent for AKS Automatic (Preview) — the AKS Automatic onboarding chat agent.

Kickstart Agent for AKS Automatic (Preview)

Overview

The Kickstart agent is an AI-guided onboarding experience that deploys a containerized application to AKS Automatic end-to-end, contributed as a VS Code chat agent. It is designed for users who want to ship an app to AKS without deep Kubernetes expertise — Kickstart walks through discovery, infrastructure configuration, design, artifact generation, review, and deploy as a single conversational flow.

Kickstart is a Preview feature and is gated behind a setting.

Enabling the Feature

💡 Important Note: Kickstart is disabled by default. To enable it, add the following line to your user settings.json file:

"aks.kickstartEnabledPreview": true

You can open this file by pressing Ctrl+Shift+P (or Cmd+Shift+P on macOS), selecting Preferences: Open Settings (JSON), and adding the setting within the top-level JSON object. Reload the window after changing the setting.

The same flag also gates:

• The kickstart and kickstart-reviewer chat agents (contributed via contributes.chatAgents).
• The 19 kickstart phase and domain skills used by the agent (contributed via contributes.chatSkills).
• The two Kickstart commands listed below.

Features

Launch the Kickstart Agent

Starts the guided AKS Automatic onboarding flow. Available from the Command Palette or by selecting kickstart in the Copilot chat agent picker.

Command: AKS: Launch Kickstart Agent (aks.kickstart.launchExperience)

The agent walks through seven sequential phases:

1. Discover — understand the app (language, dependencies, ports, environment variables) and map each service.
2. Configure Infrastructure — create new or select existing Azure resources (resource group, AKS Automatic cluster, ACR).
3. Design — propose the target architecture and confirm with the user.
4. Generate — create Dockerfile(s), Kubernetes manifests, Bicep, and a GitHub Actions workflow.
5. Review — hand off to the internal kickstart-reviewer agent to validate every artifact against a security + AKS Automatic compliance checklist.
6. Pre-Deploy Check — verify the cluster is ready and ACR is attached.
7. Deploy — build, push, apply, and health-check the running app.

Configure a Kickstart Cluster

Provisions or updates an AKS Automatic cluster suitable for Kickstart deploys, without going through the full agent flow.

Command: AKS: Configure Kickstart Cluster (aks.kickstartCluster)

Related Documentation

• The Kickstart agent and its skills live under agents/ and skills/ in this repository.
• Kickstart hands generated artifacts off to kickstart-reviewer for validation before deploy — this handoff is internal and not user-invocable.

AKS Plugins for GitHub Copilot for Azure

Overview

The AKS plugins (or skills) for GitHub Copilot for Azure (@azure) extension enable users to perform various tasks related to Azure Kubernetes Service (AKS) directly from the GitHub Copilot Chat view. These skills include creating an AKS cluster, deploying a manifest to an AKS cluster, and generating Kubectl commands.

Features

💡 Important Note: To disable the GitHub Copilot AKS hook in VS Code, add the following line to your user settings.json file:

"aks.copilotEnabledPreview": false

You can open this file by pressing Ctrl+Shift+P (or Cmd+Shift+P on macOS), selecting Preferences: Open Settings (JSON), and adding the setting within the top-level JSON object.

Create an AKS Cluster

Users can quickly set up an AKS cluster using simple, natural language prompts. This reduces the complexity and time required to manually configure and deploy a Kubernetes cluster.

You can create an AKS cluster using the following prompts:

• [@azure] can you help me create a Kubernetes cluster
• [@azure] can you set up an AKS cluster for me?
• [@azure] I have a containerized application, can you help me create an AKS cluster to host it?
• [@azure] create AKS cluster
• [@azure] Help me create a Kubernetes cluster to host my application

Deploy a Manifest to an AKS Cluster

Users can deploy their application manifests to an AKS cluster directly from the GitHub Copilot Chat view. This simplifies the deployment process and ensures consistency. By using predefined prompts, the risk of errors during deployment is minimized, leading to more reliable and stable deployments.

To deploy a manifest file to an AKS cluster you can use these prompts:

• [@azure] help me deploy my manifest file
• [@azure] can you deploy my manifest to my AKS cluster?
• [@azure] can you deploy my manifest to my Kubernetes cluster?
• [@azure] deploy my application manifest to an AKS cluster
• [@azure] deploy manifest for AKS cluster

Generate Kubectl Command

Users can generate various Kubectl commands to manage their AKS clusters without needing to remember complex command syntax. This makes cluster management more accessible, especially for those who may not be Kubernetes experts. Quickly generating the necessary commands helps users perform cluster operations more efficiently, saving time and effort.

You can generate various Kubectl commands for your AKS cluster using these prompts:

• [@azure] list all services for my AKS cluster
• [@azure] kubectl command to get deployments with at least 2 replicas in AKS cluster
• [@azure] get me all services in my AKS cluster with external IPs
• [@azure] what is the kubectl command to get pod info for my AKS cluster?
• [@azure] Can you get kubectl command for getting all API resources

Overall, these features enhance the user experience by making it easier to manage AKS clusters, deploy applications, and execute commands, all from within the GitHub Copilot Chat view. This integration promotes a more seamless and productive workflow for DevOps engineers and developers

Simplified AKS Menu Structure

When you right-click an AKS cluster, the commands are grouped by the kind of task you are doing rather than listed all at once. This is how the menu behaves by default.

If you preferred the previous layout, run AKS: Switch to Classic Menu — see Switching between Classic and Grouped menus.

How commands are grouped

Rather than one long list of top-level commands, cluster actions sit in three submenus:

• Develop & Deploy
• Troubleshoot & Diagnose
• Manage Cluster

These stay top-level: Show In Azure Portal, Show Properties, AKS Quick Actions, and Switch to Classic Menu.

Menu grouping overview

Develop & Deploy : Run Kubectl Commands, Attach ACR to Cluster, Create a GitHub Workflow, Run Deployment Safeguards YAML Validation, Install Azure Service Operator, the Deploy a LLM with KAITO submenu, Check Argo CD Status (with aks.argoCDEnabled), and the Container Assist commands (with aks.containerAssistEnabledPreview).

Troubleshoot & Diagnose : The Run AKS Diagnostics, Troubleshoot Network Health, Troubleshoot Resource Utilization, and Improve security of my cluster submenus, plus Show Inspektor Gadget and Run Eraser Image Cleanup.

Manage Cluster : Show Properties, Show In Azure Portal, Delete Cluster, Rotate Cluster Certificate, Reconcile Cluster.

Where the Container Assist commands appear

With aks.containerAssistEnabledPreview enabled (the default), AKS: Migrate Application to AKS appears under Develop & Deploy. With a workspace folder also open, AKS: Generate Dockerfiles and K8s Manifests for App and AKS: Deploy App with Automated Pipeline appear alongside it.

Switching between Classic and Grouped menus

Two commands let you switch menu modes without opening Settings:

Both commands are available in:

• The Command Palette (Cmd+Shift+P / Ctrl+Shift+P).
• The AKS cluster context menu (right-click on a cluster in the Azure/Kubernetes Cloud Explorer).
  Only the applicable command is shown — if the grouped menu is active you see “Switch to Classic Menu”, and vice versa.

After running either command, VS Code prompts you to reload the window. The new menu layout takes effect after the reload.

Changing it in Settings instead

If you would rather set this directly, the menu is controlled by aks.simplifiedMenuStructure. Set it to false for the classic menu, where seven submenus — Run AKS Diagnostics, Deployment Tools, Managed Cluster Operations, Troubleshoot Network Health, Troubleshoot Resource Utilization, Improve security of my cluster and Deploy a LLM with KAITO — sit directly on the cluster context menu instead of being grouped into the three role-based submenus:

{
  "aks.simplifiedMenuStructure": false
}

Reload the VS Code window afterwards.

Screenshots

Install and Deploy KAITO models

The KAITO integration enables seamless installation of KAITO onto your clusters, empowering you to deploy AI models, manage workflows, and test deployments with ease and precision.

Install KAITO

Right-click your AKS cluster > Develop & Deploy > Deploy a LLM with KAITO > Install KAITO to open the KAITO installation page.

Once on the page, click Install KAITO and the KAITO installation process will begin. Once KAITO has been successfully installed, you will be prompted with a “Generate Workspace” button that will redirect you to the model deployment page.

Deploy a model

On a cluster that already has KAITO installed, right-click the cluster > Develop & Deploy > Deploy a LLM with KAITO > Create KAITO Workspace to open the KAITO model deployment page.

Once on this page, you can click any of the models to open up the side panel, which will present you with the option to either Deploy Default workspace CRD or Customize Workspace CRD.

Click Deploy Default workspace CRD to deploy the model. It will track the progress of the model and notify you once the model has been successfully deployed. It will also notify you if the model was already previously unsucessfully onto your cluster. Upon successful deployment, you will be prompted with a “View Deployed Models” button that will redirect you to the deployment management page.

Click Customize Workspace CRD to open up a CRD file pre-populated with the infromation necessary to deploy the model. You can alter this file to your desires and save it locally.

Manage and Test KAITO Deployments

Actively monitor the status of all KAITO deployments on the cluster, retrieve logs, test the inference servers, and delete/redeploy models.

Manage KAITO Deployments

Right-click your AKS cluster > Develop & Deploy > Deploy a LLM with KAITO > Manage KAITO Models.

Once on this page, you will see all existing KAITO deployments on the cluster, alongside their status (ongoing, successful, or failed).

For your selected deployment, click Get Logs to access the latest logs from the KAITO workspace pods. This action will generate a new text file containing the most recent 500 lines of logs.

To delete a model, select Delete Workspace (or Cancel for ongoing deployments). For failed deployments, choose Re-deploy Default CRD to remove the current deployment and restart the model deployment process from scratch.

Test a Model

On your desired model, select Test to access the model testing page.

Once on the testing page, you can modify the parameters and enter a prompt for submsission. Click Reset Params to reset all configurable parameters to their default values. Click Submit Prompt to submit your query.

AKS Fleet Manager

The extension allows you to create AKS Fleet Manager resources and visualize them in the tree view.

Create an AKS Fleet Manager

• Right-click on the subscription where you want to create a Fleet.
• Choose Fleet Manager, then select Create Fleet.

A loading screen will appear while resource groups and locations are being retrieved. Once loaded, an input form will be displayed.

Complete all required fields marked with an asterisk (*). If any input is invalid, an error message will indicate the issue and guide you on how to fix it.

Once all required fields are filled with valid inputs, submit the form to create the Fleet resource. A loading screen will appear while the API processes the request.

Upon successful creation, a confirmation page will be shown, including a link to view the newly created Fleet in the Azure portal.

If there is an error during creation, a failure page will be displayed with the error message from the API.

AKS MCP Server

The AKS extension registers a Model Context Protocol (MCP) server that gives Copilot Chat contextual access to your AKS clusters. The server is registered automatically — there is no setup command to run.

How to Use

1. Open the Command Palette (Cmd+Shift+P on macOS / Ctrl+Shift+P on Windows/Linux) and run MCP: List Servers.
2. Find AKS MCP in the list and start it. The first start downloads the server binary, and subsequent starts will use the stored copy.

Once started, the AKS MCP server appears in the Copilot Chat: Configure Tools dropdown.

Remote development (WSL, Remote-SSH, Dev Containers)

The server registers itself in whichever extension host you’re connected to, and the binary downloads to that same machine on first usage. No additional setup is required.

Limiting Enabled Components

Some components require local CLI tools (e.g. helm, cilium, hubble). The default configuration enables az_cli, monitor, fleet, network, compute, detectors, advisor, inspektorgadget, and kubectl to ensure a comprehensive setup out of the box. You can change this by setting aks.aksmcpserver.enabledComponents in your VS Code user settings.

"aks.aksmcpserver.enabledComponents": "az_cli,kubectl,monitor,network"

Available components: az_cli, monitor, fleet, network, compute, detectors, advisor, inspektorgadget, kubectl, helm, cilium, hubble. Set to an empty string to enable all components.

Pinning the Server Version

The extension pins a specific aks-mcp release via the aks.aksmcpserver.releaseTag setting. Override it to test a different release. Binaries are cached at ~/.vs-kubernetes/tools/aks-mcp/<version>/; you can delete old versions manually if needed.

Troubleshooting

• If the server doesn’t appear in MCP: List Servers, restart VS Code so the extension can re-register the provider.
• If the server fails to start, open MCP: List Servers, select AKS MCP, and choose Show Output to view the server log.

Argo CD GitOps Integration

The Argo CD integration brings a complete GitOps workflow to AKS clusters directly inside VS Code. Argo CD must be pre-installed on your cluster — the extension checks for its presence and directs you to the official docs if it is missing.

GitOps in one line — Argo CD is a controller that watches a Git repository for your Kubernetes manifests and continuously syncs the cluster to match them.

• Turning the Argo CD commands off
• Installation options
• Prerequisites
• Commands
• Create an Argo CD Application
• Apply an Application YAML to a Cluster
  • Open Argo CD UI
  • Configure Workload Identity for Azure (recommended)
  • Connect Private Repository (GitHub)
  • Sync Guide
• Check Argo CD Status
• Copilot Chat Integration
• Production topologies
• Security Notes
• Troubleshooting
• Further reading

Turning the Argo CD commands off

The Argo CD commands are available by default. If you don’t use Argo CD and would rather not see them, add this to your settings:

{
   "aks.argoCDEnabled": false
}

Then reload the VS Code window (Developer: Reload Window) for the change to take effect.

Installation options

The VS Code commands below work with either install path. Pick whichever fits your environment.

The extension uses two independent runtime probes:

• Install-method detection — the app.kubernetes.io/managed-by=Microsoft.ArgoCD pod label in the argocd namespace. Resolves to managed, upstream, or unknown (e.g. RBAC forbidden, transient kubectl failure). The post-apply menu only surfaces the Azure Workload Identity hint when this resolves to managed (or when SSO is independently detected, see below).
• Auth-mode detection — the argocd-cm ConfigMap’s oidc.config entry. When it references login.microsoftonline.com, the UI sign-in is treated as Entra ID SSO and the OSS admin-password flow is skipped.

These signals are orthogonal: a managed install can be configured without SSO, and — in principle — an upstream install can be wired to Entra ID by hand. The extension treats them as separate hints rather than collapsing them into one flag.

Public preview, Mar 2026. The Azure-managed extension is in public preview on AKS and Azure Arc-enabled Kubernetes — see the announcement blog.

Prerequisites

• A Kubernetes cluster with Argo CD installed via either of the Installation options above.
• kubectl available on your PATH (the extension uses the active kubectl context).
• A Git repository containing your Kubernetes manifests. These can live in the same repository as your application source or in a separate repository — whichever fits your workflow.

Commands

The integration provides four commands, all prefixed with AKS:

Create an Argo CD Application

1. Open the Command Palette (Cmd+Shift+P on macOS / Ctrl+Shift+P on Windows/Linux).
2. Run AKS: Create Argo CD Application.
3. Fill in the prompted parameters:
   • App name — validated as [a-z0-9][a-z0-9-]*.
   • Manifest repo URL — the Git repo Argo CD will watch. Enter manually, browse a local folder (reads .git/config origin automatically), or browse your GitHub repos (authenticates via VS Code’s built-in GitHub provider). This can be the same repo as your application source or a separate one.
   • Manifest path — the path within the repo that contains your Kubernetes manifests.
   • Output path — where to save the generated <app-name>.yaml manifest in your workspace.
   • Target namespace — where your workloads will be deployed.
   • Include a setup guide (README)? — optional, off by default. When enabled, a short <app-name>-README.md with install / UI-access / day-2 steps is written alongside the manifest.
4. The extension writes <app-name>.yaml — the Argo CD Application CR with all placeholders substituted — and opens it in the editor. There is no blocking pre-generate dialog; a non-modal notification with a Learn More link appears once the file is created.
5. A notification offers to apply the manifest to the cluster.

Apply an Application YAML to a Cluster

1. Open or right-click an Argo CD Application YAML file (.yaml / .yml).
2. Select AKS: Apply Argo CD Application to Cluster.
   • Alternatively, when you open an Application YAML, the extension detects it and shows an “Apply to Cluster” notification.
3. The extension:
   1. Validates the file is an argoproj.io/v1alpha1 Application.
   2. Resolves the active kubectl context (no subscription or cluster picker needed).
   3. Checks that Argo CD is installed (looks for the argocd namespace).
   4. Confirms the apply action.
   5. Runs kubectl apply -n <namespace> -f <file> --validate=false. Validation is skipped because Argo CD CRDs may not be present on the client.
4. After a successful apply, a notification offers four actions:

Open Argo CD UI

• If Argo CD is installed via the Azure-managed extension with Entra ID OIDC configured, the dialog prompts you to sign in with your Microsoft account — no admin password is fetched.
• If the argocd-server Service has a LoadBalancer with an external IP, the extension opens https://<address> directly.
• If the Service is ClusterIP (common for local setups), the extension starts a kubectl port-forward in an integrated terminal and shows an Open Browser button once the tunnel is ready. The local port matches the port Argo CD is configured to serve on (read from the argocd-cm ConfigMap’s url / global.domain, defaulting to 8080), so the opened URL stays aligned with the Entra ID redirect URI and SSO does not break.

Configure Workload Identity for Azure (recommended)

Shown only when both conditions hold:

1. spec.source.repoURL of the applied Application points at an Azure source:
   • ACR hosts: *.azurecr.io (OCI Helm chart / manifest sources).
   • Azure DevOps hosts: dev.azure.com/*, legacy *.visualstudio.com, and the SSH variants ssh.dev.azure.com / vs-ssh.visualstudio.com.
2. The cluster is running the Azure-managed Argo CD extension (managed-by label detected) or Entra ID SSO is already configured on the argocd-cm ConfigMap.

The action behaves differently depending on which install path was detected:

• Managed extension detected — runs a guided WIF bootstrap helper directly inside VS Code:
  1. Auto-detects the Argo CD ServiceAccount (argocd-repo-server by default) and the cluster’s OIDC issuer URL, and prints the federated-credential subject claim (system:serviceaccount:argocd:<sa>) and audience (api://AzureADTokenExchange) to the Argo CD output channel — with one-click clipboard copy.
  2. Opens the Azure Portal directly on Managed Identities (or App registrations) so you can paste those values into a new federated credential.
  3. Prints the final wiring steps: the AcrPull / Reader role assignment and the azure.workload.identity/client-id ServiceAccount annotation, plus the kubectl rollout restart command. The Microsoft Learn tutorial remains available as a fallback link.
• SSO-only (no managed-by label) — opens the Microsoft Learn tutorial directly, since the in-cluster annotations the bootstrap helper relies on may not match an upstream install.

Workload Identity Federation is the recommended credential path when running the Azure-managed Argo CD extension — no long-lived PATs or SSH keys are stored as Kubernetes Secrets.

Connect Private Repository (GitHub)

Shown only when the applied Application’s spec.source.repoURL is a private GitHub repository:

• Pre-populates owner/repo from the YAML and (when a silent VS Code GitHub session exists) resolves the numeric repo ID.
• Opens the GitHub fine-grained PAT creation page with the token name and repository pre-filled.
• Prompts for the PAT in a masked input (never logged, never written to disk).
• Creates a labelled Kubernetes Secret (argocd.argoproj.io/secret-type: repository) via kubectl create secret --from-literal so Argo CD auto-discovers it without a restart.

For Azure DevOps or ACR sources, prefer the Configure Workload Identity action above instead of creating a PAT secret.

Sync Guide

• Opens the Argo CD documentation for syncing applications.

Check Argo CD Status

1. Right-click your AKS cluster > Develop & Deploy.
2. Select AKS: Check Argo CD Status.
3. The Argo CD output channel shows:
   • Whether the argocd namespace exists.
   • Whether the Azure-managed Microsoft.ArgoCD extension is detected (via the app.kubernetes.io/managed-by pod label). Reported as managed, upstream, or could not determine when the label query fails (for example, due to RBAC).
   • Pod status (kubectl get pods -n argocd -o wide).
   • Service status (kubectl get svc -n argocd).
   • Tips for port-forwarding and authentication (SSO vs. initial admin password).

Copilot Chat Integration

An Azure AI Agent plugin (argoCDDeploymentPlugin) is registered for GitHub Copilot for Azure, so you can ask questions like:

• “How do I set up Argo CD on my AKS cluster?”
• “Create an Argo CD deployment for my cluster”

The plugin explains the GitOps principle and offers a button to launch the scaffold command directly from chat.

Production topologies

The scaffolded Application manifests work unchanged with the upstream-parity features of the Azure-managed extension:

• High availability (HA) — chosen at install time via the managed extension or upstream Helm chart; no change required to the generated YAML.
• Hub-and-spoke / multi-cluster — the Create Argo CD Application command generates a spec.destination.server you can point at a remote spoke cluster from a central hub.
• ApplicationSet — the extension generates a single Application. For generator-driven, multi-cluster rollouts (cluster generator, Git generator, etc.), write an ApplicationSet yourself alongside the generated <app-name>.yaml manifest; the Apply Argo CD Application to Cluster command accepts any argoproj.io/v1alpha1 resource.

Security Notes

• PATs and passwords are never written to disk or logged to output channels. Repo credential Secrets are created via kubectl create secret --from-literal (in-memory only).
• Workload Identity Federation is preferred over PATs for ACR and Azure DevOps sources when running the Azure-managed extension — no long-lived credentials are stored on the cluster.
• Entra ID SSO replaces the OSS argocd-initial-admin-secret flow when the managed extension is configured with OIDC; the extension auto-detects this and skips the password prompt.

Troubleshooting

Further reading

• Announcing public preview of the Argo CD extension on AKS and Azure Arc-enabled Kubernetes clusters — Azure Arc Blog, Mar 2026.
• Microsoft Learn: Use GitOps with Argo CD on Azure Arc-enabled Kubernetes.
• Argo CD upstream documentation.

Reference

Generated from package.json on every change, so these pages do not drift from the shipped extension.

• Commands — every command, its ID, and where it appears in the menus
• Settings — every setting, its type and default
• Pinned versions — third-party tool and GitHub Actions versions

The feature guides link here rather than restating command IDs and menu paths.

Commands

Every command the extension contributes, with where it appears in the tree-view menus.

The menu layout depends on the aks.simplifiedMenuStructure setting, which defaults to true. The Default menu column reflects that default; Classic menu applies when the setting is false. A dash means the command has no entry in that menu and is reachable only from the Command Palette.

Command Palette

63 of 66 commands are available from the Command Palette (Ctrl+Shift+P / Cmd+Shift+P).

Hidden from the palette (invoked from a menu or another command): aks.refreshSubscription, aks.containerizeAppFromTree, aks.deployAppWithAutomatedPipelineFromTree.

Menu placement

Settings

Configure these in Settings (Ctrl+, / Cmd+,) or in settings.json.

Pinned versions

Third-party versions the extension pins.

Tools

Each is overridable in settings.

GitHub Actions in generated workflows

Actions pinned to a commit SHA are shown with the tag from their trailing comment.

Release

Use this section to track reader-facing changes by version and maintain release process guidance.

• What’s New in 2.5.0
• Releasing Information

What’s New in 2.5.0

Everything added since 2.1.0, across the 2.2.0, 2.3.0, 2.4.0 and 2.5.0 releases. Full release history is on the GitHub Releases page.

GitOps with Argo CD, no setup required

Argo CD is now available out of the box — you no longer need to turn on a setting first.

• AKS: Create Argo CD Application scaffolds an application — on a folder’s context menu in the Explorer, or from the Command Palette. It asks you where your manifests are and where to write the output, and generates <app-name>.yaml. It no longer assumes your manifests live in a separate repository, and the README it produces is now optional.
• AKS: Apply Argo CD Application to Cluster deploys the generated YAML — on a YAML file’s context menu in the Explorer or editor.
• Right-click your AKS cluster > Develop & Deploy > AKS: Check Argo CD Status to see how the sync is going.

Argo CD itself still needs to be installed on your cluster; if it isn’t, the extension tells you and points you at the install steps.

See Argo CD GitOps Integration.

Deploy an app with the Kickstart agent (preview)

Kickstart is a Copilot chat agent that takes an application you already have and walks you all the way to it running on AKS Automatic — working out how to containerise it, creating the Azure resources, generating the manifests and pipeline, and deploying. Before it creates anything it shows you an estimated cost, and it favours regions that currently have capacity so you are less likely to hit a provisioning failure.

Kickstart is off by default. To try it, add this to your settings and reload:

{
  "aks.kickstartEnabledPreview": true
}

You will then have AKS: Launch Kickstart Agent and AKS: Configure Kickstart Cluster in the Command Palette.

Container Assist is easier to fit to your project

• Azure Container Registry is now optional, and you can pick which files you want generated instead of taking the whole set.
• Generated manifests no longer pick up build output. Directories like dist/, target/ and bin/ are skipped, so you get manifests for your application rather than for compiled artifacts.
• Deployment Safeguards validation now shows you what it found instead of stopping with an error, so you can see every policy issue at once and decide what to fix.
• Your own namespace annotations and labels are preserved when the extension updates a managed namespace.

See Container Assist Integration (Preview).

Cluster commands are grouped by task

The cluster context menu now groups commands into Develop & Deploy, Troubleshoot & Diagnose and Manage Cluster, so there is less to scan when you know what kind of task you are doing.

If you prefer the old layout, run AKS: Switch to Classic Menu at any time.

See Simplified AKS Menu Structure.

Where to go next

• What the extension can do
• Every command, setting and pinned tool version

How to Release

To make a new release and publish it to the marketplace you have to follow the following steps.

1. Create a branch publish-x.y.z
2. Update package.json with the new version
3. Refresh the pinned third-party versions (see Pinned third-party versions below)
4. Add a section to CHANGELOG.md with the header ## [x.y.z] (N.B: make sure to write the new version in square brackets as the changelog-reader action only works if the CHANGELOG.md file follows the Keep a Changelog standard)
5. Create a new PR, get approval and merge
6. Run the Build & Publish workflow manually from the GH Actions tab

Pinned third-party versions

Two independent sets of external versions are baked into this extension. Both drift silently between releases and should be reviewed each cut.

CLI binaries downloaded on demand

Defaults live in package.json under contributes.configuration. azure.kubelogin.releaseTag is the single source of truth for both the locally-downloaded kubelogin AND the kubelogin-version input in every generated GitHub Actions workflow — workflowTemplate.ts substitutes the setting value at generation time.

for repo in Azure/kubelogin Azure/aks-mcp Azure/draft microsoft/retina inspektor-gadget/inspektor-gadget; do
  echo -n "$repo: "; gh api "repos/$repo/releases/latest" --jq '.tag_name'
done

Before bumping, verify the target release actually has uploaded platform assets (curl -sI on a representative download URL and expect HTTP/2 200).

GitHub Actions pinned in workflow templates

The templates under resources/yaml/*.template.yaml pin these action majors. Major tags receive minor/patch fixes automatically — bumping is only needed when a new major ships. When bumping, update all template files that reference the action and the corresponding assertions in src/tests/suite/containerAssist/workflowTemplate.test.ts.

grep -h "uses:" resources/yaml/*.template.yaml | sort -u
for repo in actions/checkout Azure/login Azure/use-kubelogin Azure/aks-set-context Azure/k8s-deploy; do
  echo -n "$repo: "
  gh api "repos/$repo/releases" --jq \
    '[.[] | select(.prerelease==false and .draft==false)] | .[0].tag_name'
done

Skim the release notes of the target major before bumping. Recent Azure/* action majors have been pure Node.js runtime bumps (Node 20 → Node 24) and are safe. Watch for renamed/removed inputs or new required inputs.

Do not bump a version without a smoke test — generate a workflow via the extension, push it to a real branch on a real AKS cluster, and confirm the run succeeds. Bumping blindly is worse than staying pinned.

Build & Publish

The Build & Publish workflow allows to create a new release, package it in a VSIX file and publish to the VSCode marketplace with a single click.

The only requirement needed to run the workflow is to have a secret named VS_MARKETPLACE_TOKEN containing the Personal Access Token of the publisher. You can find more infos about how to create a publisher/token in the official documentation

Once everything is set up and you followed all first 4 steps in the previous section, you are ready to trigger the Build & Publish workflow. This is what it actually does:

1. Install all dependencies and build the project
2. Check if the CHANGELOG.md contains a section related to the new version
3. Create a new release
4. Create the VSIX file and publish it to the marketplace
5. Attach the VSIX file to the new release

Contributing

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Telemetry

This extension sends usage data to Microsoft to help us understand which features are used and where they fail, so we can improve them. This page describes exactly what is and is not sent. Telemetry respects your VS Code telemetry setting — if you have already turned telemetry off in VS Code, this extension sends nothing.

What we collect

Which features you use

• Which extension commands you run.
• Which screen you opened and which action you took in it — for example, that you opened the Create Cluster screen and started a cluster creation. What you typed into the form is not included.
• Whether creating a cluster succeeded.

How the GitHub Copilot for Azure (@azure) integration went

When you ask @azure to do something that involves AKS, we record how far the conversation got, so we can find where it breaks down:

• Which extension feature the request used.
• Whether you selected a subscription, a cluster, and a manifest file.
• Which of the cluster choices you picked.
• Whether you cancelled the deployment.
• Whether the deployment succeeded, and whether you clicked the link shown afterwards.

What we do not collect

We do not collect anything that identifies your code or your Azure resources. That includes:

• Cluster, resource group, subscription and registry names.
• File paths, image names and container registry contents.
• Anything you type into a form in the extension.
• The contents of your manifests, Dockerfiles or source code.

Container Assist does send your source code and project details to a language model in order to generate deployment files for you. That is a different thing from the usage data described here, and it is covered separately in AI Data Flow and Privacy.

How it is sent

The extension uses the standard VS Code telemetry library (@vscode/extension-telemetry), which sends the events above to Azure Application Insights. That library is what enforces your VS Code telemetry setting, so nothing leaves your machine when telemetry is off.

Turning it off

Set telemetry.telemetryLevel to off in your VS Code settings. This turns off telemetry for VS Code and every extension, including this one. If you have used the older telemetry.enableTelemetry setting, note that VS Code replaced it in version 1.61.

See the VS Code telemetry FAQ for details, and the Microsoft privacy statement for how Microsoft handles the data.