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

Differences between runC and runV

Item runC runV
Container engine Docker and Containerd Containerd
Node type Elastic Compute Service (ECS) instances and ECS Bare Metal instances EBM
Container kernel Share the host kernel Dedicated kernel
Container isolation Cgroups and namespaces Lightweight virtual machines (VMs)
Rootfs Graph Driver OverlayFS DeviceMapper
RootFS I/O throttling Cgroups DeviceMapper Block IO Limit
Note Supported by only Sandboxed-Container V1.
NAS mounting Not supported Supported
Disk mounting Not supported Supported
Container log collection Logtail directly collects container logs from the host. Logtail sidecar. For more information, see Use CRDs to collect Kubernetes container logs in the Sidecar mode.
Pod Overhead None
  • Sandboxed-Container V1:

    For example, if you set memory: 512 Mi for a pod overhead, it indicates that 512 MiB of memory is allocated to the pod sandbox. In this case, if you set a memory limit of 512 MiB for containers in the pod, the pod will request a total memory of 1,024 MiB.

  • Sandboxed-Container V2:

    The memory limit for a pod overhead is calculated based on the formula: Memory for a pod overhead = 64 MiB + requested memory of containers in a pod × 2%. If the result is more than 512 MiB, the value is set to 512 Mi. If the result is less than 64 MiB, the value is set to 64 Mi.

Differences in pod creation between runC and runV

You can connect to clusters of Alibaba Cloud Container Service for Kubernetes (ACK) by using the kubectl command-line tool. For more information, see Use kubectl to connect to a cluster.

  • Create a pod that uses runC
    1. Use runtimeClassName: runc to set the container runtime to runC.
      Note The preceding command 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. 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 your Kubernetes version is earlier than 1.16, add the following nodeSelector configuration.
      nodeSelector:
          alibabacloud.com/container-runtime: Sandboxed-Container.runv
    4. Run the following command to query the created pod. If the output is runv, it indicates that the pod is running 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 specifications.
      kubectl exec -ti pod busybox-runv /bin/sh
      / # cat /proc/meminfo | head -n1
      MemTotal:        1130692 kB
      / # cat /proc/cpuinfo | grep processor
      processor    : 0

      The 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 uses some memory as well.