Differences between runC and runV

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.


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

Use runtimeClassName: runc to set the container runtime to runC.

Note The preceding command is optional. runC is the default container runtime.

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.