Operating AKS from your workstation: Inside Microsoft’s New AKS Desktop

There has long been a peculiar duality in managing Azure Kubernetes Service. The Azure portal offers abundant information but often feels disconnected from the cluster’s core functions. Meanwhile, Kubernetes is accessible through kubectl, YAML files, and dashboards like Headlamp. One exists within the Azure control plane, and the other entirely within the Kubernetes API. Operators frequently switch between these two realms multiple times daily, yet they never quite close the gap.

For years, we accepted this fragmentation as normal. The portal shows you the Azure environment. kubectl shows you the cluster state. Dashboards provide a limited view of the cluster. But none of these are operator workspaces. They are interfaces for infrastructure, configuration, or introspection, not for the day-to-day tasks of someone working in Kubernetes.

Microsoft finally recognized this gap and developed a dedicated tool for frequent AKS cluster operators. It’s not just another dashboard, portal pane, or kubectl wrapper. It’s a purpose-built local UI designed specifically for operators: AKS Desktop, built on Headlamp.

It immediately seems like an essential tool that should have been there from the start, a fast local client connecting the Kubernetes interface with the Azure environment. It acts as an operator cockpit tailored for AKS rather than a generic CNCF dashboard. This is where logs, events, node pools, networking, workload identities, and Azure integration coexist seamlessly. Most importantly, it eliminates the need to switch between browser tabs, CLI sessions, and external tools to grasp what your cluster is actually doing.

Before exploring its features, it’s important to clarify that AKS Desktop is currently in Public Preview. The UI might undergo changes, and features may evolve or be added. Expect some rough edges. Nonetheless, the core vision is clear: Microsoft aims to develop a local-first operator experience for Kubernetes on Azure. Even in its preview stage, it is already transforming how you work with AKS daily.

Where AKS Desktop Fits in an Operator’s World

Anyone managing multiple AKS clusters knows the operational surface gradually becomes a patchwork of various tools. The Azure portal provides views for upgrades, node pool management, and policy details, but hides the cluster’s internal workings. On the other hand, kubectl provides access to everything in the Kubernetes API but does not reveal Azure-specific aspects governing the cluster’s lifecycle, networking, and security. Tools like Lens and K9s help bridge some of these gaps, but they operate solely within the Kubernetes API. They lack understanding of Azure’s node pools, VMSS behavior, workload identity mappings, or the process of transitioning a cluster between API versions.

This fragmentation becomes exhausting quickly. You need logs, events, node pool status, workload identity bindings, ConfigMaps, deployment rollout updates, and Azure upgrade info, preferably all in one place without changing tools. Until now, that wasn’t feasible.

AKS Desktop fills that gap by positioning itself as a local desktop app that integrates closely with both Azure’s control plane and Kubernetes runtime. It uses your Azure CLI authentication, retrieves cluster details via ARM, and connects directly to the Kubernetes API with kubeconfig, combining all these elements into a unified visual map.

Almost immediately, it’s evident that AKS Desktop isn’t just another generic Kubernetes dashboard. It does not aim to compete with CNCF tools or replicate the Kubernetes dashboard. Instead, it emphasizes Azure-native features and a vendor-specific approach. When exploring an AKS cluster in AKS Desktop, users see Azure node pools, network overlays, workload identity resources, upgrade paths, and Azure Policy evaluations alongside Pods, Deployments, Services, and Ingress.

It offers a well-balanced combination of Azure Resource Manager, Kubernetes API, and operational workflows. This creates a user interface that truly resembles an operator cockpit for AKS, rather than just a generic dashboard repurposed for the purpose.

Installing AKS Desktop: The Start of a Local-First Workflow

The great thing is that installation is straightforward. It doesn’t involve backend systems or extensions, nor does it deploy controllers or operate inside the cluster. AKS Desktop is completely local, with authentication managed through your Azure CLI identity.

Before opening it for the first time, consider preparing your Azure environment.

az login
az account set --subscription "<your-subscription-id>"

All your security measures, whether Conditional Access, MFA, PIM, or strict governance, are seamlessly integrated into AKS Desktop since it just uses your Azure CLI tokens. You log in once, and everything else proceeds automatically.

