Advantages of Sandboxed Containers - Container Service for Kubernetes

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
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

Prerequisite

You have connected the cluster using kubectl.

Create a pod that uses runC

Optional: Use runtimeClassName: runc to set the container runtime to runC.
Note
The preceding configuration 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 the Sandboxed Container runV

Use runtimeClassName: runv to set the container runtime to runV.
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.

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

Important

If your Kubernetes version is earlier than 1.16, you must add the following nodeSelector configuration. Otherwise, no configuration is needed.

nodeSelector:
    alibabacloud.com/container-runtime: Sandboxed-Container.runv

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}
```
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.