Azure Linux explained: what it is, why it exists, and where it runs

Microsoft ships its own Linux distribution, and the first time you notice it is usually a one-line flag on an AKS node pool. Here is what that flag actually gives you, where the distribution came from, and how to decide whether to run it under your clusters.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure Linux (formerly CBL-Mariner) is Microsoft's own lightweight, container-optimized Linux distribution, built and maintained by Microsoft primarily as a host OS for AKS (Azure Kubernetes Service) nodes and other cloud-native and edge workloads. It aims for a small footprint, a reduced attack surface, and consistent, Microsoft-supported patching. If you have only ever run Ubuntu under your clusters, that sentence probably raises more questions than it answers — so let me walk through them one at a time.

What Azure Linux is (and the CBL-Mariner lineage)

Azure Linux is a full Linux distribution, in the same category as Ubuntu, Debian, or Fedora, in that it has a kernel, a package manager, an init system, and the usual userland tools. What sets it apart is who builds it and what it is trimmed down for. Microsoft's Linux Systems Group develops it in the open, the source lives on GitHub, and it uses RPM packages rather than the .deb format you would find on an Ubuntu box. If you have used a Red Hat or Fedora system before, the package tooling will feel familiar.

The name is the part that trips people up. The distribution first shipped under the name CBL-Mariner — CBL stands for Common Base Linux — and you will still find plenty of GitHub issues, blog posts, and internal docs that call it Mariner. Microsoft later renamed the project to Azure Linux. It is the same distribution, same repository, same lineage; only the branding changed. So when a Microsoft doc talks about "Mariner" and an az command asks for AzureLinux, they are pointing at the same thing.

The distribution has moved through major versions over time, and the version you get by default depends on the Kubernetes version of your cluster rather than on anything you type. That is worth internalizing early: on AKS you rarely pin a distribution version by hand — you follow the Kubernetes version and let AKS map it to a supported Azure Linux image.

Why Microsoft built its own distro

The obvious question is why a company that already partners closely with Canonical and Red Hat would go and maintain a Linux distribution of its own. The answer is not really about competing with Ubuntu; it is about control over a very specific job — being the host underneath a container.

A general-purpose distribution is built to do everything: run a desktop, host a database, serve as a build machine, act as a jump box. That generality means it ships a lot of packages you will never use on a Kubernetes node. Azure Linux takes the opposite stance and includes roughly the set of packages needed to run containers and the kubelet, and not much else. Three things fall out of that decision:

• A small footprint. Fewer packages means a smaller image, which means faster node provisioning and less to download when a pool scales out.
• A reduced attack surface. Every package you do not install is a package that cannot carry a vulnerability. A host that ships without a general-purpose toolchain and without services you never enabled simply has fewer doors to lock.
• Supply-chain and patching control. Because Microsoft builds the packages from source in its own pipeline, it can patch a CVE and push a fixed node image on its own schedule, and it supports the result end to end. For an organization that already lives inside a Microsoft support contract, having the node OS covered by that same relationship is the quiet, boring benefit that matters most in an audit.

None of this is exotic. It is the same logic behind minimal container base images and distroless builds, applied one layer down — to the machine the containers land on rather than the image inside them.

The point of a first-party node OS is not novelty. It is having one vendor own the packages, the patches, and the support line.

Where it runs: AKS nodes and edge

By far the most common place you will meet Azure Linux is as the operating system on your AKS worker nodes — the virtual machines that run your pods. That is its headline role, and it is the context almost every tutorial assumes. Your containers run on top of it through the container runtime, so from a pod's point of view the host OS is mostly invisible; a workload that ran on an Ubuntu node will, in the overwhelming majority of cases, run on an Azure Linux node without noticing the difference.

It shows up in a few other places too. Microsoft uses Azure Linux internally as a base OS for various Azure services, and it appears in edge and IoT scenarios where a small, well-supported host is exactly what you want on constrained or remote hardware. But for a cloud engineer, the practical answer to "where does this run?" is: on the nodes under my cluster. Everything else is context.

Choosing Azure Linux for your AKS node pool

Selecting the distribution is genuinely a one-liner. AKS calls the node operating system the OS SKU, and you set it with the --os-sku flag. To stand up a new cluster whose default node pool runs Azure Linux:

az aks create \
  --resource-group myResourceGroup \
  --name myCluster \
  --os-sku AzureLinux \
  --generate-ssh-keys

More often you will add an Azure Linux pool to a cluster you already have, which is the same flag on a different command:

az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myCluster \
  --name azpool \
  --os-sku AzureLinux

That is the whole mechanism. There is no separate image to publish, no custom cloud-init to babysit; you name the OS SKU and AKS provisions nodes on the matching Microsoft-maintained image. Because a cluster can hold several node pools, a low-risk way to try Azure Linux is to add a single pool of it beside your existing Ubuntu pool, move a non-critical workload onto it with a node selector, and watch how it behaves before you commit anything important.

Migrating from a general-purpose distro

Moving an existing cluster from Ubuntu to Azure Linux is less a "migration" in the heavy sense and more a rolling replacement of nodes. The usual pattern is to add an Azure Linux node pool, cordon and drain the old Ubuntu nodes so Kubernetes reschedules their pods onto the new pool, and then remove the old pool once everything has landed and looks healthy. Your workloads move because Kubernetes moves them, not because you rebuild anything by hand.

The reason it goes smoothly for most people is the same reason the node OS is usually invisible: your app already lives in a container with its own base image, so it carries its own libraries with it. The cases that need a second look are the ones that reach past the container and touch the host — and those are worth listing plainly:

• Anything that assumes a specific package manager. A DaemonSet or init script that shells out to apt will not find it on an RPM-based host. Tooling that installs packages on the node needs to speak the RPM world instead.
• Host-path and privileged agents. Security agents, log shippers, and monitoring tools that install onto the node, load kernel modules, or read host paths should be checked for Azure Linux support before you cut over. Most mature vendors support it; confirm rather than assume.
• Node customizations. Any bespoke daemon set, sysctl tweak, or file dropped on the host should be re-validated, because the filesystem layout and available packages are not identical to Ubuntu's.

Because you can run the two pools side by side, you never have to make this a big-bang change. Bring up an Azure Linux pool, shift one workload, verify your monitoring and security agents report in correctly, and only then widen the move. A separate but related point: keep an eye on version support timelines. Microsoft retires older node images on a published schedule, and staying on a supported Kubernetes version is what keeps you on a supported Azure Linux image underneath it — this is ordinary AKS upkeep, not something unique to switching distributions.

Azure Linux vs Ubuntu on AKS: how to decide

Ubuntu has been the default AKS node OS for years, and it is a completely reasonable choice — huge community, enormous body of documentation, and the muscle memory that most Linux engineers already have. So the honest framing is not "which is better" but "what do you gain by switching, and what does it cost you?"

You lean toward Azure Linux when the small footprint and reduced attack surface line up with a compliance or hardening goal, or when you want the node OS covered by the same Microsoft support relationship as the rest of your Azure estate. You stay on Ubuntu when your team's tooling, runbooks, and third-party agents are all built and tested against it, and the friction of re-validating that ecosystem outweighs the security-surface gain. Neither answer is wrong; they are optimizing for different things.

A practical middle path exists precisely because AKS supports multiple node pools per cluster. You do not have to standardize the whole estate on day one. Run a small Azure Linux pool, learn how your agents and workloads behave on it, and let the evidence — not a blog post, including this one — decide how far you take it.

Questions people also ask

What is Azure Linux?

Azure Linux is Microsoft's own lightweight, container-optimized Linux distribution, built and maintained by Microsoft's Linux Systems Group. It ships only the packages needed to run containers and Kubernetes, which keeps the image small and the attack surface narrow. Its primary job is to serve as a host operating system for AKS nodes, though Microsoft also uses it inside other Azure services and edge scenarios.

Is Azure Linux the same as CBL-Mariner?

Yes. Azure Linux is the current name for the distribution that Microsoft originally shipped as CBL-Mariner, short for Common Base Linux Mariner. The project was renamed to Azure Linux, so when you read older docs or GitHub issues that say CBL-Mariner, they are describing the same distribution you now select as AzureLinux on AKS.

Can I use Azure Linux for AKS nodes?

Yes. Azure Linux is a supported node operating system for Azure Kubernetes Service. You choose it by setting the OS SKU when you create a cluster or add a node pool, using the flag --os-sku AzureLinux on az aks create or az aks nodepool add. Your workloads run in containers on top of it, so in most cases the pods do not care which node OS you picked.

Is Azure Linux free?

Yes. Azure Linux is free and open source, with its source code published on GitHub under permissive licenses. When you run it as your AKS node OS there is no separate charge for the operating system itself; you pay for the underlying virtual machines, storage, and other Azure resources exactly as you would with any other AKS node image.