On macOS, installation is straightforward: either download the DMG or use Homebrew.

brew tap azure/aks-desktop
brew install aks-desktop

Windows users can use Winget:

winget install Microsoft.AKSDesktop

Linux distributions can be installed using a .deb package or an archive. After installation, the application automatically detects all AKS clusters accessible to your identity, allowing you to generate or refresh the kubeconfig for any of them with a single click.

It’s refreshing that no components are deployed into the cluster. There are no agents, CRDs, DaemonSets, or any extensions to the Kubernetes API. The tool maintains a clear boundary between the local operator experience and the cluster runtime. The only interaction occurs via kubeconfig and the Azure control plane.

When you select a cluster, the application automatically activates. The cluster topology appears, node pools materialize, workloads load quickly, and events start streaming in. Logs become accessible. It resembles a visual extension of kubectl but is deeply integrated with Azure’s architecture.

The Difference Between AKS Desktop and Headlamp

This is the common question: “If I already use Headlamp, is AKS Desktop still necessary?” The answer is both straightforward and nuanced. Headlamp is entirely vendor-neutral, representing the Kubernetes environment exactly as the API describes it. This is especially beneficial if you manage multiple clusters across different clouds or operate hybrid platforms, as it provides a consistent and predictable interface.

However, it fails to recognize Azure’s specific features. Headlamp does not detect node pool upgrade options, workload identity bindings, or VNet profiles. It also cannot display Azure Policy statuses or properties of the AKS-managed control plane. Instead, it interprets everything solely as Kubernetes.

One day, when troubleshooting a failed deployment, Headlamp will display the deployment events and pods. AKS Desktop will show the same information and also indicate the health of the node pool, whether the cluster is in the middle of an upgrade, whether Azure Policy is blocking resources, or whether workload identity issues are preventing token retrieval.

Both tools are valuable: one is a Kubernetes viewer, and the other serves as an Azure-integrated control panel. Together, they provide a comprehensive view.

The Azure Reality Layer: what AKS Desktop Adds

When you explore your first cluster in AKS Desktop, you’ll immediately notice the distinct Azure-native layers. Node pools are not merely displayed as groups of nodes but as actual VMSS-backed pools, with details like size, type, version, and health clearly visible.

Networking now shows Services, Ingress, VNet integration, and the network profile of the cluster. Workload identity is prioritized as a first-class feature. Azure Policies provide enforcement and compliance updates. Upgrade options are now positioned beside the cluster identity rather than being tucked away in a separate portal page.

This is the real strength of AKS Desktop. It goes beyond simply querying the Kubernetes API by seamlessly merging ARM realities with cluster realities. It removes the need for operators to mentally assemble the environment from portal blades and CLI outputs. Instead, it presents the Azure architecture directly beside the Kubernetes context. Only when you see this fragmentation cleared up do you recognize how unsettling it was.

The Kubernetes Surface: Still Clear and Familiar

Even with the Azure integration, AKS Desktop maintains clear visibility into Kubernetes workloads. It displays pods, logs, and events in real time without requiring complex terminal commands. ConfigMaps and Secrets are shown clearly, while Deployments, StatefulSets, Jobs, CronJobs, and DaemonSets are easily accessible.

Troubleshooting is simplified: a quick visual scan of a pod in CrashLoopBackOff immediately shows its logs; a failing service becomes easy to triage; and a stuck rollout instantly reveals related ReplicaSet and pod events. While similar results can be achieved with kubectl, logs, and describe commands, AKS Desktop consolidates everything into user-friendly views that eliminate the need for mental juggling. It restores operator downtime, something Kubernetes seldom offers.

