8.5 Managing Container Instances & Linux Containers with WSL
Key Takeaways
- Data written to a container's writable layer is destroyed on removal, so persistent state requires a volume or bind mount rather than the container filesystem.
- Production instances should be constrained with --cpus, --memory, and --restart unless-stopped, and can be forced into Hyper-V isolation per instance with --isolation hyperv.
- Kubernetes nodes run containerd, not the Docker Engine, so container instances on an AKS Hybrid worker node must be inspected with crictl or ctr rather than docker ps.
- A Windows Server host cannot natively execute Linux container images; WSL 2 supplies a real Linux kernel in a lightweight utility VM, and the deprecated LCOW feature is no longer the supported path.
- WSL 2 requires the Virtual Machine Platform optional component and hardware virtualization, so a virtualized Windows Server host must have nested virtualization exposed before WSL 2 will start.
Managing Container Instances & Linux Containers with WSL
Building an image is only the first half of the container skill measured on AZ-800. The rest is operational. This section covers the day-to-day half: starting, inspecting, constraining, and removing running instances, and running Linux containers on a Windows Server host. Attaching those instances to the right network and handing orchestration to Kubernetes are covered in section 8.6.
1. Managing Container Instances
A container image is an immutable template; a container instance is a running (or stopped) execution of that template. On a Windows Server container host you drive instances either through the Docker CLI or, on a containerd-only host, through ctr and crictl.
Instance Lifecycle With the Docker CLI
# Run detached, name the instance, publish host port 8080 to container port 80
docker run -d --name web01 -p 8080:80 --isolation=process `
mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022
# List running instances; -a also shows stopped ones
docker ps
docker ps -a
# Lifecycle verbs
docker stop web01 # graceful shutdown, then SIGKILL after the grace period
docker start web01
docker restart web01
docker rm web01 # must be stopped first, or use -f to force
# Inspect a running instance
docker logs web01 --tail 50 --follow
docker stats web01 # live CPU, memory, network and I/O counters
docker inspect web01 # full JSON configuration, including network settings
docker exec -it web01 powershell.exe # interactive shell inside the instance
[!IMPORTANT] Anything written inside a container's writable layer is destroyed when the instance is removed. Data that must survive
docker rmhas to live on a volume or a bind mount:docker run -v C:\HostData:C:\AppData ....
Constraining Instance Resources
Container instances share the host kernel and, by default, compete freely for host resources. Production hosts should always constrain them:
| Flag | Effect |
|---|---|
--cpus 2 | Limits the instance to two logical processors' worth of CPU |
--cpu-shares 512 | Relative CPU weight under contention (default is 1024) |
--memory 2g | Hard memory ceiling; the instance is terminated if it exceeds it |
--restart unless-stopped | Restarts the instance automatically after a host reboot or a crash |
--isolation hyperv | Runs this instance in Hyper-V isolation regardless of the host default |
docker run -d --name api01 --cpus 2 --memory 4g --restart unless-stopped `
--isolation hyperv contoso/orders-api:2.4
Managing Instances Under containerd
Modern Windows Server container hosts and every Kubernetes node run containerd rather than the Docker Engine. The equivalent tooling is ctr for raw containerd operations and crictl for Kubernetes CRI-level operations:
ctr --namespace default containers list
ctr --namespace default tasks list
crictl ps # running containers known to the CRI
crictl pods # pod sandboxes on this node
crictl logs <container-id>
crictl stats
[!TIP]
docker pswill not show containers created by Kubernetes on a containerd node. When troubleshooting an AKS Hybrid worker node, reach forcrictl, notdocker.
2. Running Linux Containers on Windows Server With WSL
Windows Server containers share the host kernel, which means a Windows Server host cannot natively execute a Linux container image — a Linux container needs a Linux kernel. The supported way to provide one on Windows Server is the Windows Subsystem for Linux (WSL 2), which runs a genuine Linux kernel inside a lightweight, Microsoft-managed utility virtual machine.
[!NOTE] The older "Linux Containers on Windows" (LCOW) preview feature has been deprecated. WSL 2 is the current path for Linux container workloads on a Windows Server host.
Enabling WSL 2 on Windows Server
WSL 2 depends on the Virtual Machine Platform optional component, because the utility VM is a Hyper-V construct.
# Enable the two required optional components
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Restart-Computer
# Install WSL and a default distribution, then confirm the version in use
wsl --install
wsl --list --online
wsl --install -d Ubuntu
wsl --set-default-version 2
wsl --list --verbose
Key constraints the exam expects you to recognise:
- WSL 2 requires hardware virtualization. If the Windows Server itself is a virtual machine, nested virtualization must be enabled on that VM with
Set-VMProcessor -VMName <name> -ExposeVirtualizationExtensions $truebefore WSL 2 will start. - WSL 1 will not do. WSL 1 translates Linux syscalls rather than running a Linux kernel, so it cannot host Linux containers. Confirm
VERSION 2inwsl --list --verbose. - Windows containers and Linux containers on the same host run in separate runtimes; a single Docker daemon on Windows Server does not run both simultaneously in mixed mode.
A support engineer connects to an AKS Hybrid Windows Server worker node to inspect a failing pod's container. Running docker ps returns an empty list even though the workload is running. What explains this?
A containerized web application must survive both a host reboot and an application crash without manual intervention, and must never consume more than 4 GB of host memory. Which docker run options satisfy both requirements?
An administrator must run a Linux container image on a Windows Server 2025 host that is itself running as a Hyper-V virtual machine. What combination is required?