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 helps you better understand and utilize the advantages of sandboxed containers.


Item	runC	runV
Container engine	Docker and Containerd	Containerd
Node type	ECS and EBM	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 I/O limit
NAS mounting	Not supported	Supported
Disk mounting	Not supported	Supported
Container log file 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	Memory: 512MiB Pod overhead refers to the amount of resources consumed by the pod sandbox. For example, if you set a memory limit of 512 MiB for a pod, the pod will request a total memory of 1,024 MiB.

Differences in pod creation between runC and runV

You can use the kubectl command-line tool to connect to Kubernetes clusters. For more information, see Connect to Kubernetes clusters through kubectl.

Create a pod using 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 commands to create a pod using 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 using 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 already exists in the cluster.
```
kubectl get runtimeclass runv -o yaml
```
  Note In Kubernetes clusters based on Sandboxed-Container, a RuntimeClass object named runv is created by default.
3. Run the following commands to create a pod using 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, you need to 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
```
  As shown in the preceding output, 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.