听说过 OCI Runtime 不止 runc 还有 kata

OS:Ubuntu 22.04安装与配置通过 snap 安装 kata-containers,目前【2022-08-25】snap 中最新版本是 2.4.2 2022-06-08,但是官网的 release 已经发布到了 2.5.0。sudo snap install kata-containers

OS:Ubuntu 22.04

安装与配置

通过 snap 安装 kata-containers,目前【2022-08-25】snap 中最新版本是 2.4.2 2022-06-08,但是官网的 release 已经发布到了 2.5.0

sudo snap install kata-containers --stable --classic

设置默认的配置文件 /etc/kata-containers/configuration.toml

sudo mkdir -p /etc/kata-containers
sudo cp /snap/kata-containers/current/usr/share/defaults/kata-containers/configuration.toml /etc/kata-containers/

# 将 sandbox_cgroup_only 设置为 true
sudo sed -i 's/sandbox_cgroup_only=.*$/sandbox_cgroup_only=true/' /etc/kata-containers/configuration.toml

将 kata 的二进制链接到 PATH 涵盖的目录中,以便 containerd 能直接访问该二进制

sudo ln -sf /snap/kata-containers/current/usr/bin/containerd-shim-kata-v2 \
	/usr/local/bin/containerd-shim-kata-v2
sudo ln -sf /snap/kata-containers/current/usr/bin/kata-runtime \
	/usr/local/bin/kata-runtime

修改 containerd 的配置文件 /etc/containerd/config.toml

[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    [plugins."io.containerd.grpc.v1.cri".containerd]
      #default_runtime_name = "kata"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
          runtime_type = "io.containerd.kata.v2"
          privileged_without_host_devices = true
          pod_annotations = ["io.katacontainers.*"]
          container_annotations = ["io.katacontainers.*"]

检验安装是否正确

测试 kata-containers 配置是否正常,两次 ctr run 输出的结果应该会一样

sudo ctr image pull docker.io/library/busybox:latest
# 将使用 kata runtime
sudo ctr run --rm -t --runtime "io.containerd.kata.v2" \
    docker.io/library/busybox:latest test-kata-containers uname -r
# 将使用 runc runtime
sudo ctr run --rm -t docker.io/library/busybox:latest test-kata-containers uname -r

在 K8s 中使用 Kata 运行时,需要先创建 RuntimeClass 对象到 K8s 集群中,如下:

cat <<EOF | kubectl apply -f -
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
EOF

然后在 yaml 中手动指定 pod.spec.runtimeClass 字段为:名称是 kataRuntimeClass 对象,然后 containerd 才会使用 kata 作为运行时。

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dep
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      runtimeClassName: kata
      containers:
      - name: nginx
        image: ghcr.io/joengjyu/nginx:latest
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent
        resources:
        	requests:
        		cpu: 500m
        		memory: 512Mi
        	limits:
        	  cpu: 500m
        	  memory: 512Mi
EOF

成功运行后,结果如下:

$ uname -r
5.15.0-46-generic

$ kubectl exec nginx-dep-f6bbd75cf-7c9sq -- uname -r
5.15.26.container

遇到的问题

在配置完 containerd 和 kata 后,检测是否能正常运行时,遇到了如下报错

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

ctr: failed to create shim task: Could not create the sandbox resource controller cgroups: cgroup mountpoint does not exist: not found

在 kata-container 的 ISSUE #1927 中,找到一个与此问题类似的讨论,主要是将 kata 配置文件中的 sandbox_cgroup_only  字段设置成 true

但是修改后,错误依然存在。

索性找到了此报错信息在 kata-containers 中源码的位置,打了相关日志,重新创建 kata 相关的链接后

sudo ln -sf ~/kata-containers/src/runtime/kata-runtime /usr/local/bin/kata-runtime
sudo ln -sf ~/kata-containers/src/runtime/containerd-shim-kata-v2 /usr/local/bin/containerd-shim-kata-v2
sudo ln -sf ~/kata-containers/src/runtime/kata-monitor /usr/local/bin/kata-monitor

再次运行后,发现问题消失了。可能是 kata 版本的问题,通过 snap 安装的 kata 版本是 2.4.2 ,发布于 2022 年 6 月,最新稳定版本是 2.5.0,发布于  2022 年 8 月。其间只是隔了一两个版本。

Reference

Read more

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd