Azure Container Linux (ACL)
Microsoft project
- Entry ?
- Azure Container Linux (ACL)
- Who owns the artifact ?
- Vendor image
- Bring your own distro ?
- No, ships its own base
- Day-0 paths ?
- Cloud image
- azure-marketplace-image
- Configuration tool ?
- Ignition (shipped as ignition-flatcar) (Apache-2.0) Earliest: initramfs; Latest: first boot; Repeat: once; Scope: files and units
- Update unit ?
- AKS node image: Whole node (reimaged or replaced); In-node A/B: /usr onlyNote: On AKS, ACL supports only full node image updates. The repository documents an in-node A/B /usr slot that Trident switches; no source says AKS uses it.Mechanism: Replace the instance, A/B partition switch.
- Mounts ?
- Read-only /usr (btrfs filesystem under dm-verity)
- Writable, reset on reboot Not found in the documentation we read. Know the answer?
- Writable, persistent /etc (overlay, upper layer persisted on the ROOT partition); the rest of the ROOT partition (the documents do not list which paths)
- Configurable Ignition can format and mount additional disks and set up mount points at first boot. The read-only /usr is fixed.
- Adding software to the OS ?
- systemd-sysextSysext images merge over the read-only /usr. The image carries a containerd sysext. Standalone sysexts for NVIDIA drivers and Docker are downloaded on demand.[24]
- Derive the imageRun the Azure Linux Image Customizer on an existing ACL image. The project's guide uses it to preload container images with a script that runs in a chroot on the image.[25]
- Update signature check ?
- PossibleOn by default, through Trusted Launch.[26] The kernel, initramfs and command line ship as one signed UKI, which Secure Boot checks at boot.[26]
- Boot trust chain ?
- Level 3: Running root coveredOn by default, through Trusted Launch.[26] Trust reaches the running root (level 3).[26,27] How the root is covered: dm-verity root hash inside a signed boot artifact (signed UKI and per-slot addon). Secure Boot and vTPM are required. The public build signs the UKI only with a test key, so the vendor documents level 3 but it cannot be reproduced from the public source.
- Automatic rollback ?
- Not found in the documentation we read. Know the answer?
- Fleet upgrade paths ?
- On its own: The OS has no update agent of its own. AKS acts when the node OS upgrade channel is NodeImage.
- Kubernetes ?
- Optional, not bundledDocumented ways to run Kubernetes: AKSNo row-level source. Sources for the Kubernetes relationship section
- Node access ?
- SSH and shell
- Cluster API ?
- None documentedNo row-level source. Sources for the Fleet management section
- AI accelerators ?
- Architectures ?
- amd64
- arm64
- Self-hostable update source ?
- Not found in the documentation we read. Know the answer?
- Who holds the assets ?
- Single vendorVendor: MicrosoftNo row-level source. Sources for the Governance section
- Support model ?
- Vendor lifecycleCommercial support: unknownNo row-level source. Sources for the Maturity section
- What names the OS version
- Named by AKS node image version and os-release VERSION. Condition: No optional system extensions beyond those baked into the image.Inclusion criterion 1: atomic updates (versioned OS).
- Maintainers
- Single vendor.
Sources for this section
Rows here, and guide text, marked "No row-level source" rest on these lists. Each list backs its dimension as a whole, not one row.
Customization [244,247,248,249]
Provisioning [250]
Kubernetes relationship [20,251,252,253,254]
Operations and debugging [255,256,257,258,247]