容器运行时kata的一些知识分享

kata运行时的地位

kata-runtime的地位等同于runc运行时，所以可以替换containerd使用的运行时，在k8s中通过调用containerd，containerd使用kata达到使用。

docker使用kata是声明默认的运行时，以达到containerd替换默认运行时为kata

kata的一些功能无法实现

使用kata会无法使用docker network的自动发现功能。

但是IP地址是可以通信的

kata最新版

kata在VMware 个人桌面的一些问题解决

错误：ERROR: System is not capable of running Kata Containers

解决方法：

VMware虚拟机设置，处理器–》虚拟化引擎

勾选虚拟化Intel VT-x/EPT

错误：ERRO[0000] kernel property not found arch=amd64 description=”Host Support
for Linux VM Sockets” name=vhost_vsock pid=16727 source=runtime type=module

System is capable of running Kata Containers

System can currently create Kata Containers

解决方法：

是linux 检测到在 vmware 环境中运行时，会加载一些 vmware 的模块并使用 vsock
从而产生了冲突

sudo tee /etc/modules-load.d/blacklist-vmware.conf << EOF

blacklist vmw_vsock_virtio_transport_common

blacklist vmw_vsock_vmci_transport

EOF

然后重启linux

kata命令

kata-runtime help

kata检查

kata-runtime kata-check

v2额外支持

kata-runtime check

版本

kata-runtime -v

环境变量

kata-runtime kata-env

v2额外支持

kata-runtime env

kata配置文件

查看配置文件存放位置，默认位置是/usr/share/defaults/kata-containers/configuration.toml标准系统的位置
。但是，如果/etc/kata-containers/configuration.toml存在，则优先

命令：kata-runtime –kata-show-default-config-paths

/etc/kata-containers/configuration.toml

/usr/share/defaults/kata-containers/configuration.toml ###centos7存放位置

/usr/share/kata-containers/defaults/configuration.toml ###centos8存放位置

kata存在基于alpine系统下运行java会提示library initialization failed - unable to
allocate file descriptor table - out of memory

在Linux的最新版本中，打开文件数量的默认限制已大大增加。Java 8在尝试为此数量的文件描述符预先分配内存方面做了错误的事情（请参阅https://bugs.openjdk.java.net/browse/JDK-8150460）。以前，当默认限制要低得多时，此方法有效，但现在，它尝试分配过多而失败。解决方法是设置打开文件数的下限（或使用较新的java）：

各操作系统安装kata

cnetos7 kata v1

1 2	yum-config-manager --add-repo http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/stable-1.11/CentOS_7/home:katacontainers:releases:x86_64:stable-1.11.repo

centos8 kata v1

tee /etc/yum.repos.d/advanced-virt.repo <<-'EOF'
[advanced-virt]
name=Advanced Virtualization
baseurl=https://mirrors.huaweicloud.com/centos/$releasever/virt/$basearch/advanced-virtualization
enabled=1
gpgcheck=0
skip_if_unavailable=1
EOF

tee /etc/yum.repos.d/kata-containers.repo <<-'EOF'
[kata-containers]
name=Kata Containers
baseurl=https://mirrors.huaweicloud.com/centos/$releasever/virt/$basearch/kata-containers
enabled=1
gpgcheck=0
skip_if_unavailable=1
EOF

dnf module disable -y virt:rhel
dnf install -y kata-runtime

centos8 kata v2

v1和v2的差异在于，安装kata-containers即会安装v2，安装kata-runtime即会安装v1

sudo -E dnf install -y centos-release-advanced-virtualization
sudo -E dnf module disable -y virt:rhel
source /etc/os-release
cat <<EOF | sudo -E tee /etc/yum.repos.d/kata-containers.repo
[kata-containers]
name=Kata Containers
baseurl=http://mirror.centos.org/\$contentdir/\$releasever/virt/\$basearch/kata-containers
enabled=1
gpgcheck=1
skip_if_unavailable=1
EOF
sudo -E dnf install -y kata-containers

由于Docker尚不直接支持容器化的shimv2架构，因此Kata 2.0.0不适用于Docker。

Kata 1.x运行时可与docker一起使用

kata中使用alpine系统存在的java问题

当前都是kata运行时，并且版本都是1.11+

经过我的测试是文件打开数太大导致java无法运行

当image是FROM alpine时无法运行，

当image是FROM slim时可以运行，

Centos8系统安装的docker，所有容器的文件打开数默认是1048576

Centos7系统安装的docker，所有容器的文件打开数默认是1073741816

并且docker版本都是最新的20.10.6

解决方法：

方法1，不使用基于alpine为基础image的docker镜像，很显然是当文件打开数太大，kata下的alpine会运行错误。很多服务都是以alpine运行的，这个方法不推荐

方法2，使用kata运行时，使用centos8系统运行docker，不使用centos7。这个是推荐方法

方法3，可以在docker系统服务文件加上dockerd启动参数

--default-ulimit nofile=65535:65535 设置所有容器的文件打开数

设置LimitNOFILE=65535是无效的，并不会更改docker所有容器的文件打开数。

containerd下可以指定是否使用kata-runtime运行时

使用ctr命令行启动容器

要通过容器命令行使用Kata Containers运行容器，可以运行以下命令：

sudo ctr image pull docker.io/library/busybox:latest

sudo ctr run –runtime io.containerd.run.kata.v2 -t –rm
docker.io/library/busybox:latest hello sh

这将启动一个名为的BusyBox容器hello，–rm退出后将被删除。

在k8s1.12+下利用RuntimeClass选择性使用kata

查看当前机器下containerd容器使用了什么运行时来运行容器

ctr -n k8s.io c ls

kata-runtime是隔断网络访问的，所以为了k8s组件可以正常运行，containerd默认的运行时不可以设置为kata，可以使用下面的2种方式指定运行时运行容器

containerd支持kata-runtimev2的接口，在配置untrusted_workload_runtime时，直接使用katav2的类型io.containerd.kata.v2，没有io.containerd.kata.v1这种类型

因为不存在 runtime_type = “io.containerd.kata.v1”，我们可以使用runtime_type =
“io.containerd.kata.v2”来调用kata-runtime，containerd并不关心运行的kata是v1还是v2

1、untrusted_workload_runtime 的方式

kata-v1


[plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
  runtime_type = "io.containerd.runtime.v1.linux"
  runtime_engine = "/usr/bin/kata-runtime"

或者

1 2	[plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime] runtime_type = "io.containerd.kata.v2"

kata-v2

1
2
3

[plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
  runtime_type = "io.containerd.kata.v2"

k8s调用


apiVersion: v1
kind: Pod
metadata:
  name: nginx-untrusted
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  containers:
  - name: nginx
    image: nginx

2、RuntimeClass 方式

首先需要在containerd配置文件中增加


kata-v2	
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
          runtime_type = "io.containerd.kata.v2"  
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
            SystemdCgroup = true

kata-v1			
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
          runtime_type = "io.containerd.kata.v2"  
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
            SystemdCgroup = true

因为不存在 runtime_type = “io.containerd.kata.v1”，我们可以使用runtime_type =
“io.containerd.kata.v2”来调用kata-runtime，containerd并不关心运行的kata是v1还是v2

在 K8s 中创建 RuntimeClass


apiVersion: node.k8s.io/v1beta1  # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
  name: kata  
handler: kata  # 这里与containerd配置文件中的 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.{handler}] 匹配
创建pod

apiVersion: v1
kind: Pod
metadata:
  name: kata-nginx
spec:
  runtimeClassName: kata
  containers:
    - name: nginx
      image: nginx
      ports:
      - containerPort: 80