主页
产品
OpenShift Sandboxed Containers
1.9
用户指南
5.3. 使用命令行部署 OpenShift 沙盒容器

5.3. 使用命令行部署 OpenShift 沙盒容器

您可以使用命令行界面(CLI)在 Google Cloud 上部署 OpenShift 沙盒容器，以执行以下任务：

安装 OpenShift 沙盒容器 Operator。
可选：更改每个 worker 节点上运行的虚拟机数量。
可选：启用端口 15150，以允许内部与对等 pod 进行通信。
可选：如果您卸载了 Cloud Credential Operator，它与 OpenShift 沙盒容器 Operator 一起安装的，则创建 peer pod secret。
创建对等 pod 配置映射。
创建 pod 虚拟机镜像配置映射。
可选：自定义 Kata 代理策略。
创建 KataConfig 自定义资源。
配置 OpenShift 沙盒容器工作负载对象。

5.3.1. 安装 OpenShift 沙盒容器 Operator

您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。

先决条件

已安装 OpenShift CLI(oc)。
您可以使用具有 cluster-admin 角色的用户访问集群。

流程

创建 osc-namespace.yaml 清单文件：

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sandboxed-containers-operator

运行以下命令创建命名空间：
```
$ oc apply -f osc-namespace.yaml
```

创建 osc-operatorgroup.yaml 清单文件：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sandboxed-containers-operator-group
  namespace: openshift-sandboxed-containers-operator
spec:
  targetNamespaces:
  - openshift-sandboxed-containers-operator

运行以下命令来创建 operator 组：
```
$ oc apply -f osc-operatorgroup.yaml
```

创建 osc-subscription.yaml 清单文件：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sandboxed-containers-operator
  namespace: openshift-sandboxed-containers-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: sandboxed-containers-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: sandboxed-containers-operator.v1.9.0

运行以下命令来创建订阅：
```
$ oc apply -f osc-subscription.yaml
```
运行以下命令验证 Operator 是否已正确安装：
```
$ oc get csv -n openshift-sandboxed-containers-operator
```
此命令可能需要几分钟来完成。

运行以下命令监控进程：

$ watch oc get csv -n openshift-sandboxed-containers-operator

输出示例

NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.9.0    1.8.1        Succeeded

其他资源

在受限网络中使用 Operator Lifecycle Manager。
为断开连接的环境在 Operator Lifecycle Manager 中配置代理支持。

5.3.2. 为 Google Cloud 启用端口 15150

您必须在 OpenShift Container Platform 上启用端口 15150，以允许内部与 Compute Engine 上运行的对等 pod 通信。

先决条件

已安装 Google Cloud 命令行界面(CLI)工具。
您可以使用具有 roles/container.admin 角色的用户访问 OpenShift Container Platform 集群。

流程

运行以下命令来设置项目 ID 变量：
```
$ export GCP_PROJECT_ID="<project_id>"
```
运行以下命令登录到 Google Cloud：
```
$ gcloud auth login
```
运行以下命令来设置 Google Cloud 项目 ID：
```
$ gcloud config set project ${GCP_PROJECT_ID}
```

运行以下命令打开端口 15150 ：

$ gcloud compute firewall-rules create allow-port-15150-restricted \
   --project=${GCP_PROJECT_ID} \
   --network=default \
   --allow=tcp:15150 \
   --source-ranges=<external_ip_cidr-1>[,<external_ip_cidr-2>,...] 1

1: 以 CIDR 格式指定一个或多个 IP 地址或范围，用逗号分开。例如，203.0.113.5/32,198.51.100.0/24。

验证

运行以下命令验证端口 15150 已被打开：
```
$ gcloud compute firewall-rule list
```

5.3.3. 创建对等 pod secret

当对等 pod secret 为空并安装 Cloud Credential Operator (CCO)时，OpenShift 沙盒容器 Operator 会使用 CCO 检索 secret。如果卸载了 CCO，您必须手动为 OpenShift 沙盒容器创建对等 pod secret，否则对等 pod 将无法操作。

secret 存储用于创建 pod 虚拟机(VM)镜像和对等 pod 实例的凭证。

默认情况下，OpenShift 沙盒容器 Operator 根据用于创建集群的凭证创建 secret。但是，您可以手动创建使用不同的凭证的 secret。

先决条件

