All Products
Search

This Product

    Container Service for Kubernetes:Comparison of Docker, containerd, and sandboxed container runtimes

    Document Center

    Container Service for Kubernetes:Comparison of Docker, containerd, and sandboxed container runtimes

    Last Updated:Mar 26, 2026

    Container Service for Kubernetes (ACK) supports three container runtimes: containerd, Sandboxed-Container, and Docker. This topic compares their supported cluster types, feature limitations, deployment architectures, and CLI commands to help you choose the right runtime for your workloads.

    Important

    Docker runtime is discontinued. If your cluster runs Docker, migrate to containerd. For instructions, see Migrate from Docker to containerd.

    How container runtimes fit into a Kubernetes node

    A container runtime manages the execution and lifecycle of containers on each node. kubelet communicates with the runtime through the Container Runtime Interface (CRI) to start, stop, and monitor containers. Your choice of runtime determines the isolation model, supported node types, and which CLI tools you use to manage containers.

    ACK supports the following runtimes:

    • containerd — The recommended runtime for most workloads. Lightweight and directly CRI-compliant, with no intermediate daemon layer.

    • Sandboxed-Container — Uses lightweight VMs (runV) to run each pod in an isolated kernel.

    • Docker (discontinued) — Deprecated and no longer receiving maintenance. Migrate to containerd.

    Comparison in terms of implementations and limits

    Feature

    containerd

    Sandboxed-Container

    Docker (discontinued maintenance)

    Cluster types

    • ACK managed clusters

    • ACK dedicated clusters

    • ACK Edge clusters

    • ACK managed clusters

    • ACK dedicated clusters

    All types of ACK clusters

    Kubernetes version

    Version 1.20 or later

    Kubernetes 1.16 or later

    Kubernetes 1.22 and earlier

    Node type

    • ECS

    • Self-managed nodes (ACK Edge clusters)

    Only ECS Bare Metal Instance families are supported

    ECS

    Node operating system

    Container Service for Kubernetes provides public images for operating systems such as Alibaba Cloud Linux 3 container-optimized version, ContainerOS, Alibaba Cloud Linux 3, Ubuntu, and Windows. For more information, see Operating systems.

    • Alibaba Cloud Linux

    • CentOS

    Container engine

    containerd

    containerd

    Docker

    Monitoring

    Supported

    Supported

    Supported

    Container log collection

    Supported

    Manual injection (sidecar). See Use CRDs to collect container text logs in sidecar mode.

    Supported

    Container stdout collection

    Supported

    Supported

    Supported

    RuntimeClass

    Not supported

    Supported (runV)

    Not supported

    Pod scheduling

    No configuration required.

    You must add configurations based on the following rules:

    • For Kubernetes 1.14.x, add the following configuration to the nodeSelector parameter:

      alibabacloud.com/sandboxed-container: Sandboxed-Container.runv

    • For Kubernetes 1.16.x and later, no configuration is required.

    No configuration required.

    HostNetwork

    Supported

    Not supported

    Supported

    Node data disk

    Optional

    Required. The data disk must be at least 200 GiB.

    Optional

    Network plug-in

    • Flannel

    • Terway (excluding ACK Edge clusters)

    • Flannel

    • When using Terway, the exclusive Elastic Network Interface (ENI) mode and DataPath v2 feature are not supported.

    • Flannel

    • Terway

    kube-proxy mode

    • iptables

    • IPVS

    • iptables

    • IPVS

    • iptables

    • IPVS

    Volume plug-in

    CSI plug-in (excluding ACK Edge clusters)

    CSI plug-in

    CSI plug-in

    Container root file system

    OverlayFS

    OverlayFS with disk quota configuration

    OverlayFS
    Note

    You cannot deploy Docker and Sandboxed-Container on the same node. To run both runtime types in a cluster, create separate node pools — one for Docker runtime nodes and one for Sandboxed-Container runtime nodes.

    Note

    Sandboxed-Container is implemented on top of containerd. When you inspect Sandboxed-Container nodes with kubectl get node or view the node list in the ACK console, the runtime is displayed as containerd.

    Comparison in terms of deployment architectures

    The deployment architecture shows the component call chain from kubelet down to the containers. Fewer layers mean lower overhead and less operational complexity.

    Runtime

    Deployment architecture

    Docker

    		 
    kubelet
└── dockerd
    └── containerd
        └── containerd-shim
            └── runC containers

    containerd

    		 
    kubelet
└── containerd
    └── containerd-shim
        └── runC containers

    Sandboxed-Container v2

    		 
    kubelet
├── (CRI) containerd
│   ├── containerd-shim
│   │   └── runC containers
│   └── containerd-shim-runv2
│       └── runV sandboxed containers

    containerd removes the dockerd layer that Docker requires, giving kubelet direct CRI access to the runtime. Sandboxed-Container v2 extends containerd with an additional shim (containerd-shim-runv2) that runs pods inside lightweight VMs using runV, enabling kernel-level isolation alongside standard runC containers on the same node.

    CLI commands for containerd and Docker

    containerd and Docker use different CLI tools to manage images and containers. crictl is the recommended tool for containerd because it operates at the CRI level and is consistent across Kubernetes environments. ctr is containerd's lower-level CLI and is available as an alternative.

    Operation

    crictl (recommended for containerd)

    ctr (containerd lower-level CLI)

    docker

    Query containers

    crictl ps

    ctr -n k8s.io c ls

    docker ps

    Query container details

    crictl inspect <container>

    ctr -n k8s.io c info <container>

    docker inspect <container>

    Query container logs

    crictl logs <container>

    N/A

    docker logs <container>

    Run commands in containers

    crictl exec <container>

    N/A

    docker exec <container>

    Attach local stdin, stdout, and stderr to containers

    crictl attach <container>

    N/A

    docker attach <container>

    Query resource usage statistics

    crictl stats <container>

    N/A

    docker stats <container>

    Create containers

    crictl create <container>

    ctr -n k8s.io c create <container>

    docker create <container>

    Start containers

    crictl start <container>

    ctr -n k8s.io run <container>

    docker start <container>

    Stop containers

    crictl stop <container>

    ctr -n k8s.io task pause <container>

    docker stop <container>

    Delete containers

    crictl rm <container>

    ctr -n k8s.io c del <container>

    docker rm <container>

    Query images

    crictl images

    ctr -n k8s.io i ls <image>

    docker images

    Query image details

    crictl inspecti <image>

    N/A

    docker inspect <image>

    Pull images

    crictl pull <image>

    ctr -n k8s.io i pull <image>

    docker pull <image>

    Push images

    N/A

    ctr -n k8s.io i push <image>

    docker push <image>

    Delete images

    crictl rmi <image>

    ctr -n k8s.io i rm <image>

    docker rmi <image>

    Query pods

    crictl pods

    N/A

    N/A

    Query pod details

    crictl inspectp <pod name>

    N/A

    N/A

    Start pods

    crictl runp <pod name>

    N/A

    N/A

    Stop pods

    crictl stopp <pod name>

    N/A

    N/A

    What's next

    References