如需了解版本信息，请参阅 Distributed Cloud Connected 版本说明。

部署工作负载

本页面介绍了在 Google Distributed Cloud Connected 硬件上部署工作负载的步骤，以及在配置工作负载时必须遵守的限制。

在完成这些步骤之前，您必须满足 Distributed Cloud Connected 安装要求并订购 Distributed Cloud 硬件。

当 Google Distributed Cloud Connected 硬件到达您选择的目的地时，它已预配置了硬件、 Google Cloud以及您在订购 Distributed Cloud Connected 时指定的一些网络设置。

Google 安装人员会完成物理安装，而您的系统管理员会将 Distributed Cloud Connected 连接到本地网络。

硬件连接到本地网络后，会与 Google Cloud 通信，以下载软件更新并与您的Google Cloud 项目建立连接。然后，您就可以在 Distributed Cloud Connected 上预配节点池和部署工作负载了。

部署概览

如需在 Distributed Cloud 连接的硬件上部署工作负载，请完成以下步骤：

可选：启用 Distributed Cloud Edge Network API。
可选：初始化 Distributed Cloud connected 可用区的网络配置。
可选：配置 Distributed Cloud 网络。
创建 Distributed Cloud connected 集群。
可选：如果您想与 Cloud Key Management Service 集成，以支持为工作负载数据使用 CMEK，请为本地存储启用对客户管理的加密密钥 (CMEK) 的支持。如需了解 Distributed Cloud Connected 如何加密工作负载数据，请参阅本地存储安全。
创建节点池。在此步骤中，您将节点分配给节点池，并可以选择性地将节点池配置为使用 Cloud KMS 来封装和解封装 Linux 统一密钥设置 (LUKS) 密码，以加密工作负载数据。
获取集群的凭据以测试集群。
通过向用户分配项目的 Edge Container Viewer 角色 (roles/edgecontainer.viewer) 或 Edge Container Admin 角色 (roles/edgecontainer.admin)，授予用户对集群的访问权限。
使用 RoleBinding 和 ClusterRoleBinding 为用户分配对集群资源的基于角色的精细访问权限。
可选：启用 VM Runtime on Google Distributed Cloud 支持，以便在 Distributed Cloud Connected 上的虚拟机中运行工作负载。
可选：启用 GPU 支持，以便在 Distributed Cloud Connected 上运行基于 GPU 的工作负载。
可选：将 Distributed Cloud connected 集群连接到Google Cloud：
1. 创建与 Google Cloud 项目的 VPN 连接。
2. 检查 VPN 连接是否正常运行。
可选：配置专用 Google 访问通道，以允许 Pod 使用 Cloud VPN 访问Google Cloud API 和服务。
可选：配置 Private Service Connect，以允许您的 Pod 使用 Cloud VPN 访问Google Cloud API 和服务。

将 NGINX 负载均衡器部署为服务

以下示例展示了如何在连接的分布式云集群上部署 NGINX 服务器并将其公开为服务：

创建一个名为 nginx-deployment.yaml 的 YAML 文件，其中包含以下内容：

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

使用以下命令将 YAML 文件应用到集群：
```
kubectl apply -f nginx-deployment.yaml
```

创建一个名为 nginx-service.yaml 的 YAML 文件，其中包含以下内容：

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

使用以下命令将 YAML 文件应用到集群：
```
kubectl apply -f nginx-deployment.yaml
```

使用以下命令获取 MetalLB 负载平衡器分配给服务的外部 IP 地址：

kubectl get services

该命令会返回类似于以下内容的输出：

NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

部署具有 SR-IOV 功能的容器

以下示例说明了如何部署使用 Distributed Cloud Connected 的 SR-IOV 网络功能运算符功能的 Pod。

创建分布式 Cloud 网络组件

为您的 Distributed Cloud 连接部署创建所需的网络组件，如下所示。如需详细了解这些组件，请参阅 Distributed Cloud Connected 网络功能。

创建网络：
```
gcloud edge-cloud networking networks create NETWORK_NAME \
    --location=REGION \
    --zone=ZONE_NAME \
    --mtu=MTU_SIZE
```
替换以下内容：
- NETWORK_NAME：唯一标识相应网络的描述性名称。
- REGION：目标 Distributed Cloud 可用区所属的 Google Cloud 区域。
- ZONE_NAME：目标 Distributed Cloud 已连接区域的名称。
- MTU_SIZE：相应网络的最大传输单元 (MTU) 大小。有效值为 1500 和 9000。此值必须与 default 网络的 MTU 大小一致，并且对于所有网络都相同。
创建子网：
```
gcloud edge-cloud networking subnets create SUBNETWORK_NAME \
    --network=NETWORK_NAME \
    --ipv4-range=IPV4_RANGE \
    --vlan-id=VLAN_ID \
    --location=REGION \
    --zone=ZONE_NAME
```
替换以下内容：
- SUBNETWORK_NAME：可唯一标识相应子网的描述性名称。
- NETWORK_NAME：封装相应子网的网络。
- IPV4_RANGE：相应子网覆盖的 IPv4 地址范围（采用 IP 地址/前缀格式）。
- VLAN_ID：相应子网的目标 VLAN ID。
- REGION：目标 Distributed Cloud connected 可用区所属的 Google Cloud 区域。
- ZONE_NAME：目标 Distributed Cloud 已连接区域的名称。
监控子网的状态，直到子网成功创建：
```
watch -n 30 'gcloud edge-cloud networking subnets list \
    --location=REGION \
    --zone=ZONE_NAME
```
替换以下内容：
- REGION：目标 Distributed Cloud connected 可用区所属的 Google Cloud 区域。
- ZONE_NAME：目标 Distributed Cloud 已连接区域的名称。
状态从 PENDING 变为 PROVISIONING，最终变为 RUNNING。

记录 VLAN ID、子网 CIDR 地址块以及 CIDR 地址块的网关 IP 地址。您将在本流程的后续步骤中使用这些值。

配置 `NodeSystemConfigUpdate` 资源

为集群中的每个节点配置一个 NodeSystemConfigUpdate 网络功能运算符资源，如下所示。

使用以下命令列出目标集群的节点池中运行的节点：

kubectl get nodes | grep -v master

该命令会返回类似于以下内容的输出：

NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

记录返回的节点名称并推导其短名称。例如，对于 pool-example-node-1-01-b2d82cc7 节点，其简称为 node101。

对于您在上一步中记录的每个节点，创建一个专用的 NodeSystemConfigUpdate 资源文件，其中包含以下内容：

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

替换以下内容：

NODE_NAME：目标节点的完整名称。例如 pool-example-node-1-01-b2d82cc7。
NODE_SHORT_NAME：目标节点的简称，从其全名派生而来。例如 node101。

将每个文件命名为 node-system-config-update-NODE_SHORT_NAME.yaml。

使用以下命令将每个 NodeSystemConfigUpdate 资源文件应用于集群：
```
kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml
```
将 NODE_SHORT_NAME 替换为相应目标节点的简称。

将资源应用到集群后，每个受影响的节点都会重新启动，这可能需要长达 30 分钟的时间。
1. 监控受影响节点的状态，直到所有节点都成功重启：
```
kubectl get nodes | grep -v master
```
随着每个节点的重新启动完成，其状态会从 not-ready 转换为 ready。

为 SR-IOV 网络功能配置 ToR 交换机

按照本部分中的步骤，在分布式云连接机架中的每个分布式云 ToR 交换机中配置网络接口，以实现 SR-IOV 网络功能操作。

创建名为 mlnc6-pcie1-tor1-sriov.yaml 的文件，其中包含以下内容。此文件用于配置第一个 ToR 交换机上的第一个网络接口。

  apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor1_sriov

创建名为 mlnc6-pcie1-tor2-sriov.yaml 的文件，其中包含以下内容。此文件用于配置第一个 ToR 交换机上的第二个网络接口。

  apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor2_sriov

创建名为 mlnc6-pcie2-tor1-sriov.yaml 的文件，其中包含以下内容。此文件用于配置第二个 ToR 交换机上的第一个网络接口。

  apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor1_sriov

创建名为 mlnc6-pcie2-tor2-sriov.yaml 的文件，其中包含以下内容。此文件用于配置第二个 ToR 交换机上的第二个网络接口。

  apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor2_sriov

使用以下命令将 ToR 配置文件应用于集群：

kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml

受影响的节点会被封锁、排空并重新启动。

使用以下命令监控节点的状态：

watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ 
grep "syncStatus\|pool-"|sed "N;s/\n/ /"'

当所有受影响的节点都显示 syncStatus: Succeeded 时，按 Ctrl+C 退出监控命令循环。

该命令会返回类似于以下内容的输出，表明已在 ToR 交换机上启用 SR-IOV 网络功能：

Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource                       Requests     Limits
--------                       --------     ------
cpu                            2520m (3%)   7310m (9%)
memory                         3044Mi (1%)  9774Mi (3%)
ephemeral-storage              0 (0%)       0 (0%)
hugepages-1Gi                  0 (0%)       0 (0%)
hugepages-2Mi                  0 (0%)       0 (0%)
devices.kubevirt.io/kvm        0            0
devices.kubevirt.io/tun        0            0
devices.kubevirt.io/vhost-net  0            0
gke.io/mlnx6_pcie1_tor1_sriov  3            3
gke.io/mlnx6_pcie1_tor2_sriov  0            0
gke.io/mlnx6_pcie2_tor1_sriov  0            0
gke.io/mlnx6_pcie2_tor2_sriov  0            0

