gVisor 与 Kubernetes 快速上手从 GKE Sandbox 到自建集群的 RuntimeClass 集成指南【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor导读本文以 g3doc/user_guide/quick_start/kubernetes.md 为骨架系统讲解 gVisor容器应用内核在 Kubernetes 中的三种主流接入方式——GKE Sandbox托管节点池、Minikube本地开发、以及基于 containerd containerd-shim-runsc-v1的自建集群方案。读完你将掌握如何创建带 gVisor 的节点池、配置 RuntimeClass、编写带runtimeClassName: gvisor的 Pod 清单并能结合仓库源码理解其底层集成机制与排障手段。为什么 Kubernetes 需要 gVisorgVisor 定位为 Application Kernel for Containers它不是虚拟机监控器也不是简单的 seccomp 过滤器而是一个运行在用户态的应用内核Sentry用内存安全的 Go 从零重实现了 Linux 系统调用接口、内存管理、文件系统、网络栈、进程管理与信号处理等内核逻辑不把沙箱内工作负载的系统调用直接透传给宿主机内核。详见 g3doc/architecture_guide/intro_to_gvisor.md。在 Kubernetes 场景下这意味着攻击面被大幅收敛即使 Pod 内应用被攻破攻击者面对的是 gVisor Sentry 重实现的“假内核”而非宿主 Linux 内核与普通 runc 容器相比Pod 运行在独立的双内核隔离边界内同时比虚拟机更轻量可在运行时按需分配/释放宿主机 CPU 与内存资源。gVisor 在 Kubernetes 中有多个集成点最常见的就是通过 KubernetesRuntimeClass机制让调度器把特定 Pod 路由到 gVisor 运行时runsc上。仓库的测试集群代码中定义了一组已知运行时类型常量test/kubernetes/testcluster/objects.goconst ( RuntimeTypeGVisor RuntimeType(gvisor) RuntimeTypeUnsandboxed RuntimeType(runc) RuntimeTypeGVisorTPU RuntimeType(gvisor-tpu) RuntimeTypeKataQEMU RuntimeType(kata-qemu) RuntimeTypeKataCloudHypervisor RuntimeType(kata-cloudhypervisor) ... )测试集群在创建 Pod 时会直接设置podSpec.RuntimeClassName proto.String(gvisorRuntimeClass)见 test/kubernetes/testcluster/objects.go这正是“注解即路由”的落地形态。方式一GKE Sandbox托管式零运维概念与适用场景GKE Sandbox 是 Google Kubernetes Engine 提供的托管能力只需在集群中部署一个开启 gVisor 的节点池所有带runtimeClassName: gvisor注解的 Pod 都会自动运行在 gVisor 沙箱中无需自行管理 runsc、shim 或节点配置。官方仓库在 g3doc/user_guide/tutorials/kubernetes.md 中给出了完整的 WordPress 示例这是理解 GKE Sandbox 用法的最直观材料。前置准备在 Google Cloud Console 的 Kubernetes Engine 页面创建或选择一个项目启用 Kubernetes Engine API。创建启用 gVisor 的节点池用命令行创建节点池时只需在gcloud container node-pools create命令中追加--sandbox typegvisor参数gcloud container node-pools create gvisor --cluster${CLUSTER_NAME?} --sandbox typegvisor --machine-typee2-standard-2如果偏好图形界面在集群详情页点击ADD NODE POOL按钮然后在左侧Security标签页勾选Enable sandbox with gVisor其余选项按需选择即可。验证 gVisor 已启用节点创建过程中会自动实例化名为gvisor的 RuntimeClass验证命令$ kubectl get runtimeclass/gvisor NAME HANDLER AGE gvisor gvisor 1h注意这里 HANDLER 显示的也是gvisor与通过 containerd shim 自建时使用的 handlerrunsc不同——后者对应containerd-shim-runsc-v1。部署 WordPress 示例WordPress 站点需要两个 Pod前端 Web 服务器和 MySQL 数据库二者都使用PersistentVolume存储数据并通过 Secret 共享 MySQL 密码。重要提示官方示例只对前端 Web 服务器启用 gVisor 沙箱不建议把数据库放进沙箱。原因在于 gVisor 的 I/O 开销详见 g3doc/architecture_guide/performance.md会影响数据库这类 I/O 密集应用而前端是对外攻击面最大的组件是安全/性能权衡下最适合沙箱化的位置。生产部署前请阅读 g3doc/user_guide/production.md。先下载官方部署清单并在两个文件中加入runtimeClassName: gvisor以 wordpress-deployment.yaml 为例curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yamlapiVersion: v1 kind: Service metadata: name: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: wp-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: frontend strategy: type: Recreate template: metadata: labels: app: wordpress tier: frontend spec: runtimeClassName: gvisor # ADD THIS LINE containers: - image: wordpress:4.8-apache name: wordpress env: - name: WORDPRESS_DB_HOST value: wordpress-mysql - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: password ports: - containerPort: 80 name: wordpress volumeMounts: - name: wordpress-persistent-storage mountPath: /var/www/html volumes: - name: wordpress-persistent-storage persistentVolumeClaim: claimName: wp-pv-claimmysql-deployment.yaml 同理唯一区别是runtimeClassName: gvisor默认被注释掉如需沙箱化数据库可取消注释spec: #runtimeClassName: gvisor # Uncomment this line if you want to sandbox the database. containers: - image: mysql:5.6 name: mysql ...关键点除了新增runtimeClassName: gvisor一行其余 Deployment 配置完全不变——这是 gVisor 与 Kubernetes 集成的核心体验沙箱化对应用清单的侵入为零。创建 Secret 并部署整个应用$ kubectl create secret generic mysql-pass --from-literalpassword${YOUR_SECRET_PASSWORD_HERE?} $ kubectl apply -f mysql-deployment.yaml $ kubectl apply -f wordpress-deployment.yaml等待 Deployment 就绪、Service 获得外部 IP$ watch kubectl get service wordpress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE wordpress LoadBalancer 10.120.16.63 35.203.179.216 80:31025/TCP 1m将EXTERNAL-IP复制到浏览器即可访问并配置 WordPress。方式二Minikube本地快速验证在本地开发环境中gVisor 通过 Minikube 的 addon 机制接入。启用 gVisor addon 后Pod 中设置runtimeClassName: gvisor即可用 runsc 执行。启用方式请参考 Minikube 官方仓库的 gvisor addon 文档g3doc/user_guide/quick_start/kubernetes.md 原文链接。这是体验“一条命令起一个沙箱集群”的最快路径适合在笔记本上先行验证应用在 gVisor 下的兼容性。方式三containerd gVisor shim自建集群这是把 gVisor 接入自建 Kuberneteskubeadm、kind、EKS 等的标准方案。核心组件是containerd-shim-runsc-v1——它实现了 containerd 的 shim v2 协议受 containerd 1.3 及以上版本支持见 shim/README.md。shim 收到 CRI 调用后会把容器生命周期操作转交给 runscgVisor 的 OCI 运行时实现。完整步骤见 g3doc/user_guide/containerd/quick_start.md这里提炼关键环节。1. 前置要求runsc 与 containerd-shim-runsc-v1按 g3doc/user_guide/install.md 安装containerd最低支持版本1.3.9 或 1.4.3见 containerd 官网。⚠️ 若你的集群是用kubeadm搭建的可能遇到问题详见 g3doc/user_guide/FAQ.md 中关于 runtime handler 的说明。2. 配置 containerd编辑/etc/containerd/config.toml注册runsc运行时。确保containerd-shim-runsc-v1在${PATH}中或与 containerd 二进制同目录cat EOF | sudo tee /etc/containerd/config.toml version 2 [plugins.io.containerd.runtime.v1.linux] shim_debug true [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runsc] runtime_type io.containerd.runsc.v1 EOF若使用 containerd 2.x可考虑将版本头改为version 3二者差异参见 containerd 官方 PLUGINS 文档。3. 安装 CNI 插件与重启后续步骤通常需要 CNI 插件快速安装方式使用默认设置git clone --depth1 -b {CONTAINERD_VERSION} https://github.com/containerd/containerd.git cd containerd ./script/setup/install-cni重启 containerd 使配置生效sudo systemctl restart containerd4. 用 ctr 验证 gVisor 运行时ctr直接与 containerd 通信随 containerd 一起发布。拉取并运行一个容器使用--runtime io.containerd.runsc.v1指定 gVisorsudo ctr image pull docker.io/library/hello-world:latest sudo ctr run --runtime io.containerd.runsc.v1 -t --rm docker.io/library/hello-world:latest hello-wrold5. 用 dmesg 验证确实运行在 gVisor 中gVisor 沙箱内的dmesg读取的是 Sentry 重实现的内核日志会输出标志性的幽默启动信息由 gVisor 系统调用处理器按需生成每次运行内容不同$ sudo ctr image pull docker.io/library/busybox:latest $ sudo ctr run --runtime io.containerd.run.runsc.v1 -t --rm docker.io/library/busybox:latest gvisord dmesg [ 0.000000] Starting gVisor... [ 0.445958] Forking spaghetti code... [ 0.794963] Feeding the init monster... [ 0.842573] Synthesizing system calls... [ 0.985066] Generating random numbers by fair dice roll... [ 1.444465] Mounting deweydecimalfs... [ 1.546130] Waiting for children... [ 1.689078] Searching for socket adapter... [ 2.026282] Accelerating teletypewriter to 9600 baud... [ 2.274752] Creating process schedule... [ 2.498083] Reticulating splines... [ 2.675603] Setting up VFS... [ 2.750186] Setting up FUSE... [ 2.789133] Ready!这些日志证明 busybox 的dmesg(1)二进制在与 gVisor 内核对话而不是宿主 Linux 内核宿主上直接运行dmesg通常会得到Operation not permitted。提示原文档此命令写作io.containerd.run.runsc.v1与 containerd 配置中的io.containerd.runsc.v1不一致。以配置注册的io.containerd.runsc.v1为准参见 g3doc/user_guide/containerd/quick_start.md 的 runtime_type 设置。6. 用 crictl 走完整 CRI 流程crictl面向 CRI 兼容容器更接近 Kubernetes 的真实调用路径。安装{ wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.13.0/crictl-v1.13.0-linux-amd64.tar.gz tar xf crictl-v1.13.0-linux-amd64.tar.gz sudo mv crictl /usr/local/bin }写入 crictl 配置cat EOF | sudo tee /etc/crictl.yaml runtime-endpoint: unix:///run/containerd/containerd.sock EOFStep 1拉取镜像并创建沙箱Podsudo crictl pull nginxcat EOF | tee sandbox.json { metadata: { name: nginx-sandbox, namespace: default, attempt: 1, uid: hdishd83djaidwnduwk28bcsb }, linux: { }, log_directory: /tmp } EOFSANDBOX_ID$(sudo crictl runp --runtime runsc sandbox.json)Step 2在沙箱内创建并启动 nginx 容器cat EOF | tee container.json { metadata: { name: nginx }, image:{ image: nginx }, log_path:nginx.0.log, linux: { } } EOFCONTAINER_ID$(sudo crictl create ${SANDBOX_ID} container.json sandbox.json) sudo crictl start ${CONTAINER_ID}Step 3校验sudo crictl inspectp ${SANDBOX_ID} sudo crictl inspect ${CONTAINER_ID} sudo crictl exec ${CONTAINER_ID} dmesg | grep -i gvisorinspectp检查 Pod、inspect检查容器最后的dmesg | grep -i gvisor是确认 nginx 运行在 gVisor 沙箱内的最直接证据。让 Kubernetes 认识 gVisorRuntimeClass 详解无论哪种接入方式最终都落到同一个 Kubernetes 原语RuntimeClass。它把“运行时名称”与“实际 handler”解耦让 Pod 通过runtimeClassName声明自己需要的运行时。在 containerd 方案下安装 gVisor 的 RuntimeClass 并创建 Podcat EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc EOFcat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: nginx-gvisor spec: runtimeClassName: gvisor containers: - name: nginx image: nginx EOF验证kubectl get pod nginx-gvisor -o wide关键对应关系RuntimeClass 字段GKE Sandboxcontainerd 自建metadata.namegvisorgvisorhandlergvisorrunsc对应containerd-shim-runsc-v1GKE 的节点池创建流程会自动实例化gvisorRuntimeClasshandler 为gvisor自建集群则需要手动 apply 上面的 RuntimeClasshandler 为runsc且 containerd 配置中必须注册了runscruntime 才能正确路由。进阶shim 配置与共享卷 inotify自建集群接入后可进一步利用containerd-shim-runsc-v1的配置能力。shim 支持通过配置文件传入 shim 自身选项和 runsc 标志详见 g3doc/user_guide/containerd/configuration.mdcat EOF | sudo tee /etc/containerd/runsc.toml option value [runsc_config] flag value EOF[runsc_config]下的flag value会被转换为--flagvalue传给 runsc可用runsc flags查看全部可选标志配置文件通过 containerd 的ConfigPath传给 shimcat EOF | sudo tee /etc/containerd/config.toml version 2 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runsc] runtime_type io.containerd.runsc.v1 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runsc.options] TypeUrl io.containerd.runsc.v1.options ConfigPath /etc/containerd/runsc.toml EOFsudo systemctl restart containerd多容器共享卷的 inotify 问题默认情况下 gVisor 独立挂载各容器卷同一 Pod 内多个容器共享卷的文件变化可能无法被 inotify 正确捕获。GKE 会在控制面自动处理这些“挂载提示”但 EKS 等发行版需要手动配置在 containerd 配置中放行 gVisor 注解[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.gvisor] runtime_type io.containerd.runsc.v1 pod_annotations [ dev.gvisor.* ]在 Pod 上添加挂载提示注解以共享emptyDir为例apiVersion: v1 kind: Pod metadata: name: shared-folder-test annotations: dev.gvisor.spec.mount.shared-folder.share: pod dev.gvisor.spec.mount.shared-folder.type: tmpfs dev.gvisor.spec.mount.shared-folder.options: rw,rprivate spec: runtimeClassName: gvisor containers: - name: container1 image: node:14 command: [node, watcher.js] volumeMounts: - name: shared-folder mountPath: /shared - name: container2 image: busybox command: [/bin/sh, -c, while true; do echo hello /shared/test.txt; sleep 2; done] volumeMounts: - name: shared-folder mountPath: /shared volumes: - name: shared-folder emptyDir: {}注解语义速查g3doc/user_guide/containerd/configuration.mddev.gvisor.spec.mount.NAME.sharecontainer单容器使用/podPod 内多容器共享跨容器 inotify 生效/shared与 Pod 外部共享需频繁检查外部变更dev.gvisor.spec.mount.NAME.typetmpfs沙箱内 tmpfsemptyDir用 tmpfs 性能更佳/bind宿主机绑定挂载dev.gvisor.spec.mount.NAME.options逗号分隔的挂载选项如rw,rprivatedev.gvisor.spec.mount.NAME.directfsdefault跟随全局--directfs/off对该挂载关闭 directfs适用于无法捐献挂载根 fd 的自定义 gofer 文件系统dev.gvisor.empty-dir.NAME.force-sharedtrue时将特定emptyDir从 gVisor 内部 tmpfs 优化改为宿主机共享 bind 挂载适用于需与沙箱外进程如 CSI 驱动通过 UDS 通信的emptyDir。排障时可依次检查containerd 的pod_annotations是否配置卷名如shared-folder与注解键是否一致gVisor debug 日志中是否有告警。总结与生产化建议三条路径的本质一致通过 RuntimeClass 把 Pod 路由到 runsc差别只在于谁负责管理底层组件。方案管理方适用场景核心命令/组件GKE SandboxGoogle 托管生产托管、零运维--sandbox typegvisorMinikube本地开发验证gvisor addoncontainerd shim自建自有集群、EKS 等containerd-shim-runsc-v1 RuntimeClass(handler: runsc)上线前建议完成阅读 g3doc/user_guide/production.md 了解生产配置清单用dmesg、crictl inspect等手段确认 Pod 确实运行在 gVisor 沙箱内结合 g3doc/user_guide/debugging.md 提前规划 debug 日志如debug-log /var/log/runsc/%ID%/gvisor.%COMMAND%.log与监控方案对 I/O 密集应用数据库等评估是否适合沙箱化参考 g3doc/architecture_guide/performance.md。延伸阅读g3doc/user_guide/containerd/quick_start.mdcontainerd 接入完整指南g3doc/user_guide/containerd/configuration.mdshim 高级配置与调试g3doc/user_guide/tutorials/kubernetes.mdGKE Sandbox WordPress 完整示例g3doc/user_guide/quick_start/docker.mdDocker 快速上手--runtimerunscg3doc/architecture_guide/intro_to_gvisor.mdgVisor 安全模型与 Sentry 原理shim/README.mdcontainerd shim 集成概览g3doc/user_guide/FAQ.mdkubeadm 等常见问题【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考