您已创建了带有权限（如 roles/compute.instanceAdmin.v1） 的 Google Cloud 服务帐户，以管理 Compute Engine 资源。
已安装 Google Cloud SDK (gcloud)并使用您的服务帐户进行身份验证。

流程

运行以下命令，创建 Google Cloud service account 密钥并将其保存为 JSON 文件：

$ gcloud iam service-accounts keys create <key_filename>.json \
  --iam-account=<service_account_email_address>

运行以下命令，将 JSON 文件转换为一行字符串：
```
$ cat <key_file>.json | jq -c .
```

根据以下示例创建 peer-pods-secret.yaml 清单文件：

apiVersion: v1
kind: Secret
metadata:
  name: peer-pods-secret
  namespace: openshift-sandboxed-containers-operator
type: Opaque
stringData:
  GCP_CREDENTIALS: "<gc_service_account_key_json>" 1

1: 使用从 Google Cloud service account key JSON 文件创建的单行字符串替换。

运行以下命令来创建 secret：
```
$ oc apply -f peer-pods-secret.yaml
```

5.3.4. 创建对等 pod 配置映射

您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。

流程

登录到您的 Compute Engine 实例以设置以下环境变量：
1. 运行以下命令来获取项目 ID：
```
$ GCP_PROJECT_ID=$(gcloud config get-value project)
```
2. 运行以下命令来获取区：
```
$ GCP_ZONE=$(gcloud config get-value compute/zone)
```
3. 运行以下命令来检索网络名称列表：
```
$ gcloud compute networks list --format="value(name)"
```
4. 运行以下命令来指定网络：
```
$ GCP_NETWORK=<network_name> 1
```
  1
  将 <network_name > 替换为网络的名称。
根据以下示例创建 peer-pods-cm.yaml 清单文件：
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "gcp"
  PROXY_TIMEOUT: "5m"
  GCP_PROJECT_ID: "<gcp_project_id>" 1
  GCP_ZONE: "<gcp_zone>" 2
  GCP_MACHINE_TYPE: "e2-medium" 3
  GCP_NETWORK: "<gcp_network>" 4
  PEERPODS_LIMIT_PER_NODE: "10" 5
  TAGS: "key1=value1,key2=value2" 6
  DISABLECVM: "true"