配置 `NetworkAttachmentDefinition` 资源

按如下方式为集群配置 NetworkAttachmentDefinition 资源：

创建名为 network-attachment-definition.yaml 且包含以下内容的文件：

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
  k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov
spec:
config: '{
"type": "sriov",
"cniVersion": "0.3.1",
"vlan": VLAN_ID,
"name": "sriov-network",
"ipam": {
  "type": "host-local",
  "subnet": "SUBNETWORK_CIDR",
  "routes": [{
     "dst": "0.0.0.0/0"
  }],
  "gateway": "GATEWAY_ADDRESS"
}
}'

替换以下内容：

VLAN_ID：您在本指南前面部分创建的子网的 VLAN ID。
SUBNETWORK_CIDR：子网的 CIDR 地址块。
GATEWAY_ADDRESS：子网的网关 IP 地址。

使用以下命令将资源应用到集群：

kubectl apply -f network-attachment-definition.yaml

部署具有 SR-IOV 网络功能的 Pod

完成本部分中的步骤，以在集群上部署具有 SR-IOV 网络功能的 Pod。Pod 配置文件中的 annotations 字段指定了您在本指南前面部分中创建的 NetworkAttachmentDefinition 资源的名称以及该资源已部署到的命名空间（在本例中为 default）。

创建一个名为 sriovpod.yaml 且包含以下内容的 Pod 规范文件：

     apiVersion: v1
     kind: Pod
     metadata:
     name: sriovpod
     annotations:
        k8s.v1.cni.cncf.io/networks: default/sriov-net1
     spec:
     containers:
     - name: sleeppodsriov
        command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
        image: busybox
        securityContext:
           capabilities:
           add:
              - NET_ADMIN

使用以下命令将 Pod 规范文件应用于集群：
```
kubectl apply -f sriovpod.yaml
```
使用以下命令验证 Pod 是否已成功启动：
```
kubectl get pods
```
使用以下命令为 Pod 建立命令行 shell：
```
kubectl exec -it sriovpod -- sh
```

在 Pod shell 中使用以下命令，确认 Pod 是否正在使用 SR-IOV 网络功能运算符功能与 ToR 交换机通信：

ip addr

该命令会返回类似于以下内容的输出：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000
   link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.11/25 brd 192.168.100.127 scope global net1
      valid_lft forever preferred_lft forever
228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
   link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff
   inet 10.10.3.159/32 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link 
      valid_lft forever preferred_lft forever

为 net1 接口返回的信息表示 ToR 交换机和 Pod 之间的网络连接已建立。

配置用于映像缓存的 Pod

您可以配置在 Distributed Cloud 连接集群上运行的 Pod 来缓存其映像。在首次从代码库拉取映像后，Pod 便开始使用缓存的映像。如果托管 Pod 的节点存储空间用尽，系统不会缓存新映像，并且会清除现有映像缓存，以确保工作负载继续不间断地运行。

您的 Pod 配置必须满足以下前提条件：

您必须在 Pod 上设置 gdce.baremetal.cluster.gke.io/cache-image: true 标签。
如果您使用的是私有映像代码库，则 ImagePullSecret 资源必须为 kubernetes.io/dockerconfigjson 类型。
您必须将 Pod 的拉取政策设置为 IfNotPresent，以确保始终使用目标映像的缓存副本。如果本地没有缓存副本，则从代码库中拉取映像。

以下示例展示了启用缓存的 Pod 配置：

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

以下示例展示了启用缓存的 Deployment 配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Distributed Cloud 工作负载的限制

配置 Distributed Cloud 连接的工作负载时，您必须遵守本部分中所述的限制。这些限制由 Distributed Cloud connected 在您部署到 Distributed Cloud connected 硬件上的所有工作负载上强制执行。

Linux 工作负载限制

Distributed Cloud Connected 仅支持以下工作负载的 Linux 功能：

AUDIT_READ
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_RAW
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT
SYS_NICE
SYS_PACCT
SYS_PTRACE
SYS_RESOURCE
SYS_TIME

命名空间限制

Distributed Cloud Connected 不支持以下命名空间：

hostPID
hostIPC
hostNetwork

资源类型限制

Distributed Cloud Connected 不支持 CertificateSigningRequest 资源类型，该类型允许客户端根据签名请求请求颁发 X.509 证书。

安全上下文限制

Distributed Cloud Connected 不支持特权模式安全上下文。

Pod 绑定限制

Distributed Cloud Connected 不支持将 Pod 绑定到 HostNetwork 命名空间中的主机端口。此外，HostNetwork 命名空间不可用。

`hostPath` 音量限制

Distributed Cloud Connected 仅允许以下具有读/写访问权限的 hostPath 卷：

/dev/hugepages
/dev/infiniband
/dev/vfio
/dev/char
/sys/devices

`PersistentVolumeClaim` 个资源类型限制

Distributed Cloud Connected 仅允许以下 PersistentVolumeClaim 资源类型：

csi
nfs
local

卷类型限制

Distributed Cloud Connected 仅允许使用以下卷类型：

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Pod 容忍限制

Distributed Cloud Connected 不允许在控制平面节点上创建用户创建的 Pod。具体而言，Distributed Cloud Connected 不允许调度具有以下容忍键的 Pod：

""
node-role.kubernetes.io/master
node-role.kubernetes.io/control-plane

模拟限制

Distributed Cloud Connected 不支持用户或群组模拟。

管理命名空间限制

Distributed Cloud Connected 不允许访问以下命名空间：

ai-system
ai-speech-system
ai-ocr-system
ai-translation-system
anthos-identity-service
cert-manager
dataproc-system
dataproc-PROJECT_ID
dns-system
g-istio-system
gke-connect
gke-managed-metrics-server
gke-operators
g-ospf-servicecontrol-system
g-ospf-system
g-pspf-system
gke-system
gpc-backup-system
iam-system
kube-node-lease
kube-public
kube-system，但删除 ippools.whereabouts.cni.cncf.io 除外
metallb-system，但编辑 configMap 资源以设置负载平衡 IP 地址范围除外
nf-operator
oclcm-system
prediction
rm-system
robinio
saas-system
sriov-fec-system
sriov-network-operator
vm-system

PROJECT_ID 表示目标 Google Cloud 项目的 ID。

避免使用名称中包含 g- 前缀的任何命名空间。此类命名空间通常是 Distributed Cloud connected 使用的预留命名空间。

网络钩子限制

Distributed Cloud connected 对 Webhook 的限制如下：

您创建的任何变更 webhook 都会自动排除 kube-system 命名空间。
以下资源类型的更改性 webhook 已停用：
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

Pod 优先级限制

Distributed Cloud Connected 要求您将工作负载 Pod 的优先级设置为低于 500000000 的值。

为 Pod 配置运行时类

借助 Distributed Cloud Connected，您可以使用 runtimeClassName 字段在 Pod 的配置中指定其运行时类。此设置会替换在集群级别指定的默认运行时类。可用的运行时类为 runc 和 gvisor。例如：

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

如果您在 Pod 配置中省略此项，Pod 将使用集群级层指定的类。默认的集群级运行时类为 runc，除非您使用 --default-container-runtime 参数配置默认运行时类，如创建和管理集群中所述。

如果您在 Pod 或集群级别更改运行时类，则必须重启受影响的 Pod，更改才会生效。

`gvisor` 运行时类

指定 gvisor 运行时类会将 Pod 切换到基于 gVisor 的开放容器倡议 (OCI) 安全运行时。gVisor 是一种沙盒解决方案，可在工作负载及其宿主之间引入强大的隔离。

后续步骤

应用安全性最佳实践

部署工作负载 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

部署概览

将 NGINX 负载均衡器部署为服务

部署具有 SR-IOV 功能的容器

创建分布式 Cloud 网络组件

配置 NodeSystemConfigUpdate 资源

为 SR-IOV 网络功能配置 ToR 交换机

配置 NetworkAttachmentDefinition 资源

部署具有 SR-IOV 网络功能的 Pod

配置用于映像缓存的 Pod

Distributed Cloud 工作负载的限制

Linux 工作负载限制

命名空间限制

资源类型限制

安全上下文限制

Pod 绑定限制

hostPath 音量限制

PersistentVolumeClaim 个资源类型限制

卷类型限制

Pod 容忍限制

模拟限制

管理命名空间限制

网络钩子限制

Pod 优先级限制

为 Pod 配置运行时类

gvisor 运行时类

后续步骤

部署工作负载

配置 `NodeSystemConfigUpdate` 资源

配置 `NetworkAttachmentDefinition` 资源

`hostPath` 音量限制

`PersistentVolumeClaim` 个资源类型限制

`gvisor` 运行时类