# A look at the architecture
              ┌──────────────────────────────────────────────┐
              │                AKS Desktop App               │
              │   (Local operator UI for Azure Kubernetes)   │
              └──────────────────────────────────────────────┘
                                │
                                │ Azure CLI Credentials
                                ▼
      ┌──────────────────────────────────────────────────────────────┐
      │                     kubeconfig Contexts                      │
      │   (Generated & managed based on your selected AKS cluster)   │
      └──────────────────────────────────────────────────────────────┘
                                │
                                │ Direct Kubernetes API Requests
                                ▼
      ┌──────────────────────────────────────────────────────────────┐
      │                       AKS Control Plane                      │
      │     ARM + AKS Managed Identity + Network + NodePools         │
      └──────────────────────────────────────────────────────────────┘
                                │
                                │ ARM & Azure-native metadata
                                ▼
      ┌──────────────────────────────────────────────────────────────┐
      │                    Azure Resource Manager                    │
      │    Node Pools, Network Profile, Workload Identity, Policy    │
      └──────────────────────────────────────────────────────────────┘

Daily Workflow with AKS Desktop: A Natural Operator Flow

Kubernetes operations follow a consistent rhythm: authenticate, select the correct context, inspect the cluster topology, check workloads, validate logs, scan events, triage node issues, monitor rollouts, troubleshoot identity bindings, track autoscaler behavior, and respond to network concerns. Typically, these tasks are performed across various tools. AKS Desktop streamlines the rhythm into a more seamless flow.

az login
az account set --subscription <id>

Select your cluster.

Watch the topology appear as if the cluster is sitting inside your workstation.

After a few minutes, you may switch to a different cluster, changing contexts without the kubectl equivalent of stack traces in your terminal. Everything stays local and quick. Logs show up instantly. Events stream in real time. Node pools show their health status clearly, like a debugging console.

For teams managing multiple AKS clusters, this is a significant relief. It now feels like AKS is a local development environment rather than just a remote system behind the Azure portal’s interface.

Validating Cluster Connectivity: The Familiar CLI Layer

Although AKS Desktop handles kubeconfig for you, the CLI remains a constant companion. For operators who want to double-check cluster accessibility:

kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods --all-namespaces

These commands should immediately reflect what you see in the application. If anything diverges, the troubleshooting flow becomes much more intuitive because the UI helps surface what the CLI hides in noise.

If you want to create kubeconfig manually:

az aks get-credentials \
  --resource-group rg-mycluster \
  --name aks-mycluster \
  --overwrite-existing

The thinking becomes: use the CLI for intent, AKS Desktop for navigation, and kubectl for precision. The three together create a near-perfect operator workflow.

The Workload Reality: A Sample Deployment for Demonstration

To familiarize yourself with the interface, deploy a small workload and observe its appearance. This NGINX example is a classic and functions well in AKS Desktop.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aksdesktop-sample
  labels:
    app: aksdesktop-sample
spec:
  replicas: 2
  selector:
    matchLabels:
      app: aksdesktop-sample
  template:
    metadata:
      labels:
        app: aksdesktop-sample
    spec:
      containers:
      - name: sample
        image: nginx:stable
        ports:
        - containerPort: 80

The moment it rolls out, AKS Desktop shows the pod startup sequence, container states, events, logs, and the overall deployment health.

Rollouts go from abstract kubectl lines to smooth, observable transitions.

Workload Identity, Troubleshooting, and the Azure Connection

AKS Desktop greatly improves the operator experience, especially with workload identity. If you’ve ever debugged a misconfigured AzureIdentityBinding or seen pods fail because they couldn’t get tokens from the federated identity endpoint, you know how confusing the documentation can be compared to real-world issues.

kubectl gives you the raw truth:

kubectl get azureidentity -A
kubectl get azureidentitybinding -A
kubectl get serviceaccount -n myapp

However, the application visually connects these components. It shows if the service account is mapped, if the identity exists, and whether the cluster is enforcing the correct node identity assignment. If any issues arise, the errors are visible in context rather than hidden in the describe output.

Networking and Node Pools: Visualizing the Azure Infrastructure

Networking in AKS is notoriously confusing to newcomers because much of it lives in ARM rather than Kubernetes. AKS Desktop shows the Kubernetes network constructs and then directly ties them back to Azure’s network profile.

Node pools appear not just as node groups but as actual VMSS-backed pools with their upgrade state and version alignment. When an upgrade is available, you see it clearly. When something is drifting from expected version levels, the tool shows it without requiring portal navigation.