```
1
指定您要使用的项目 ID。
2
指定您检索的 GCP_ZONE 值。此区域将运行工作负载。
3
指定与工作负载要求匹配的机器类型。
4
指定您检索的 GCP_NETWORK 值。
5
指定每个节点可以创建的对等 pod 的最大数量。默认值为 10。
6
您可以将自定义标签配置为 pod 虚拟机实例的 key:value 对，以跟踪对等 pod 成本或标识不同集群中的对等 pod。
运行以下命令来创建配置映射：
```
$ oc apply -f peer-pods-cm.yaml
```

5.3.5. 创建对等 pod 虚拟机镜像

您必须创建一个 QCOW2 peer pod 虚拟机(VM)镜像。

先决条件

已安装 podman。
您可以访问容器 registry。

流程

运行以下命令克隆 OpenShift 沙盒容器存储库：

$ git clone https://github.com/openshift/sandboxed-containers-operator.git

运行以下命令，进入 sandboxed-containers-operator/config/peerpods/podvm/bootc ：
```
$ cd sandboxed-containers-operator/config/peerpods/podvm/bootc
```
运行以下命令登录到 registry.redhat.io ：
```
$ podman login registry.redhat.io
```
您必须登录 registry.redhat.io，因为 podman 构建进程 必须访问托管在 registry 上的 Containerfile.rhel 容器镜像。
运行以下命令，为您的容器 registry 设置镜像路径：
```
$ IMG="<container_registry_url>/<username>/podvm-bootc:latest"
```
运行以下命令构建 pod 虚拟机 bootc 镜像：
```
$ podman build -t ${IMG} -f Containerfile.rhel .
```
运行以下命令登录到您的容器 registry：
```
$ podman login <container_registry_url>
```
运行以下命令将镜像推送到容器 registry 中：
```
$ podman push ${IMG}
```
对于测试和开发，您可以使镜像变为公共镜像。

运行以下命令验证 podvm-bootc 镜像：

$ podman images

输出示例

REPOSITORY                               TAG     IMAGE ID      CREATED         SIZE
example.com/example_user/podvm-bootc     latest  88ddab975a07  2 seconds ago   1.82 GB

5.3.6. 创建对等 pod 虚拟机镜像配置映射

为 pod 虚拟机(VM)镜像创建配置映射。

流程

为 pod 虚拟机镜像创建一个名为 gc-podvm-image-cm.yaml 的配置映射清单，其内容如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: gc-podvm-image-cm
  namespace: openshift-sandboxed-containers-operator
data:
  IMAGE_TYPE: pre-built
  PODVM_IMAGE_URI: <container_registry_url>/<username>/podvm-bootc:latest
  IMAGE_BASE_NAME: "podvm-image"
  IMAGE_VERSION: "0-0-0"

  INSTALL_PACKAGES: "no"
  DISABLE_CLOUD_CONFIG: "true"
  UPDATE_PEERPODS_CM: "yes"
  BOOT_FIPS: "no"

  BOOTC_BUILD_CONFIG: |
    [[customizations.user]]
    name = "peerpod"
    password = "peerpod"
    groups = ["wheel", "root"]

    [[customizations.filesystem]]
    mountpoint = "/"
    minsize = "5 GiB"

    [[customizations.filesystem]]
    mountpoint = "/var/kata-containers"
    minsize = "15 GiB"

运行以下命令来创建配置映射：
```
$ oc apply -f gc-podvm-image-cm.yaml
```

5.3.7. 自定义 Kata 代理策略

Kata 代理策略是一种安全机制，用于控制使用 Kata 运行时运行的 pod 的代理 API 请求。使用 Rego 编写并由 Pod 虚拟机(VM)中的 Kata 代理强制，此策略决定哪些操作被允许或拒绝。

您可以针对特定用例使用自定义策略来覆盖默认策略，如在安全不是关注的地方进行开发和测试。例如，您可以在 control plane 可以被信任的环境中运行。您可以通过几种方法应用自定义策略：

将其嵌入到 pod 虚拟机镜像中。
修补对等 pod 配置映射。
为工作负载 pod YAML 添加注解。

对于生产环境系统，首选的方法是使用 initdata 覆盖 Kata 代理策略。以下流程使用 io.katacontainers.config.agent.policy 注解将自定义策略应用到单独的 pod。该策略以 Base64 编码的 Rego 格式提供。此方法会在创建 Pod 时覆盖默认策略，而不修改 pod 虚拟机镜像。

注意

自定义策略完全替换了默认策略。要只修改特定的 API，请包含完整的策略并调整相关规则。

流程

使用自定义策略创建 policy.rego 文件。以下示例显示了所有可配置的 API，并且为演示启用了 exec 和 log ：

package agent_policy

import future.keywords.in
import input

default CopyFileRequest := false
default CreateContainerRequest := false
default CreateSandboxRequest := true
default DestroySandboxRequest := true
default ExecProcessRequest := true  # Enabled to allow exec API
default GetOOMEventRequest := true
default GuestDetailsRequest := true
default OnlineCPUMemRequest := true
default PullImageRequest := true
default ReadStreamRequest := true   # Enabled to allow log API
default RemoveContainerRequest := true
default RemoveStaleVirtiofsShareMountsRequest := true
default SignalProcessRequest := true
default StartContainerRequest := true
default StatsContainerRequest := true
default TtyWinResizeRequest := true
default UpdateEphemeralMountsRequest := true
default UpdateInterfaceRequest := true
default UpdateRoutesRequest := true
default WaitProcessRequest := true
default WriteStreamRequest := false

此策略启用 exec (ExecProcessRequest)和 log (ReadStreamRequest) API。根据您的需要，调整 true 或 false 值以进一步自定义策略。

运行以下命令，将 policy.rego 文件转换为 Base64 编码的字符串：
```
$ base64 -w0 policy.rego
```
将输出保存到 yaml 文件中。

将 Base64 编码的策略添加到 my-pod.yaml pod 规格文件中：

apiVersion: v1
kind: Pod
metadata:
  name: <pod_name>
  annotations:
    io.katacontainers.config.agent.policy: <base64_encoded_policy>
spec:
  runtimeClassName: kata-remote
  containers:
  - name: <container_name>
    image: registry.access.redhat.com/ubi9/ubi:latest
    command:
    - sleep
    - "36000"
    securityContext:
      privileged: false
      seccompProfile:
        type: RuntimeDefault

运行以下命令来应用 pod 清单：
```
$ oc apply -f my-pod.yaml
```

5.3.8. 创建 KataConfig 自定义资源

您必须创建 KataConfig 自定义资源(CR)来作为 worker 节点上的运行时类安装 kata-remote。

创建 KataConfig CR 会触发 OpenShift 沙盒容器 Operator 来执行以下操作：

使用默认配置创建一个名为 kata-remote 的 RuntimeClass CR。这可让用户在 RuntimeClassName 字段中引用 CR 将工作负载配置为使用 kata-remote 作为运行时。此 CR 也指定运行时的资源开销。

OpenShift 沙盒容器将 kata-remote 安装为集群上的辅助可选运行时，而不是主运行时。

重要

创建 KataConfig CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下：

带有更多 worker 节点的大型 OpenShift Container Platform 部署。
激活 BIOS 和 Diagnostics 实用程序。
在硬盘而不是 SSD 上部署。
在物理节点上部署，如裸机，而不是在虚拟节点上部署。
CPU 和网络较慢。

先决条件

您可以使用具有 cluster-admin 角色的用户访问集群。

流程

根据以下示例创建 example-kataconfig.yaml 清单文件：

apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig
spec:
  enablePeerPods: true
  logLevel: info
#  kataConfigPoolSelector:
#    matchLabels:
#      <label_key>: '<label_value>' 1

1: 可选：如果您应用了节点标签在特定节点上安装 kata-remote，请指定键和值，例如 osc: 'true'。

运行以下命令来创建 KataConfig CR：
```
$ oc apply -f example-kataconfig.yaml
```
新的 KataConfig CR 被创建，并在 worker 节点上作为运行时类安装 kata-remote。
在验证安装前，等待 kata-remote 安装完成，以及 worker 节点重新引导。
运行以下命令监控安装进度：
```
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
```
安装 kataNodes 下所有 worker 的状态并且条件 InProgress 为 False 时，而不指定原因，则会在集群中安装 kata-remote。

运行以下命令验证守护进程集：

$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds

运行以下命令验证运行时类：

$ oc get runtimeclass

输出示例

NAME             HANDLER          AGE
kata             kata             152m
kata-remote      kata-remote      152m

验证 pod 虚拟机镜像

在集群中安装 kata-remote 后，OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像，用于创建对等 pod。此过程可能需要很长时间，因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。

流程

获取您为对等 pod 创建的配置映射：

$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml

检查 YAML 文件 的状态 小节。
如果 PODVM_IMAGE_NAME 参数被填充，则 pod 虚拟机镜像已被成功创建。

故障排除

运行以下命令来检索事件日志：

$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

运行以下命令来检索作业日志：

$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

如果您无法解决这个问题，请提交红帽支持问题单并附加这两个日志的输出。

5.3.9. 配置工作负载对象

您必须通过将 kata-remote 设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象：

Pod 对象
ReplicaSet 对象
ReplicationController 对象
StatefulSet 对象
Deployment 对象
deploymentConfig 对象

重要

不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。

先决条件

您已创建了 KataConfig 自定义资源(CR)。

流程

将 spec.runtimeClassName: kata-remote 添加到每个 pod 模板工作负载对象的清单中，如下例所示：
```
apiVersion: v1
kind: <object>
# ...
spec:
  runtimeClassName: kata-remote
# ...
```
OpenShift Container Platform 创建工作负载对象并开始调度它。

验证

检查 pod 模板对象的 spec.runtimeClassName 字段。如果值为 kata-remote，则工作负载在 OpenShift 沙盒容器上运行，使用对等 pod。

返回顶部

5.3. 使用命令行部署 OpenShift 沙盒容器

5.3.1. 安装 OpenShift 沙盒容器 Operator

5.3.2. 为 Google Cloud 启用端口 15150

5.3.3. 创建对等 pod secret

5.3.4. 创建对等 pod 配置映射

5.3.5. 创建对等 pod 虚拟机镜像

5.3.6. 创建对等 pod 虚拟机镜像配置映射

5.3.7. 自定义 Kata 代理策略

5.3.8. 创建 KataConfig 自定义资源

验证 pod 虚拟机镜像

5.3.9. 配置工作负载对象

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links