All Products
Search

This Product

    Container Service for Kubernetes:Comparison among Docker, containerd, and Sandboxed-Container

    Document Center

    Container Service for Kubernetes:Comparison among Docker, containerd, and Sandboxed-Container

    Last Updated:Dec 20, 2024

    Container Service for Kubernetes (ACK) supports the following container runtimes: containerd, Sandboxed-Container, and Docker. This topic compares these runtimes in terms of implementations, limits, and deployment architectures, to help you select a container runtime based on your business requirements and scenarios.

    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 of ACK clusters

    Kubernetes version

    Kubernetes 1.31 and earlier

    Kubernetes 1.31 and earlier

    Kubernetes 1.22 and earlier

    Note

    We recommend that you upgrade Docker to containerd for your clusters. For more information, see Change the container runtime from Docker to containerd.

    Node type

    • Elastic Compute Service (ECS) instance

    • Self-managed nodes (ACK Edge clusters)

    ECS Bare Metal instance

    ECS instance

    Node operating system

    ACK provides public images for operating systems, including:

    • ContainerOS

    • Alibaba Cloud Linux 3

    • Ubuntu

    • Windows

    For more information, see OS images.

    Alibaba Cloud Linux Customized Edition

    • Alibaba Cloud Linux

    • CentOS

    Container engine

    containerd

    containerd

    Docker

    Monitoring

    Supported

    Supported

    Supported

    Log collection

    Supported

    Manual configuration of sidecar containers is required to support log collection.

    Supported

    Stdout collection

    Supported

    Supported

    Supported

    RuntimeClass

    Not supported

    Supported (runV)

    Not supported

    Pod scheduling

    No configuration is required.

    You must configure pods based on the following rules:

    • For Kubernetes 1.14.x, you must 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 is required.

    HostNetwork

    Supported

    Not supported

    Supported

    Node data disk

    Optional

    Required (at least 200 GiB)

    Optional

    Network plug-in

    • Flannel

    • Terway (excluding ACK Edge clusters)

    • Flannel

    • terway-eniip: Only terway-eniip that does not run in IPVLAN or Assign One ENI to Each Pod mode is supported.

    • Flannel

    • Terway

    Kube-proxy mode

    • iptables

    • IPVS

    • iptables

    • IPVS

    • iptables

    • IPVS

    Volume plug-in

    CSI (excluding ACK Edge clusters)

    CSI

    CSI

    Container root file system

    OverlayFS

    OverlayFS with support for disk quotas

    OverlayFS

    Note

    • You cannot deploy both Docker and Sandboxed-Container on the same node.

    • To deploy both Docker and Sandboxed-Container in the same cluster, you can create node pools that use different types of container runtimes.

    • For more information about the sidecar configuration, see Use CRDs to collect container text logs in Sidecar mode.

    Comparison in terms of deployment architectures

    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

    Comparison of the commonly used commands provided by Docker Engine and containerd

    Docker uses Docker Engine for container lifecycle management. Sandboxed-Container uses containerd for container lifecycle management. Both runtimes provide their own unique CLI tools for managing images and containers. The following table describes the commonly used commands provided by Docker Engine and containerd.

    Operation

    containerd

    Docker

    crictl (recommended)

    ctr

    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>

    N/A

    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