This is the first time Azure-specific context appears alongside Kubernetes information.

# AKS vs Headlamp 
┌─────────────────────────┐                      ┌─────────────────────────┐
│        AKS Desktop      │                      │        Headlamp         │
│ Azure-aware operator UI │                      │  Kubernetes-native UI   │
└─────────────────────────┘                      └─────────────────────────┘
           │                                                   │
           │ Azure ARM + kube-API                              │ kube-API only
           ▼                                                   ▼
┌───────────────────────────┐                    ┌──────────────────────────┐
│ Nodepools, VMSS, VNet,    │                    │ Deployments, Nodes, Logs │
│ Workload Identity, Update │                    │ ConfigMaps, Secrets      │
│ Status, Azure Policies    │                    └──────────────────────────┘
└───────────────────────────┘

The diagram captures the difference precisely. Headlamp sees Kubernetes. AKS Desktop sees Azure Kubernetes Service.

The Public Preview Reality

It is important to acknowledge that AKS Desktop is currently in Public Preview, and preview experiences always carry a sense of incompleteness. Some views might feel early. Some features will evolve. Some integrations will deepen. Microsoft’s cadence for AKS improvements is fast, so the application will likely transform over the coming months.

But this is also the best moment for operators to adopt it. Early tools shape workflows, influence product direction, and reveal gaps that matter to people who run production clusters.

Suppose you look at where the industry is heading. In that case, local-first operational tools, cloud-aware dashboards, and multi-cluster management workflows make AKS Desktop clearly part of Azure’s next-generation Kubernetes operator experience.

AKS Desktop does not have a plugin system yet, but certain tools pair perfectly with it.

kubelogin is essential because AKS Desktop relies on Azure CLI identity flows. Installing it is simple:

az aks install-cli

For Kubernetes practitioners who love CLI flexibility, krew adds the right amount of power:

kubectl krew install ctx
kubectl krew install ns
kubectl krew install sniff
kubectl krew install graph
kubectl krew install view-allocations
kubectl krew install neat
kubectl krew install modify-secret

These plugins complement AKS Desktop rather than replace it.

K9s remains invaluable for low-latency terminal triage.

VS Code’s Kubernetes plugins remain excellent for YAML work.

The trio of AKS Desktop, kubectl/k9s, and VS Code forms the most complete operator workflow currently available for AKS.

# Day-to-Day Operations Flow

┌────────────────────────┐
│ az login & select sub  │
└────────────────────────┘
            │
            ▼
┌────────────────────────┐
│ Open AKS Desktop       │
│ auto-detects clusters  │
└────────────────────────┘
            │
            ▼
┌────────────────────────┐
│ Select AKS cluster     │
│ auto-generates context │
└────────────────────────┘
            │
            ▼
┌───────────────────────────────────┐
│ Logs • Events • Upgrades          │
│ Nodepools • Networking            │
│ Workload Identity • Policy        │
│ Everything visible in one place   │
└───────────────────────────────────┘

Closing Reflections: Why This Matters

For years, the Kubernetes ecosystem has focused on cluster tools such as CRDs, operators, dashboards, and automation. However, the operator’s daily experience often goes unnoticed, as managing AKS involves integrating Azure resource graphs, node pools, network configs, workload identities, policies, and cluster health across multiple clusters, regions, and subscriptions.

AKS Desktop is Microsoft’s first effort to offer a high-quality operator experience on the workstation, creating an environment where Azure and Kubernetes realities coexist seamlessly. It doesn’t replace kubectl, the portal, or Headlamp, but ties them into a cohesive story, offering platform teams an anchor, consistency, speed, and a new mental model of AKS that’s more like a single-operator cockpit than a scattered set of tools.

It respects fundamentals: no agents, CRDs, cluster installs, or new APIs, just your machine, Azure identity, kubeconfig, and a well-designed UI understanding AKS. Over time, AKS Desktop may become a standard tool for operators. Even as a public preview, it already improves the daily experience by reducing friction, enhancing clarity, and making Azure Kubernetes feel more connected, understandable, and personal.