Containers and images have become the industry standards for software packaging and delivery. Kubernetes has become a standard platform for building, developing, and managing containerized cloud-native applications. An increasing number of enterprises and customers choose to deploy their applications in Alibaba Cloud Container Service for Kubernetes (ACK). ACK supports two types of runtimes: Docker and Sandboxed-Container. This topic describes the differences between these runtimes in the following aspects: implementations and limits, commonly used commands provided by Docker Engine and Containerd, and deployment architectures. This provides references for you to select between Docker and Sandboxed-Container based on your requirements.

Differences between Docker and Sandboxed-Container in terms of implementations and limits

Item Docker Sandboxed-Container Description
Cluster type All types ACK Standard clusters and clusters of Standard ACK Proprietary Edition. None
Node type
  • Elastic Compute Service (ECS) instances
  • ECS Bare Metal instances
 ECS Bare Metal instances None
Node operating system
  • CentOS
  • Aliyun Linux 2
  • Windows
 Aliyun Linux 2 Customized Edition
  • You cannot deploy both Docker and Sandboxed-Container on a node.
  • To deploy both Docker and Sandboxed-Container in a cluster, you can create node pools of different runtime types.
Container engine Docker Containerd None
Monitoring Supported Supported None
Container log collection Supported Sidecar: supported. Manual configuration is required. For more information about sidecar configurations, see Use CRDs to collect Kubernetes container logs in the Sidecar mode.
Container stdout collection Supported Supported None
RuntimeClass Not supported Supported (runV) None
Pod scheduling No configuration is required.
  • For Kubernetes V1.14.x, you must add the following configuration to the nodeSelector field.
    alibabacloud.com/sandboxed-container: Sandboxed-Container.runv
  • For Kubernetes V1.16.x and later, no configuration is required.
 None
HostNetwork Supported Not supported None
exec/logs Supported Supported None
Node data disk Optional Required. The data disk must be at least 200 GiB. None
Network plug-in
  • Flannel
  • Terway
  • Flannel
  • Terway: supports only the One ENI for Multi-Pod mode.
 None
Kube-proxy mode
  • Iptables
  • IPVS
  • Iptables
  • IPVS
 None
Volume plug-in CSI Plugin CSI Plugin None
Container root file system OverlayFS DeviceMapper None

Differences in 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. These tools support different commands that can be used to manage images and containers. The following table lists the commonly used commands.

Command Docker Containerd
docker crictl (recommended) ctr
Query containers docker ps crictl ps ctr -n k8s.io c ls
Query container information docker inspect crictl inspect ctr -n k8s.io c info
Query container logs docker logs crictl logs None
Run a command in a container docker exec crictl exec None
Attach local standard input, output, and error streams to a running container docker attach crictl attach None
Query resource usage statistics docker stats crictl stats None
Create one or more containers docker create crictl create ctr -n k8s.io c create
Start one or more containers docker start crictl start ctr -n k8s.io run
Stop one or more containers docker stop crictl stop None
Remove one or more containers docker rm crictl rm ctr -n k8s.io c del
Query images docker images crictl images ctr -n k8s.io i ls
Query image information docker inspect crictl inspecti None
Pull an image docker pull crictl pull ctr -n k8s.io i pull
Push an image docker push None ctr -n k8s.io i push
Remove one or more images docker rmi crictl rmi ctr -n k8s.io i rm
Query pods None crictl pods None
Query pod information None crictl inspectp None
Start one or more pods None crictl runp None
Stop one or more pods None crictl stopp None

Differences between Docker and Sandboxed-Container in terms of deployment architectures

Runtime Deployment architecture
Docker 
kubelet -> dockerd -> containerd -> containerd-shim -> runC containers
Sandboxed-Container V1 
kubelet -> (CRI)containerd
                          \-> containerd-shim -> runC containers
                          \-> containerd-shim-kata-v2 -> runV sandboxed containers
Sandboxed-Container V2 
kubelet -> (CRI)containerd
                          \-> containerd-shim -> runC containers
                          \-> containerd-shim-rund-v2 -> runV sandboxed containers