This topic describes the differences between runC and Sandboxed-Container (runV) in terms of their performance and pod creation methods. This helps you better understand and utilize sandboxed containers.

Comparison between runC and runV

Component runC runV
Container engine Docker and containerd Containerd
Node type Elastic Compute Service (ECS) instances and ECS bare metal instances EBM
Container kernel Shares the host kernel Uses a dedicated kernel
Container isolation Control groups (cgroups) and namespaces Lightweight VMs
Rootfs Graph Driver OverlayFS OverlayFS
RootFS I/O throttling Cgroups Not supported
NAS mounting Not supported Supported
Disk mounting Not supported Not supported
Container log collection Logtail directly collects the container log from the node. Logtail sidecar. For more information, see Use CRDs to collect container text logs in Sidecar mode.
Pod Overhead N/A The memory of a pod overhead is calculated based on the following formula: Memory of a pod overhead = 64 MiB + Pod memory request × 2%. If the result is greater than 512 MiB, the value is set to 512 MiB. If the result is less than 64 MiB, the value is set to 64 MiB.

Differences in pod creation between runC and runV

You can connect to Container Service for Kubernetes (ACK) clusters by using the kubectl command-line tool. For more information, see Connect to ACK clusters by using kubectl.

  • Create a pod that uses runC
    1. Optional:Use runtimeClassName: runc to set the container runtime to runC.
      Note The preceding configuration is optional. runC is the default container runtime.
    2. Run the following command to create a pod that uses runC: 
      cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-runc
  labels:
    app: busybox-runc
spec:
  containers:
  - name: busybox
    image: registry.cn-hangzhou.aliyuncs.com/acs/busybox:v1.29.2
    command:
    - tail
    - -f
    - /dev/null 
    resources:
      limits:
        cpu: 1000m
        memory: 512Mi
      requests:
        cpu: 1000m
        memory: 512Mi
EOF
  • Create a pod that uses runV
    1. Use runtimeClassName: runv to set the container runtime to runV.
    2. Optional:Run the following command to verify that a RuntimeClass object named runv exists in the cluster: 
      kubectl get runtimeclass runv -o yaml
      Note A RuntimeClass object named runv is automatically created in a Kubernetes cluster that uses Sandboxed-Container.
    3. Run the following command to create a pod that uses runV: 
      cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-runv
  labels:
    app: busybox-runv
spec:
  runtimeClassName: runv
  nodeSelector:
    alibabacloud.com/container-runtime: Sandboxed-Container.runv
  containers:
  - name: busybox
    image: registry.cn-hangzhou.aliyuncs.com/acs/busybox:v1.29.2
    command:
    - tail
    - -f
    - /dev/null
    resources:
      limits:
        cpu: 1000m
        memory: 512Mi
      requests:
        cpu: 1000m
        memory: 512Mi
EOF
      Notice If the Kubernetes version is earlier than 1.16, you must add the following nodeSelector configuration. If the Kubernetes version is 1.16 or later, the following nodeSelector configuration is not required. 
      nodeSelector:
    alibabacloud.com/container-runtime: Sandboxed-Container.runv
    4. Run the following command to query the created pod: If runv is included in the output, it indicates that the pod runs in a sandbox. 
      kubectl get pod busybox-runv -o jsonpath={.spec.runtimeClassName}
    5. Run the following command to log on to the pod and query its CPU and memory configurations: 
      kubectl exec -ti pod busybox-runv /bin/sh
/ # cat /proc/meminfo | head -n1
MemTotal:        1130692 kB
/ # cat /proc/cpuinfo | grep processor
processor    : 0

      The preceding output shows that the number of CPUs is not the same as that of the host. The total memory is the sum of pod memory and pod overhead. Note that the total memory is slightly smaller because the system consumes some memory as well.