用户指南
在 OpenShift Container Platform 中部署沙盒容器
摘要
前言
对红帽文档提供反馈
您可以通过在 Jira 中提交 Create Issue 表单来提供反馈或报告错误。Jira 问题将在 Red Hat Hybrid Cloud Infrastructure Jira 项目中创建,您可以在其中跟踪您反馈的进度。
- 确保您已登录到 Jira。如果您没有 JIRA 帐户,您必须创建一个 Red Hat Jira account。
- 启动 Create Issue 表单。
完成 Summary、Description 和 Reporter 字段。
在 Description 字段中,包含文档 URL、章节号以及问题的详细描述。
- 点 Create。
第 1 章 关于 OpenShift 沙盒容器
用于 OpenShift Container Platform 的 OpenShift 沙盒容器将 Kata 容器集成为可选运行时,通过在轻量级虚拟机中运行容器化应用程序来提供增强的安全性和隔离功能。此集成为敏感工作负载提供了一个更安全的运行时环境,而无需对现有 OpenShift 工作流进行大量更改。此运行时支持专用虚拟机(VM)中的容器,从而改进了工作负载隔离。
1.1. 功能
OpenShift 沙盒容器提供以下功能:
- 运行特权或不受信任的工作负载
您可以安全地运行需要特定特权的工作负载,而无需通过运行特权容器来破坏集群节点的风险。需要特殊权限的工作负载包括:
- 需要内核的特殊功能的工作负载,除了标准容器运行时(如 CRI-O)授予的默认功能外,例如访问低级别网络功能。
- 需要提高 root 特权的工作负载,例如访问特定物理设备。使用 OpenShift 沙盒容器时,只能将特定的设备传递给虚拟机(VM),确保工作负载无法访问或错误配置系统的其余部分。
用于安装或使用
set-uid
root 二进制文件的工作负载。这些二进制文件授予特殊权限,因此可能会造成安全风险。使用 OpenShift 沙盒容器时,对虚拟机有额外的权限,不授予对集群节点的特殊访问权限。有些工作负载需要专门用于配置集群节点的权限。此类工作负载应该仍然使用特权容器,因为在虚拟机上运行可能会阻止它们正常工作。
- 确保敏感工作负载的隔离
- Red Hat OpenShift Container Platform 的 OpenShift 沙盒容器将 Kata 容器集成为可选运行时,通过在轻量级虚拟机中运行容器化应用程序来提供增强的安全性和隔离功能。此集成为敏感工作负载提供了一个更安全的运行时环境,而无需对现有 OpenShift 工作流进行大量更改。此运行时支持专用虚拟机(VM)中的容器,从而改进了工作负载隔离。
- 确保每个工作负载的内核隔离
-
您可以运行需要自定义内核调整(如
sysctl
、调度程序更改或缓存调整)以及创建自定义内核模块(如树外
或特殊参数)的工作负载。 - 在租户间共享相同的工作负载
-
您可以从共享同一 OpenShift Container Platform 集群的不同机构运行支持许多用户(租户)的工作负载。系统还支持从多个供应商运行第三方工作负载,如容器网络功能(CNF)和企业应用程序。例如,第三方 CNF 可能不希望其自定义设置与数据包调整或由其他应用程序设置的
sysctl
变量干扰。在完全隔离的内核内运行有助于防止"邻居噪音"配置问题。 - 确保正确隔离和沙盒测试软件
-
您可以使用已知漏洞运行容器化工作负载,或处理现有应用程序中的问题。通过这种隔离,管理员可以为开发人员提供对 pod 的管理控制,这在开发人员想要测试或验证管理员通常授予的配置时很有用。例如,管理员可以安全地将内核数据包过滤(eBPF)委派给开发人员。eBPF 需要
CAP_ADMIN
或CAP_BPF
特权,因此不允许在标准 CRI-O 配置下,因为这会授予容器主机 worker 节点上的每个进程的访问权限。同样,管理员可以授予对SystemTap
等入侵工具的访问权限,或者支持在开发期间加载自定义内核模块。 - 确保通过虚拟机边界的默认资源控制
- 默认情况下,OpenShift 沙盒容器以强大和安全的方式管理 CPU、内存、存储和网络等资源。由于 OpenShift 沙盒容器部署到虚拟机上,因此额外的隔离层和安全性可为资源提供更精细的访问控制。例如,错误容器将无法为虚拟机分配超过可用内存更多的内存。相反,需要专用访问网卡或磁盘的容器可以完全控制该设备,而无需访问其他设备。
1.2. 与 OpenShift Container Platform 的兼容性
OpenShift Container Platform 平台所需的功能由两个主要组件支持:
- Kata 运行时:包括 Red Hat Enterprise Linux CoreOS (RHCOS)和每个 OpenShift Container Platform 发行版本的 更新。
-
OpenShift 沙盒容器 Operator:使用 Web 控制台或 OpenShift CLI (
oc
)安装 Operator。
OpenShift 沙盒容器 Operator 是一个 Rolling Stream Operator,这意味着最新版本是唯一受支持的版本。它可用于所有当前支持的 OpenShift Container Platform 版本。如需更多信息,请参阅 OpenShift Container Platform 生命周期政策 以了解更多详细信息。
Operator 依赖于 RHCOS 主机及其在其中运行的环境的功能。
您必须在 worker 节点上安装 Red Hat Enterprise Linux CoreOS (RHCOS)。不支持 RHEL 节点。
OpenShift 沙盒容器和 OpenShift Container Platform 的以下兼容性列表用于标识兼容的功能和环境。
架构 | OpenShift Container Platform 版本 |
---|---|
x86_64 | 4.8 或更高版本 |
s390x | 4.14 或更高版本 |
部署 Kata 容器运行时的方法有两种:
- 裸机
- 对等 pod
在公共云中部署 OpenShift 沙盒容器的对等 pod 技术在 OpenShift 沙盒容器 1.5 和 OpenShift Container Platform 4.14 中作为开发者预览提供。
随着 OpenShift 沙盒容器 1.7 的发布,Operator 需要 OpenShift Container Platform 版本 4.15 或更高版本。
功能 | 部署方法 | OpenShift Container Platform 4.15 | OpenShift Container Platform 4.16 |
---|---|---|---|
机密容器 | 裸机 | ||
对等 pod | 技术预览 | 技术预览 [1] | |
GPU 支持 [2] | 裸机 | ||
对等 pod | 开发者预览 | 开发者预览 |
- 自 OpenShift 沙盒容器 1.7.0 起,提供了机密容器技术预览。
- IBM Z 上不提供 GPU 功能。
平台 | GPU | 机密容器 |
---|---|---|
AWS Cloud Computing Services | 开发者预览 | |
Microsoft Azure Cloud Computing Services | 开发者预览 | 技术预览 [1] |
- 自 OpenShift 沙盒容器 1.7.0 起,提供了机密容器技术预览。
其他资源
1.3. 节点资格检查
您可以通过运行节点资格检查来验证您的裸机集群节点是否支持 OpenShift 沙盒容器。节点不合格的最常见原因是没有虚拟化支持。如果您在不符合节点上运行沙盒工作负载,则会出现错误。
高级工作流
- 安装 Node Feature Discovery Operator。
-
创建
NodeFeatureDiscovery
自定义资源(CR)。 -
在创建
Kataconfig
CR 时启用节点资格检查。您可以在所有 worker 节点或所选节点上运行节点资格检查。
1.4. 常见术语
以下是整个文档中所使用的术语:
- Sandbox
沙盒(sandbox)是一种隔离的环境,程序可以在其中运行。在沙盒中,您可以运行未经测试或不受信任的程序,而不影响到主机机器或操作系统。
在 OpenShift 沙盒容器环境中,沙盒通过使用虚拟化在不同的内核中运行工作负载来实现,从而增强了对在同一主机上运行的多个工作负载之间的交互的控制。
- Pod
pod 是继承自 Kubernetes 和 OpenShift Container Platform 的构造。它代表了可以部署容器的资源。容器在 pod 内运行,pod 用于指定可以在多个容器之间共享的资源。
在 OpenShift 沙盒容器上下文中,pod 被实施为一个虚拟机。多个容器可以在同一虚拟机上在同一 pod 中运行。
- OpenShift 沙盒容器 Operator
- OpenShift 沙盒容器 Operator 管理集群上沙盒容器的生命周期。您可以使用 OpenShift 沙盒容器 Operator 来执行任务,如安装和删除沙盒容器、软件更新和状态监控。
- Kata 容器
- Kata 容器是一个上游核心项目,用于构建 OpenShift 沙盒容器。OpenShift 沙盒容器将 Kata 容器与 OpenShift Container Platform 集成。
- KataConfig
-
KataConfig
对象代表沙盒容器的配置。它们存储有关集群状态的信息,如部署软件的节点。 - 运行时类
-
RuntimeClass
对象用于描述可以使用哪个运行时来运行给定工作负载。OpenShift 沙盒容器 Operator 安装和部署了名为kata
的运行时类。运行时类包含有关运行时的信息,用于描述运行时需要运行的资源,如 pod 开销。
- 对等(peer)pod
OpenShift 沙盒容器中的对等 pod 扩展标准 pod 的概念。与标准沙盒容器不同,在 worker 节点本身上创建虚拟机,在对等 pod 中,虚拟机会使用任何支持的虚拟机监控程序或云供应商 API 通过远程 hypervisor 创建。
对等 pod 作为 worker 节点上的常规 pod,其对应的虚拟机在其他位置运行。虚拟机的远程位置对用户是透明的,并由 pod 规格中运行时类指定。对等 pod 设计对嵌套虚拟化的需求。
- IBM 安全执行
- Linux 的 IBM Secure Execution 是 IBM z15® 和 LinuxONE III 中引入的高级安全功能。此功能扩展了由广泛加密提供的保护。IBM Secure Execution 可在静态、传输和使用中保护数据。它启用了工作负载安全部署并确保整个生命周期的数据保护。如需更多信息,请参阅 Linux 的 IBM 安全执行。
- 机密容器
机密容器通过验证您的工作负载是否在受信任的执行环境(TEE)中运行来保护容器和数据。您可以部署此功能,以保护大数据分析和机器学习推测的隐私。
trustee 是机密容器的组件。trustee 是一个 attestation 服务,用于验证您要运行工作负载或计划发送机密信息的位置的可信度。信任者包括部署在可信端的组件,用于验证远程工作负载是否在可信执行环境(TEE)中运行。信任者非常灵活,可在多种不同的配置中部署,以支持各种应用程序和硬件平台。
- 机密计算(testation) Operator
- 机密计算(testation) Operator 管理机密容器的安装、生命周期和配置。
1.5. OpenShift 沙盒容器 Operator
OpenShift 沙盒容器 Operator 封装了来自 Kata 容器的所有组件。它管理安装、生命周期和配置任务。
OpenShift 沙盒容器 Operator 以 Operator 捆绑包格式 打包为两个容器镜像:
- 捆绑包镜像包含元数据,这是使 operator OLM 就绪所必需的。
-
第二个容器镜像包含监控和管理
KataConfig
资源的实际控制器。
OpenShift 沙盒容器 Operator 基于 Red Hat Enterprise Linux CoreOS (RHCOS)扩展概念。RHCOS 扩展是安装可选 OpenShift Container Platform 软件的机制。OpenShift 沙盒容器 Operator 使用此机制在集群中部署沙盒容器。
沙盒容器 RHCOS 扩展包含用于 Kata、QEMU 及其依赖项的 RPM。您可以使用 Machine Config Operator 提供的 MachineConfig
资源启用它们。
其他资源
1.6. 关于机密容器
机密容器通过利用 受信任的执行环境提供机密计算环境来保护容器和数据。
Microsoft Azure Cloud Computing Services、IBM Z® 和 IBM® LinuxONE 上的机密容器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
您可以使用 Red Hat Trusted Artifact Signer 等工具为容器镜像签名。然后,您可以创建容器镜像签名验证策略。
Trustee Operator 验证签名,确保环境中仅部署可信和经过身份验证的容器镜像。
如需更多信息,请参阅 浏览 OpenShift 机密容器解决方案。
1.7. OpenShift Virtualization
您可以使用 OpenShift Virtualization 在集群中部署 OpenShift 沙盒容器。
要同时运行 OpenShift Virtualization 和 OpenShift 沙盒容器,您的虚拟机必须可实时迁移,以便它们不会阻止节点重启。详情请参阅 OpenShift Virtualization 文档中的关于实时迁移 的内容。
1.8. 块卷支持
OpenShift Container Platform 可以静态置备原始块卷。这些卷没有文件系统。对于可以直接写入磁盘或者实现其自己的存储服务的应用程序来说,使用它可以获得性能优势。
您可以将本地块设备用作 OpenShift 沙盒容器的持久性卷(PV)存储。可以使用 Local Storage Operator (LSO)置备此块设备。
默认情况下,OpenShift Container Platform 中不会安装 Local Storage Operator。有关安装说明 ,请参阅安装 Local Storage Operator。
您可以通过在 PV 规格中指定 volumeMode: Block
来为 OpenShift 沙盒容器置备原始块卷。
块卷示例
apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
name: "local-disks"
namespace: "openshift-local-storage"
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- worker-0
storageClassDevices:
- storageClassName: "local-sc"
forceWipeDevicesAndDestroyAllData: false
volumeMode: Block 1
devicePaths:
- /path/to/device 2
Copy to clipboardCopied1.9. FIPS 合规性
OpenShift Container Platform 是为联邦信息处理标准(FIPS) 140-2 和 140-3 设计的。当以 FIPS 模式引导时运行 Red Hat Enterprise Linux (RHEL)或 Red Hat Enterprise Linux CoreOS (RHCOS)时,OpenShift Container Platform 核心组件使用提交到 NIST for FIPS 140-2/140-3 Validation 的
RHEL 加密库。
有关 NIST 验证程序的更多信息,请参阅加密模块验证程序。有关为验证提交的 RHEL 加密库的单独版本的最新 NIST 状态,请参阅 Compliance Activities 和 Government Standards。
OpenShift 沙盒容器可以在启用了 FIPS 的集群中使用。
在 FIPS 模式下运行时,OpenShift 沙盒容器组件、虚拟机和虚拟机镜像会根据 FIPS 进行调整。
OpenShift 沙盒容器的 FIPS 合规性只适用于 kata
运行时类。对等 pod 运行时类 kata-remote
尚未被完全支持,且还没有为 FIPS 合规性进行测试。
FIPS 合规性是高安全性环境中所需的最重要的组件之一,可确保节点上只允许使用支持的加密技术。
只有在 x86_64
架构中的 OpenShift Container Platform 部署支持 FIPS 验证的/Modules in Process 加密库。
要了解红帽对 OpenShift Container Platform 合规框架的观点,请参阅 OpenShift 安全性指南手册中的“风险管理和法规就绪状态”一章。
第 2 章 在裸机上部署 OpenShift 沙盒容器
您可以使用 worker 节点上安装的 Red Hat Enterprise Linux CoreOS (RHCOS)在内部裸机集群中部署 OpenShift 沙盒容器。
- 不支持 RHEL 节点。
- 不支持嵌套虚拟化。
您可以使用任何安装方法,包括 用户置备的、安装程序置备的 或 Assisted Installer 来部署集群。
您还可以在 Amazon Web Services (AWS)裸机实例上安装 OpenShift 沙盒容器。不支持由其他云提供商提供的裸机实例。
集群要求
- 您已在要安装 OpenShift 沙盒容器 Operator 的集群中安装 Red Hat OpenShift Container Platform 4.14 或更高版本。
- 您的集群至少有一个 worker 节点。
有关在裸机上安装 OpenShift Container Platform 的详情,请参考 在裸机上安装。
2.1. OpenShift 沙盒容器资源要求
您必须确保集群有足够的资源。
OpenShift 沙盒容器允许用户在沙盒运行时 (Kata) 中的 OpenShift Container Platform 集群中运行工作负载。每个 pod 由一个虚拟机(VM)表示。每个虚拟机都在 QEMU 进程中运行,并托管一个 kata-agent
进程,它充当管理容器工作负载的监管程序,以及这些容器中运行的进程。两个额外的进程会增加开销:
-
containerd-shim-kata-v2
用于与 pod 通信。 -
virtiofsd
代表客户机处理主机文件系统访问。
每个虚拟机都配置有默认内存量。对于明确请求内存的容器,额外的内存会被热插到虚拟机中。
在没有内存资源的情况下运行的容器会消耗可用内存,直到虚拟机使用的总内存达到默认分配。客户机及其 I/O 缓冲区也消耗内存。
如果容器被授予特定数量的内存,那么该内存会在容器启动前热插到虚拟机中。
当指定内存限制时,如果消耗的内存超过限制,工作负载将被终止。如果没有指定内存限制,则虚拟机中运行的内核可能会耗尽内存。如果内核内存不足,它可能会终止虚拟机上的其他进程。
默认内存大小
下表列出了资源分配的一些默认值。
资源 | value |
---|---|
默认为虚拟机分配的内存 | 2Gi |
启动时客户机 Linux 内核内存使用 | ~110Mi |
QEMU 进程使用的内存(虚拟机内存除外) | ~30Mi |
| ~10Mi |
| ~20Mi |
在 Fedora 上运行 | ~300Mi* [1] |
文件缓冲区会出现并在多个位置考虑:
- 在客户机中它被显示为文件缓冲缓存。
-
在映射允许的用户空间文件 I/O 操作的
virtiofsd
守护进程中。 - 在 QEMU 进程中作为客户机内存。
内存使用率指标正确考虑内存用量总量,该指标仅计算该内存一次。
Pod 开销描述了节点上 pod 使用的系统资源量。您可以使用 oc describe runtimeclass kata
获取 Kata 运行时的当前 pod 开销,如下所示。
Example
$ oc describe runtimeclass kata
Copy to clipboardCopied输出示例
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
Copy to clipboardCopied
您可以通过更改 RuntimeClass
的 spec.overhead
字段来更改 pod 开销。例如,如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存,您可以更改 RuntimeClass
开销来满足您的需要。
红帽支持指定的默认开销值。不支持更改默认开销值,这可能会导致技术问题。
在客户机中执行任何类型的文件系统 I/O 时,将在客户机内核中分配文件缓冲区。文件缓冲区也在主机上的 QEMU 进程以及 virtiofsd
进程中映射。
例如,如果您在客户机中使用 300Mi 文件缓冲区缓存,QEMU 和 virtiofsd
都显示使用 300Mi 额外内存。但是,所有三种情况下都使用相同的内存。因此,内存使用总量仅为 300Mi,映射在三个不同的位置。报告内存使用率指标时,会正确计算。
2.2. 使用 Web 控制台部署 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台在裸机上部署 OpenShift 沙盒容器,以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:安装 Node Feature Discovery (NFD) Operator 来配置节点资格检查。如需更多信息,请参阅 节点资格检查和 NFD Operator 文档。
- 可选:自定义 Kata 代理策略。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
2.2.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
- 在 Web 控制台中,导航到 Operators → OperatorHub。
-
在 Filter by keyword 字段中,输入
OpenShift sandboxed containers
。 - 选择 OpenShift 沙盒容器 Operator 标题并点 Install。
- 在 Install Operator 页面中,从可用 Update Channel 选项列表中选择 stable。
验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在
openshift-sandboxed-containers-operator
命名空间中安装 Operator。如果此命名空间尚不存在,则会自动创建。注意尝试在
openshift-sandboxed-containers-operator
以外的命名空间中安装 OpenShift 沙盒容器 Operator 会导致安装失败。- 验证是否为 Approval Strategy 选择了 Automatic。Automatic 是默认值,当有新的 z-stream 发行版本可用时,自动启用对 OpenShift 沙盒容器的自动更新。
- 点 Install。
- 导航到 Operators → Installed Operators,以验证是否已安装 Operator。
2.2.2. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
2.2.3. 创建 KataConfig 自定义资源
您必须创建 KataConfig
自定义资源(CR),以便在 worker 节点上安装 kata
作为 RuntimeClass
。
Kata
运行时类默认安装在所有 worker 节点上。如果要在特定节点上安装 kata
,您可以向这些节点添加标签,然后在 KataConfig
CR 中定义该标签。
OpenShift 沙盒容器将 kata
作为集群中的辅助 可选运行时安装,而不是作为主要运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。以下因素可能会增加重启时间:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 选择 OpenShift 沙盒容器 Operator。
- 在 KataConfig 选项卡中,点 Create KataConfig。
输入以下详情:
-
Name: 可选:默认名称为
example-kataconfig
。 -
标签 :可选:输入任何相关的、识别到
KataConfig
资源的属性。每个标签代表一个键值对。 - checkNodeEligibility: 可选:选择使用 Node Feature Discovery Operator (NFD)来检测节点资格。
kataConfigPoolSelector.可选: 要在所选节点上安装
kata
,请在所选节点上为标签添加匹配表达式:- 展开 kataConfigPoolSelector 区域。
- 在 kataConfigPoolSelector 区域中,展开 matchExpressions。这是标签选择器要求列表。
- 点 Add matchExpressions。
- 在 Key 字段中,输入选择器应用到的标签键。
-
在 Operator 字段中,输入键与标签值的关系。有效的运算符为
In
、NotIn
、Exists
和DoesNotExist
。 - 展开 Values 区域,然后点 Add value。
-
在 Value 字段中,为 key 标签值输入
true
或false
。
-
loglevel :定义使用
kata
运行时类为节点检索的日志数据级别。
-
Name: 可选:默认名称为
点 Create。
KataConfig
CR 会被创建并在 worker 节点上安装kata
运行时类。在验证安装前,等待
kata
安装完成,以及 worker 节点重新引导。
验证
-
在 KataConfig 选项卡中,点
KataConfig
CR 查看其详情。 点 YAML 选项卡查看
status
小节。status
小节包含conditions
和kataNodes
键。status.kataNodes
的值是一个节点数组,每个节点都列出处于kata
安装的特定状态的节点。每次有更新时都会出现一条消息。点 Reload 以刷新 YAML。
当
status.kataNodes
数组中的所有 worker 都会显示installed
和conditions.InProgress: False
时,没有指定的原因,则会在集群中安装kata
。
其他资源
2.2.4. 配置工作负载对象
您必须将 kata
设置为以下 pod 模板的对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
- 在 OpenShift Container Platform Web 控制台中,导航到 Workloads → workload type,如 Pods。
- 在工作负载类型页面中,点对象查看其详情。
- 点 YAML 标签。
将
spec.runtimeClassName: kata
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata
,则工作负载在 OpenShift 沙盒容器中运行,使用对等 pod。
2.3. 使用命令行部署 OpenShift 沙盒容器
您可以使用命令行界面(CLI)在裸机上部署 OpenShift 沙盒容器,以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
安装 Operator 后,您可以配置以下选项:
- 配置块存储设备。
安装 Node Feature Discovery (NFD) Operator 来配置节点资格检查。如需更多信息,请参阅 节点资格检查和 NFD Operator 文档。
-
创建
NodeFeatureDiscovery
自定义资源。
-
创建
- 可选:自定义 Kata 代理策略。
-
创建
KataConfig
自定义资源。 - 可选:修改 pod 开销。
- 配置 OpenShift 沙盒容器工作负载对象。
2.3.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
osc-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
运行以下命令创建命名空间:
Copy to clipboardCopied$ oc apply -f osc-namespace.yaml
创建
osc-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f osc-operatorgroup.yaml
创建
osc-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f osc-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n openshift-sandboxed-containers-operator
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedNAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
2.3.2. 可选配置
您可在安装 OpenShift 沙盒容器 Operator 后配置以下选项。
2.3.2.1. 置备本地块卷
您可以在 OpenShift 沙盒容器中使用本地块卷。您必须首先使用 Local Storage Operator (LSO)置备本地块卷。然后,您必须使用本地块卷启用节点来运行 OpenShift 沙盒容器工作负载。
您可以使用 Local Storage Operator (LSO)为 OpenShift 沙盒容器置备本地块卷。本地卷置备程序会在定义的资源中指定的路径上查找任何块设备。
先决条件
- 已安装 Local Storage Operator。
您有一个满足以下条件的本地磁盘:
- 它附加到一个节点。
- 它尚未挂载。
- 它不包含分区。
流程
创建本地卷资源。此资源必须定义本地卷的节点和路径。
注意不要在同一设备中使用不同的存储类名称。这样做可创建多个持久性卷(PV)。
例如:Block
Copy to clipboardCopiedapiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" 1 spec: nodeSelector: 2 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-136-143 - ip-10-0-140-255 - ip-10-0-144-180 storageClassDevices: - storageClassName: "local-sc" 3 forceWipeDevicesAndDestroyAllData: false 4 volumeMode: Block devicePaths: 5 - /path/to/device 6
- 1
- 安装了 Local Storage Operator 的命名空间。
- 2
- 可选:包含附加了本地存储卷的节点列表的节点选择器。本例使用从
oc get node
获取的节点主机名。如果没有定义值,则 Local Storage Operator 会尝试在所有可用节点上查找匹配的磁盘。 - 3
- 创建持久性卷对象时使用的存储类的名称。
- 4
- 此设置定义是否调用
wipefs
,它会删除分区表签名(魔法字符串),使磁盘准备好用于 Local Storage Operator 置备。除了签名外,没有其它数据会被清除。默认为 "false" (不调用wipefs
)。当在需要重新使用的磁盘中,将forceWipeDevicesAndDestroyAllData
设置为 "true" 很有用。在这些情况下,将此字段设置为 true 可消除管理员手动擦除磁盘的需要。 - 5
- 包含要从中选择的本地存储设备列表的路径。在启用带有本地块设备的节点来运行 OpenShift 沙盒容器工作负载时,您必须使用此路径。
- 6
- 使用到
LocalVolume
资源by-id
的文件路径替换这个值,如/dev/disk/by-id/wwn
。当置备程序已被成功部署时,会为这些本地磁盘创建 PV。
在 OpenShift Container Platform 集群中创建本地卷资源。指定您刚才创建的文件:
Copy to clipboardCopied$ oc apply -f <local-volume>.yaml
验证置备程序是否已创建并创建了相应的守护进程集:
Copy to clipboardCopied$ oc get all -n openshift-local-storage
输出示例
Copy to clipboardCopiedNAME READY STATUS RESTARTS AGE pod/diskmaker-manager-9wzms 1/1 Running 0 5m43s pod/diskmaker-manager-jgvjp 1/1 Running 0 5m43s pod/diskmaker-manager-tbdsj 1/1 Running 0 5m43s pod/local-storage-operator-7db4bd9f79-t6k87 1/1 Running 0 14m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/local-storage-operator-metrics ClusterIP 172.30.135.36 <none> 8383/TCP,8686/TCP 14m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/diskmaker-manager 3 3 3 3 3 <none> 5m43s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/local-storage-operator 1/1 1 1 14m NAME DESIRED CURRENT READY AGE replicaset.apps/local-storage-operator-7db4bd9f79 1 1 1 14m
请注意
所需的
和当前的
守护进程设定进程数。所需的
数量为0
表示标签选择器无效。验证持久性卷是否已创建:
Copy to clipboardCopied$ oc get pv
输出示例
Copy to clipboardCopiedNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available local-sc 88m local-pv-2ef7cd2a 100Gi RWO Delete Available local-sc 82m local-pv-3fa1c73 100Gi RWO Delete Available local-sc 48m
编辑 LocalVolume
对象不会更改现有的持久性卷,因为这样做可能会导致破坏性操作。
2.3.2.2. 启用节点使用本地块设备
您可以使用本地块设备配置节点,以便在定义的卷资源中指定的路径上运行 OpenShift 沙盒容器工作负载。
先决条件
- 已使用 Local Storage Operator (LSO)置备块设备。
流程
运行以下命令,使用本地块设备启用每个节点来运行 OpenShift 沙盒容器工作负载:
Copy to clipboardCopied$ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
在创建本地存储资源时,
/path/to/device
必须与您定义的路径相同。输出示例
Copy to clipboardCopiedsystem_u:object_r:container_file_t:s0 /host/path/to/device
2.3.2.3. 创建 NodeFeatureDiscovery 自定义资源
您可以创建一个 NodeFeatureDiscovery
自定义资源(CR)来定义 Node Feature Discovery (NFD) Operator 检查的配置参数,以确定 worker 节点可以支持 OpenShift 沙盒容器。
要仅在您了解的所选 worker 节点上安装 kata
运行时,请将 feature.node.kubernetes.io/runtime.kata=true
标签应用到所选节点,并在 KataConfig
CR 中设置 checkNodeEligibility: true
。
要在所有 worker 节点上安装 kata
运行时,请在 KataConfig
CR 中设置 checkNodeEligibility: false
。
在这两种情况下,您不需要创建 NodeFeatureDiscovery
CR。如果您确定节点有资格运行 OpenShift 沙盒容器,则应仅应用 feature.node.kubernetes.io/runtime.kata=true
标签。
以下流程将 feature.node.kubernetes.io/runtime.kata=true
标签应用到所有有资格的节点,并将 KataConfig
资源配置为检查节点资格。
先决条件
- 已安装 NFD Operator。
流程
根据以下示例创建
nfd.yaml
清单文件:
Copy to clipboardCopiedapiVersion: nfd.openshift.io/v1 kind: NodeFeatureDiscovery metadata: name: nfd-kata namespace: openshift-nfd spec: workerConfig: configData: | sources: custom: - name: "feature.node.kubernetes.io/runtime.kata" matchOn: - cpuId: ["SSE4", "VMX"] loadedKMod: ["kvm", "kvm_intel"] - cpuId: ["SSE4", "SVM"] loadedKMod: ["kvm", "kvm_amd"] # ...
创建
NodeFeatureDiscovery
CR:
Copy to clipboardCopied$ oc create -f nfd.yaml
NodeFeatureDiscovery
CR 将feature.node.kubernetes.io/runtime.kata=true
标签应用到所有合格的 worker 节点。
根据以下示例创建
kata-config.yaml
清单文件:
Copy to clipboardCopiedapiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
创建
KataConfig
CR:
Copy to clipboardCopied$ oc create -f kata-config.yaml
验证
验证集群中是否应用了正确的标签:
Copy to clipboardCopied$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
输出示例
Copy to clipboardCopiedNAME STATUS ROLES AGE VERSION compute-3.example.com Ready worker 4h38m v1.25.0 compute-2.example.com Ready worker 4h35m v1.25.0
2.3.3. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
2.3.4. 创建 KataConfig 自定义资源
您必须创建 KataConfig
自定义资源(CR)以在 worker 节点上作为运行时类安装 kata
。
创建 KataConfig
CR 会触发 OpenShift 沙盒容器 Operator 来执行以下操作:
-
在 RHCOS 节点上安装所需的 RHCOS 扩展,如 QEMU 和
kata-containers
。 - 确保 CRI-O 运行时配置了正确的运行时处理程序。
-
使用默认配置创建一个名为
kata
的RuntimeClass
CR。这可让用户在RuntimeClassName
字段中引用 CR 将工作负载配置为使用kata
作为运行时。此 CR 也指定运行时的资源开销。
OpenShift 沙盒容器将 kata
作为集群中的辅助 可选运行时安装,而不是作为主要运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
根据以下示例创建
example-kataconfig.yaml
清单文件:
Copy to clipboardCopiedapiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: false 1 logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 2
运行以下命令来创建
KataConfig
CR:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 会被创建,并在 worker 节点上作为运行时类安装kata
。在验证安装前,等待
kata
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
当安装
kataNodes
下的所有 worker 的状态并且条件InProgress
为False
时,如果没有指定原因,则会在集群中安装kata
。
2.3.5. 修改 pod 开销
Pod 开销描述了节点上 pod 使用的系统资源量。您可以通过更改 RuntimeClass
自定义资源的 spec.overhead
字段来修改 pod 开销。例如,如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存,您可以更改 RuntimeClass
开销来满足您的需要。
在客户机中执行任何类型的文件系统 I/O 时,将在客户机内核中分配文件缓冲区。文件缓冲区也在主机上的 QEMU 进程以及 virtiofsd
进程中映射。
例如,如果您在客户机中使用 300Mi 文件缓冲区缓存,QEMU 和 virtiofsd
都显示使用 300Mi 额外内存。但是,所有三种情况下都使用相同的内存。因此,内存使用总量仅为 300Mi,映射在三个不同的位置。报告内存使用率指标时,会正确计算。
红帽支持默认值。不支持更改默认开销值,这可能会导致技术问题。
流程
运行以下命令来获取
RuntimeClass
对象:
Copy to clipboardCopied$ oc describe runtimeclass kata
更新
overhead.podFixed.memory
和cpu
值,并将文件保存为runtimeclass.yaml
:
Copy to clipboardCopiedkind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
运行以下命令来应用更改:
Copy to clipboardCopied$ oc apply -f runtimeclass.yaml
2.3.6. 配置工作负载对象
您必须将 kata
设置为以下 pod 模板的对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
将
spec.runtimeClassName: kata
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata
,则工作负载在 OpenShift 沙盒容器中运行,使用对等 pod。
第 3 章 在 AWS 上部署 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台或命令行界面(CLI)在 AWS Cloud Computing Services 上部署 OpenShift 沙盒容器。
OpenShift 沙盒容器部署对等 pod。对等 pod 设计对嵌套虚拟化的需求。如需更多信息,请参阅 对等 pod 和 Peer pod 技术深入了解。
集群要求
- 您已在要安装 OpenShift 沙盒容器 Operator 的集群中安装 Red Hat OpenShift Container Platform 4.14 或更高版本。
- 您的集群至少有一个 worker 节点。
有关在 AWS 云计算服务上安装 OpenShift Container Platform 的详情,请参考在 AWS 上安装。
3.1. 对等 pod 资源要求
您必须确保集群有足够的资源。
对等 pod 虚拟机(VM)需要位于两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2
)、remote-hypervisor 资源(cloud-api-adaptor
),以及 worker 节点和对等 pod 虚拟机之间的隧道设置。 - 云实例。这是在云中运行的实际对等 pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由 RuntimeClass (kata-remote
)定义中包含的 pod 开销 处理,用于创建对等 pod。
在云中运行的对等 pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peer-pods-cm
配置映射中的 PEERPODS_LIMIT_PER_NODE
属性设置。
扩展资源名为 kata.peerpods.io/vm
,并允许 Kubernetes 调度程序处理容量跟踪和核算。
在安装 OpenShift 沙盒容器 Operator 后,您可以根据环境要求编辑每个节点的限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm
添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度对等 pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 会检查 pod 是否有预期的
RuntimeClassName
值,在TARGET_RUNTIME_CLASS
环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIME_CLASS
的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName
值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources
字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm
)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm
用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除 OpenShift Container Platform 中的特定系统命名空间。如果在这些系统命名空间中创建了对等 pod,则使用 Kubernetes 扩展资源的资源核算不起作用,除非 pod spec 包含扩展资源。
作为最佳实践,定义集群范围的策略,仅允许在特定命名空间中创建对等 pod。
3.2. 使用 Web 控制台部署 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台在 AWS 上部署 OpenShift 沙盒容器以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:启用端口 15150 和 9000,以允许内部与对等 pod 进行通信。
- 可选:如果您卸载了 Cloud Credential Operator,它与 OpenShift 沙盒容器 Operator 一起安装的,则创建 peer pod secret。
- 可选: 选择自定义 pod 虚拟机镜像。
- 可选:自定义 Kata 代理策略。
- 创建对等 pod 配置映射。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
3.2.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
- 在 Web 控制台中,导航到 Operators → OperatorHub。
-
在 Filter by keyword 字段中,输入
OpenShift sandboxed containers
。 - 选择 OpenShift 沙盒容器 Operator 标题并点 Install。
- 在 Install Operator 页面中,从可用 Update Channel 选项列表中选择 stable。
验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在
openshift-sandboxed-containers-operator
命名空间中安装 Operator。如果此命名空间尚不存在,则会自动创建。注意尝试在
openshift-sandboxed-containers-operator
以外的命名空间中安装 OpenShift 沙盒容器 Operator 会导致安装失败。- 验证是否为 Approval Strategy 选择了 Automatic。Automatic 是默认值,当有新的 z-stream 发行版本可用时,自动启用对 OpenShift 沙盒容器的自动更新。
- 点 Install。
- 导航到 Operators → Installed Operators,以验证是否已安装 Operator。
3.2.2. 为 AWS 启用端口
您必须启用端口 15150 和 9000,以允许内部与 AWS 上运行的对等 pod 通信。
先决条件
- 已安装 OpenShift 沙盒容器 Operator。
- 已安装 AWS 命令行工具。
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
登录您的 OpenShift Container Platform 集群并检索实例 ID:
Copy to clipboardCopied$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
检索 AWS 区域:
Copy to clipboardCopied$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
检索安全组 ID,并将其存储在阵列中:
Copy to clipboardCopied$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))
对于每个安全组 ID,授权 peer pod shim 访问 kata-agent 通信,并设置对等 pod 隧道:
Copy to clipboardCopied$ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ done
现在启用这些端口。
3.2.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。
先决条件
您有使用 AWS 控制台生成的以下值:
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
-
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 点 OpenShift 沙盒容器 Operator 标题。
- 单击右上角的 Import 图标(+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AWS_ACCESS_KEY_ID: "<aws_access_key>" 1 AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 2
- 点 Save 应用更改。
- 导航到 Workloads → Secrets 以验证对等 pod secret。
3.2.4. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
先决条件
- 如果没有根据集群凭证使用默认 AMI ID,则具有 Amazon Machine Image (AMI) ID。
流程
从 AWS 实例获取以下值:
检索并记录实例 ID:
Copy to clipboardCopied$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
这用于检索 secret 对象的其他值。
检索并记录 AWS 区域:
Copy to clipboardCopied$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
检索并记录 AWS 子网 ID:
Copy to clipboardCopied$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""
检索并记录 AWS VPC ID:
Copy to clipboardCopied$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""
检索并记录 AWS 安全组 ID:
Copy to clipboardCopied$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "aws" VXLAN_PORT: "9000" PODVM_INSTANCE_TYPE: "t3.medium" 1 PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 2 PROXY_TIMEOUT: "5m" PODVM_AMI_ID: "<podvm_ami_id>" 3 AWS_REGION: "<aws_region>" 4 AWS_SUBNET_ID: "<aws_subnet_id>" 5 AWS_VPC_ID: "<aws_vpc_id>" 6 AWS_SG_IDS: "<aws_sg_ids>" 7 PEERPODS_LIMIT_PER_NODE: "10" 8 TAGS: "key1=value1,key2=value2" 9 DISABLECVM: "true"
- 1
- 定义工作负载中没有定义类型时使用的默认实例类型。
- 2
- 列出创建 pod 时可以指定的所有实例类型。这可让您为大型工作负载需要较少的内存和更多 CPU 或更大的实例类型的工作负载定义较小的实例类型。
- 3
- 可选:默认情况下,这个值会在运行
KataConfig
CR 时填充,使用基于集群凭证的 AMI ID。如果您创建自己的 AMI,请指定正确的 AMI ID。 - 4
- 指定您检索到的
AWS_REGION
值。 - 5
- 指定您检索到的
AWS_SUBNET_ID
值。 - 6
- 指定您检索到的
AWS_VPC_ID
值。 - 7
- 指定您检索到的
AWS_SG_IDS
值。 - 8
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 9
- 您可以将自定义标签配置为 pod 虚拟机实例的
key:value
对,以跟踪对等 pod 成本或标识不同集群中的对等 pod。
- 点 Save 应用更改。
- 导航到 Workloads → ConfigMaps 以查看新的配置映射。
3.2.5. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
- 点 Save 应用更改。
3.2.6. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单,并将 Base64 编码的策略添加到其中:
Copy to clipboardCopiedapiVersion: 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
- 点 Save 应用更改。
3.2.7. 创建 KataConfig 自定义资源
您必须创建 KataConfig
自定义资源(CR),以便在 worker 节点上作为 RuntimeClass
安装 kata-remote
。
kata-remote
运行时类默认安装在所有 worker 节点上。如果要在特定节点上安装 kata-remote
,您可以向这些节点添加标签,然后在 KataConfig
CR 中定义该标签。
OpenShift 沙盒容器将 kata-remote
安装为集群上的 辅助 可选运行时,而不是主运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。以下因素可能会增加重启时间:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 选择 OpenShift 沙盒容器 Operator。
- 在 KataConfig 选项卡中,点 Create KataConfig。
输入以下详情:
-
Name: 可选:默认名称为
example-kataconfig
。 -
标签 :可选:输入任何相关的、识别到
KataConfig
资源的属性。每个标签代表一个键值对。 - enablePeerPods :为公共云、IBM Z® 和 IBM® LinuxONE 部署选择。
kataConfigPoolSelector.可选: 要在所选节点上安装
kata-remote
,请在所选节点上安装标签的匹配表达式:- 展开 kataConfigPoolSelector 区域。
- 在 kataConfigPoolSelector 区域中,展开 matchExpressions。这是标签选择器要求列表。
- 点 Add matchExpressions。
- 在 Key 字段中,输入选择器应用到的标签键。
-
在 Operator 字段中,输入键与标签值的关系。有效的运算符为
In
、NotIn
、Exists
和DoesNotExist
。 - 展开 Values 区域,然后点 Add value。
-
在 Value 字段中,为 key 标签值输入
true
或false
。
-
loglevel :定义使用
kata-remote
运行时类为节点检索的日志数据级别。
-
Name: 可选:默认名称为
点 Create。
KataConfig
CR 会被创建并在 worker 节点上安装kata-remote
运行时类。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。
验证
-
在 KataConfig 选项卡中,点
KataConfig
CR 查看其详情。 点 YAML 选项卡查看
status
小节。status
小节包含conditions
和kataNodes
键。status.kataNodes
的值是一个节点数组,每个节点都列出处于kata-remote
安装的特定状态的节点。每次有更新时都会出现一条消息。点 Reload 以刷新 YAML。
当
status.kataNodes
数组中的所有 worker 都会显示installed
和conditions.InProgress: False
时,集群中会安装kata-remote
。
其他资源
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
- 进入 Workloads → ConfigMaps。
- 点供应商配置映射查看其详情。
- 点 YAML 标签。
检查 YAML 文件
的状态
小节。如果
PODVM_AMI_ID
参数被填充,则 pod 虚拟机镜像已创建成功。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
如果您无法解决这个问题,请提交红帽支持问题单并附加这两个日志的输出。
3.2.8. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
您可以通过在 YAML 文件中添加注解,定义工作负载是否使用配置映射中定义的默认实例类型部署。
如果您不想手动定义实例类型,您可以添加注解来使用自动实例类型,具体取决于可用内存。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
- 在 OpenShift Container Platform Web 控制台中,导航到 Workloads → workload type,如 Pods。
- 在工作负载类型页面中,点对象查看其详情。
- 点 YAML 标签。
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
向 pod 模板对象添加注解,以使用手动定义的实例类型或自动实例类型:
要使用手动定义的实例类型,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "t3.medium" 1 # ...
要使用自动实例类型,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
定义可供工作负载使用的内存量。工作负载将根据可用内存量在自动实例类型上运行。
点 Save 应用更改。
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
3.3. 使用命令行部署 OpenShift 沙盒容器
您可以使用命令行界面(CLI)在 AWS 上部署 OpenShift 沙盒容器,以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:更改每个 worker 节点上运行的虚拟机数量。
- 可选:启用端口 15150 和 9000,以允许内部与对等 pod 进行通信。
- 可选:如果您卸载了 Cloud Credential Operator,它与 OpenShift 沙盒容器 Operator 一起安装的,则创建 peer pod secret。
- 可选: 选择自定义 pod 虚拟机镜像。
- 创建对等 pod 配置映射。
- 可选:自定义 Kata 代理策略。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
3.3.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
osc-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
运行以下命令创建命名空间:
Copy to clipboardCopied$ oc apply -f osc-namespace.yaml
创建
osc-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f osc-operatorgroup.yaml
创建
osc-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f osc-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n openshift-sandboxed-containers-operator
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedNAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
3.3.2. 为 AWS 启用端口
您必须启用端口 15150 和 9000,以允许内部与 AWS 上运行的对等 pod 通信。
先决条件
- 已安装 OpenShift 沙盒容器 Operator。
- 已安装 AWS 命令行工具。
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
登录您的 OpenShift Container Platform 集群并检索实例 ID:
Copy to clipboardCopied$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
检索 AWS 区域:
Copy to clipboardCopied$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
检索安全组 ID,并将其存储在阵列中:
Copy to clipboardCopied$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))
对于每个安全组 ID,授权 peer pod shim 访问 kata-agent 通信,并设置对等 pod 隧道:
Copy to clipboardCopied$ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ done
现在启用这些端口。
3.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。
先决条件
您有使用 AWS 控制台生成的以下值:
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
-
流程
根据以下示例创建
peer-pods-secret.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AWS_ACCESS_KEY_ID: "<aws_access_key>" 1 AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 2
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc apply -f peer-pods-secret.yaml
3.3.4. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
先决条件
- 如果没有根据集群凭证使用默认 AMI ID,则具有 Amazon Machine Image (AMI) ID。
流程
从 AWS 实例获取以下值:
检索并记录实例 ID:
Copy to clipboardCopied$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
这用于检索 secret 对象的其他值。
检索并记录 AWS 区域:
Copy to clipboardCopied$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
检索并记录 AWS 子网 ID:
Copy to clipboardCopied$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""
检索并记录 AWS VPC ID:
Copy to clipboardCopied$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""
检索并记录 AWS 安全组 ID:
Copy to clipboardCopied$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "aws" VXLAN_PORT: "9000" PODVM_INSTANCE_TYPE: "t3.medium" 1 PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 2 PROXY_TIMEOUT: "5m" PODVM_AMI_ID: "<podvm_ami_id>" 3 AWS_REGION: "<aws_region>" 4 AWS_SUBNET_ID: "<aws_subnet_id>" 5 AWS_VPC_ID: "<aws_vpc_id>" 6 AWS_SG_IDS: "<aws_sg_ids>" 7 PEERPODS_LIMIT_PER_NODE: "10" 8 TAGS: "key1=value1,key2=value2" 9 DISABLECVM: "true"
- 1
- 定义工作负载中没有定义类型时使用的默认实例类型。
- 2
- 列出创建 pod 时可以指定的所有实例类型。这可让您为大型工作负载需要较少的内存和更多 CPU 或更大的实例类型的工作负载定义较小的实例类型。
- 3
- 可选:默认情况下,这个值会在运行
KataConfig
CR 时填充,使用基于集群凭证的 AMI ID。如果您创建自己的 AMI,请指定正确的 AMI ID。 - 4
- 指定您检索到的
AWS_REGION
值。 - 5
- 指定您检索到的
AWS_SUBNET_ID
值。 - 6
- 指定您检索到的
AWS_VPC_ID
值。 - 7
- 指定您检索到的
AWS_SG_IDS
值。 - 8
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 9
- 您可以将自定义标签配置为 pod 虚拟机实例的
key:value
对,以跟踪对等 pod 成本或标识不同集群中的对等 pod。
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
3.3.5. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
通过添加
io.katacontainers.config.hypervisor.image
注解来编辑 pod 清单,并将其保存到pod-manifest.yaml
文件中:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc apply -f pod-manifest.yaml
3.3.6. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ oc apply -f my-pod.yaml
3.3.7. 创建 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
清单文件:
Copy to clipboardCopiedapiVersion: 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:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
获取您为对等 pod 创建的配置映射:
Copy to clipboardCopied$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
检查 YAML 文件
的状态
小节。如果
PODVM_AMI_ID
参数被填充,则 pod 虚拟机镜像已创建成功。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
如果您无法解决这个问题,请提交红帽支持问题单并附加这两个日志的输出。
3.3.8. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
您可以通过在 YAML 文件中添加注解,定义工作负载是否使用配置映射中定义的默认实例类型部署。
如果您不想手动定义实例类型,您可以添加注解来使用自动实例类型,具体取决于可用内存。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
向 pod 模板对象添加注解,以使用手动定义的实例类型或自动实例类型:
要使用手动定义的实例类型,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "t3.medium" 1 # ...
- 1
- 指定配置映射中定义的实例类型。
要使用自动实例类型,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
定义可供工作负载使用的内存量。工作负载将根据可用内存量在自动实例类型上运行。
运行以下命令,将更改应用到工作负载对象:
Copy to clipboardCopied$ oc apply -f <object.yaml>
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
第 4 章 在 Azure 上部署 OpenShift 沙盒容器
您可以在 Microsoft Azure Cloud Computing Services 上部署 OpenShift 沙盒容器。
OpenShift 沙盒容器部署对等 pod。对等 pod 设计对嵌套虚拟化的需求。如需更多信息,请参阅 对等 pod 和 Peer pod 技术深入了解。
集群要求
- 您已在要安装 OpenShift 沙盒容器 Operator 的集群中安装 Red Hat OpenShift Container Platform 4.14 或更高版本。
- 您的集群至少有一个 worker 节点。
有关在 Microsoft Azure Cloud Computing Services 上安装 OpenShift Container Platform 的详情,请参考在 Azure 上安装。
4.1. 对等 pod 资源要求
您必须确保集群有足够的资源。
对等 pod 虚拟机(VM)需要位于两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2
)、remote-hypervisor 资源(cloud-api-adaptor
),以及 worker 节点和对等 pod 虚拟机之间的隧道设置。 - 云实例。这是在云中运行的实际对等 pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由 RuntimeClass (kata-remote
)定义中包含的 pod 开销 处理,用于创建对等 pod。
在云中运行的对等 pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peer-pods-cm
配置映射中的 PEERPODS_LIMIT_PER_NODE
属性设置。
扩展资源名为 kata.peerpods.io/vm
,并允许 Kubernetes 调度程序处理容量跟踪和核算。
在安装 OpenShift 沙盒容器 Operator 后,您可以根据环境要求编辑每个节点的限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm
添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度对等 pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 会检查 pod 是否有预期的
RuntimeClassName
值,在TARGET_RUNTIME_CLASS
环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIME_CLASS
的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName
值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources
字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm
)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm
用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除 OpenShift Container Platform 中的特定系统命名空间。如果在这些系统命名空间中创建了对等 pod,则使用 Kubernetes 扩展资源的资源核算不起作用,除非 pod spec 包含扩展资源。
作为最佳实践,定义集群范围的策略,仅允许在特定命名空间中创建对等 pod。
4.2. 配置出站连接
要让对等 pod 与外部网络(如公共互联网)通信,您必须为 pod 虚拟机(VM)子网配置出站连接。这涉及设置 NAT 网关,并选择性地定义子网如何在 Azure 中与集群的虚拟网络(VNet)集成。
- 对等 pod 和子网
- 对等 pod 在专用 Azure 子网中操作,这需要显式配置出站访问。此子网可以是 OpenShift Container Platform 节点使用的默认 worker 子网,也可以是专门为对等 pod 创建的自定义子网。
- VNet peering
- 使用单独的子网时,VNet peering 会将对等 pod VNet 连接到集群的 VNet,确保内部通信同时保持隔离。这需要在 VNets 间的非覆盖 CIDR 范围。
您可以通过两种方式配置出站连接:
- 默认 worker 子网 :修改现有 worker 子网使其包含 NAT 网关。这更简单并重复使用集群资源,但它提供较少的隔离。
- peer pod VNet:为对等 pod 设置专用 VNet 和子网,附加 NAT 网关,并使用集群 VNet 对等。这在额外的复杂性方面提供了更高的隔离和灵活性。
4.2.1. 为出站连接配置默认 worker 子网
您可以使用 NAT 网关配置默认 worker 子网。
先决条件
-
已安装并进行身份验证的 Azure CLI (
az
)。 - 有对 Azure 资源组和 VNet 的管理员访问权限。
流程
运行以下命令设置
AZURE_RESOURCE_GROUP
环境变量:
Copy to clipboardCopied$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \ -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
运行以下命令设置
AZURE_REGION
环境变量:
Copy to clipboardCopied$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\ --query "{Location:location}" --output tsv) && \ echo "AZURE_REGION: \"$AZURE_REGION\""
运行以下命令设置
AZURE_VNET_NAME
环境变量:
Copy to clipboardCopied$ AZURE_VNET_NAME=$(az network vnet list \ -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)
运行以下命令设置
AZURE_SUBNET_ID
环境变量:
Copy to clipboardCopied$ AZURE_SUBNET_ID=$(az network vnet subnet list \ --resource-group "${AZURE_RESOURCE_GROUP}" \ --vnet-name "${AZURE_VNET_NAME}" --query "[].{Id:id} \ | [? contains(Id, 'worker')]" --output tsv)
运行以下命令,为 peer pod 子网设置 NAT 网关环境变量:
Copy to clipboardCopied$ export PEERPOD_NAT_GW=peerpod-nat-gw
Copy to clipboardCopied$ export PEERPOD_NAT_GW_IP=peerpod-nat-gw-ip
运行以下命令,为 NAT 网关创建公共 IP 地址:
Copy to clipboardCopied$ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \ -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}" --sku Standard
运行以下命令,创建 NAT 网关并将其与公共 IP 地址关联:
Copy to clipboardCopied$ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \ -l "${AZURE_REGION}" --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \ -n "${PEERPOD_NAT_GW}"
运行以下命令,更新 VNet 子网以使用 NAT 网关:
Copy to clipboardCopied$ az network vnet subnet update --nat-gateway "${PEERPOD_NAT_GW}" \ --ids "${AZURE_SUBNET_ID}"
验证
运行以下命令确认 NAT 网关已附加到 VNet 子网:
Copy to clipboardCopied$ az network vnet subnet show --ids "${AZURE_SUBNET_ID}" \ --query "natGateway.id" -o tsv
输出中包含 NAT 网关资源 ID。如果没有附加 NAT 网关,输出为空。
输出示例
Copy to clipboardCopied/subscriptions/12345678-1234-1234-1234-1234567890ab/resourceGroups/myResourceGroup/providers/Microsoft.Network/natGateways/myNatGateway
其它资源
- Azure 文档: NAT 网关概述
- Azure 文档: VNet Peering 概述
4.2.2. 为出站连接创建对等 pod VNet
要启用公共互联网访问,您可以为对等 pod 创建专用虚拟网络(VNet),附加网络地址转换(NAT)网关,创建一个子网,并使用非覆盖地址空间启用 VNet 对等。
先决条件
-
已安装 Azure CLI (
az
) - 您已登录到 Azure。请参阅使用 Azure CLI 对 Azure 进行授权。
- 具有管理员对 Azure 资源组和托管集群的 VNet 的访问权限。
-
您已验证了集群 VNet 无类别域间路由(CIDR)地址。默认值为
10.0.0.0/14
。如果您覆盖默认值,请确保为对等 pod VNet 选择了非覆盖 CIDR 地址。例如,192.168.0.0/16
。
流程
为 peer pod 网络设置环境变量:
运行以下命令设置 peer pod VNet 环境变量:
Copy to clipboardCopied$ export PEERPOD_VNET_NAME="${PEERPOD_VNET_NAME:-peerpod-vnet}"
Copy to clipboardCopied$ export PEERPOD_VNET_CIDR="${PEERPOD_VNET_CIDR:-192.168.0.0/16}"
运行以下命令来设置对等 pod 子网环境变量:
Copy to clipboardCopied$ export PEERPOD_SUBNET_NAME="${PEERPOD_SUBNET_NAME:-peerpod-subnet}"
Copy to clipboardCopied$ export PEERPOD_SUBNET_CIDR="${PEERPOD_SUBNET_CIDR:-192.168.0.0/16}"
为 Azure 设置环境变量:
Copy to clipboardCopied$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \ -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
Copy to clipboardCopied$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\ --query "{Location:location}" --output tsv) && \ echo "AZURE_REGION: \"$AZURE_REGION\""
Copy to clipboardCopied$ AZURE_VNET_NAME=$(az network vnet list \ -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)
运行以下命令设置对等 pod NAT 网关环境变量:
Copy to clipboardCopied$ export PEERPOD_NAT_GW="${PEERPOD_NAT_GW:-peerpod-nat-gw}"
Copy to clipboardCopied$ export PEERPOD_NAT_GW_IP="${PEERPOD_NAT_PUBLIC_IP:-peerpod-nat-gw-ip}"
配置 VNET:
运行以下命令来创建对等 pod VNet:
Copy to clipboardCopied$ az network vnet create --resource-group "${AZURE_RESOURCE_GROUP}" \ --name "${PEERPOD_VNET_NAME}" \ --address-prefixes "${PEERPOD_VNET_CIDR}"
运行以下命令,为对等 pod VNet 创建公共 IP 地址:
Copy to clipboardCopied$ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \ -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}"
运行以下命令,为对等 pod VNet 创建 NAT 网关:
Copy to clipboardCopied$ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \ -l "${AZURE_REGION}" \ --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \ -n "${PEERPOD_NAT_GW}"
运行以下命令,在对等 pod VNet 中创建子网并附加 NAT 网关:
Copy to clipboardCopied$ az network vnet subnet create \ --resource-group "${AZURE_RESOURCE_GROUP}" \ --vnet-name "${PEERPOD_VNET_NAME}" \ --name "${PEERPOD_SUBNET_NAME}" \ --address-prefixes "${PEERPOD_SUBNET_CIDR}" \ --nat-gateway "${PEERPOD_NAT_GW}"
配置虚拟网络对等连接:
运行以下命令来创建对等连接:
Copy to clipboardCopied$ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \ -n peerpod-azure-vnet-to-peerpod-vnet \ --vnet-name "${AZURE_VNET_NAME}" \ --remote-vnet "${PEERPOD_VNET_NAME}" --allow-vnet-access \ --allow-forwarded-traffic
运行以下命令来同步对等连接:
Copy to clipboardCopied$ az network vnet peering sync -g "${AZURE_RESOURCE_GROUP}" \ -n peerpod-azure-vnet-to-peerpod-vnet \ --vnet-name "${AZURE_VNET_NAME}"
运行以下命令来完成 peering 连接:
Copy to clipboardCopied$ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \ -n peerpod-peerpod-vnet-to-azure-vnet \ --vnet-name "${PEERPOD_VNET_NAME}" \ --remote-vnet "${AZURE_VNET_NAME}" --allow-vnet-access \ --allow-forwarded-traffic
验证
运行以下命令,从集群 VNet 检查对等连接状态:
Copy to clipboardCopied$ az network vnet peering show -g "${AZURE_RESOURCE_GROUP}" \ -n peerpod-azure-vnet-to-peerpod-vnet \ --vnet-name "${AZURE_VNET_NAME}" \ --query "peeringState" -o tsv
这应该返回
Connected
。运行以下命令,验证 NAT 网关是否已附加到对等 pod 子网:
Copy to clipboardCopied$ az network vnet subnet show --resource-group "${AZURE_RESOURCE_GROUP}" \ --vnet-name "${PEERPOD_VNET_NAME}" --name "${PEERPOD_SUBNET_NAME}" \ --query "natGateway.id" -o tsv
其它资源
- Azure 文档: NAT 网关概述
- Azure 文档: VNet Peering 概述
4.3. 使用 Web 控制台部署 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台在 Azure 上部署 OpenShift 沙盒容器以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:如果您卸载了 Cloud Credential Operator,它与 OpenShift 沙盒容器 Operator 一起安装的,则创建 peer pod secret。
- 可选: 选择自定义 pod 虚拟机镜像。
- 可选:创建 Azure secret。
- 可选:自定义 Kata 代理策略。
- 创建对等 pod 配置映射。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
4.3.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
- 在 Web 控制台中,导航到 Operators → OperatorHub。
-
在 Filter by keyword 字段中,输入
OpenShift sandboxed containers
。 - 选择 OpenShift 沙盒容器 Operator 标题并点 Install。
- 在 Install Operator 页面中,从可用 Update Channel 选项列表中选择 stable。
验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在
openshift-sandboxed-containers-operator
命名空间中安装 Operator。如果此命名空间尚不存在,则会自动创建。注意尝试在
openshift-sandboxed-containers-operator
以外的命名空间中安装 OpenShift 沙盒容器 Operator 会导致安装失败。- 验证是否为 Approval Strategy 选择了 Automatic。Automatic 是默认值,当有新的 z-stream 发行版本可用时,自动启用对 OpenShift 沙盒容器的自动更新。
- 点 Install。
- 导航到 Operators → Installed Operators,以验证是否已安装 Operator。
4.3.2. 创建对等 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。
先决条件
- 已安装并配置了 Azure CLI 工具。
流程
运行以下命令来检索 Azure 订阅 ID:
Copy to clipboardCopied$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \ -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
运行以下命令来生成 RBAC 内容:
Copy to clipboardCopied$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID \ --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"
输出示例
Copy to clipboardCopied{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }
-
记录要在
secret
对象中使用的 RBAC 输出。 - 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 点 OpenShift 沙盒容器 Operator 标题。
- 单击右上角的 Import 图标(+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<azure_client_id>" 1 AZURE_CLIENT_SECRET: "<azure_client_secret>" 2 AZURE_TENANT_ID: "<azure_tenant_id>" 3 AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>" 4
- 点 Save 应用更改。
- 导航到 Workloads → Secrets 以验证对等 pod secret。
4.3.3. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
流程
从 Azure 实例获取以下值:
检索并记录 Azure 资源组:
Copy to clipboardCopied$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
检索并记录 Azure VNet 名称:
Copy to clipboardCopied$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
这个值用于检索 Azure 子网 ID。
检索并记录 Azure 子网 ID:
Copy to clipboardCopied$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
检索并记录 Azure 网络安全组(NSG) ID:
Copy to clipboardCopied$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
检索并记录 Azure 区域:
Copy to clipboardCopied$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 2 AZURE_SUBNET_ID: "<azure_subnet_id>" 3 AZURE_NSG_ID: "<azure_nsg_id>" 4 PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>" 5 AZURE_REGION: "<azure_region>" 6 AZURE_RESOURCE_GROUP: "<azure_resource_group>" 7 PEERPODS_LIMIT_PER_NODE: "10" 8 TAGS: "key1=value1,key2=value2" 9 DISABLECVM: "true"
- 1
- 如果工作负载中没有定义实例大小,
"Standard_B2als_v2"
实例大小为默认值。 - 2
- 列出创建 pod 时可以指定的所有实例大小。这可让您为大型工作负载需要较少的内存和更小的实例大小的工作负载定义较小的实例大小。
- 3
- 指定您检索的
AZURE_SUBNET_ID
值。 - 4
- 指定您检索的
AZURE_NSG_ID
值。 - 5
- 可选:默认情况下,这个值会在运行
KataConfig
CR 时填充,使用基于集群凭证的 Azure 镜像 ID。如果创建自己的 Azure 镜像,请指定正确的镜像 ID。 - 6
- 指定您检索到的
AZURE_REGION
值。 - 7
- 指定您检索的
AZURE_RESOURCE_GROUP
值。 - 8
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 9
- 您可以将自定义标签配置为 pod 虚拟机实例的
key:value
对,以跟踪对等 pod 成本或标识不同集群中的对等 pod。
- 点 Save 应用更改。
- 导航到 Workloads → ConfigMaps 以查看新的配置映射。
4.3.4. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
- 点 Save 应用更改。
4.3.5. 创建 Azure secret
您必须创建 SSH 密钥 secret,这是 Azure 虚拟机(VM)创建 API 所需的。Azure 只需要 SSH 公钥。机密容器会禁用虚拟机中的 SSH,因此这些密钥对虚拟机没有影响。
流程
运行以下命令来生成 SSH 密钥对:
Copy to clipboardCopied$ ssh-keygen -f ./id_rsa -N ""
- 在 OpenShift Container Platform Web 控制台中导航至 Workloads → Secrets。
- 在 Secrets 页面中,验证您是否位于 openshift-sandboxed-containers-operator 项目中。
- 点 Create 并选择 Key/value secret。
-
在 Secret name 字段中,输入
ssh-key-secret
。 -
在 Key 字段中,输入
id_rsa.pub
。 - 在 Value 字段中,粘贴您的公共 SSH 密钥。
- 点 Create。
删除您创建的 SSH 密钥:
Copy to clipboardCopied$ shred --remove id_rsa.pub id_rsa
4.3.6. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单,并将 Base64 编码的策略添加到其中:
Copy to clipboardCopiedapiVersion: 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
- 点 Save 应用更改。
4.3.7. 创建 KataConfig 自定义资源
您必须创建 KataConfig
自定义资源(CR),以便在 worker 节点上作为 RuntimeClass
安装 kata-remote
。
kata-remote
运行时类默认安装在所有 worker 节点上。如果要在特定节点上安装 kata-remote
,您可以向这些节点添加标签,然后在 KataConfig
CR 中定义该标签。
OpenShift 沙盒容器将 kata-remote
安装为集群上的 辅助 可选运行时,而不是主运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。以下因素可能会增加重启时间:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 选择 OpenShift 沙盒容器 Operator。
- 在 KataConfig 选项卡中,点 Create KataConfig。
输入以下详情:
-
Name: 可选:默认名称为
example-kataconfig
。 -
标签 :可选:输入任何相关的、识别到
KataConfig
资源的属性。每个标签代表一个键值对。 - enablePeerPods :为公共云、IBM Z® 和 IBM® LinuxONE 部署选择。
kataConfigPoolSelector.可选: 要在所选节点上安装
kata-remote
,请在所选节点上安装标签的匹配表达式:- 展开 kataConfigPoolSelector 区域。
- 在 kataConfigPoolSelector 区域中,展开 matchExpressions。这是标签选择器要求列表。
- 点 Add matchExpressions。
- 在 Key 字段中,输入选择器应用到的标签键。
-
在 Operator 字段中,输入键与标签值的关系。有效的运算符为
In
、NotIn
、Exists
和DoesNotExist
。 - 展开 Values 区域,然后点 Add value。
-
在 Value 字段中,为 key 标签值输入
true
或false
。
-
loglevel :定义使用
kata-remote
运行时类为节点检索的日志数据级别。
-
Name: 可选:默认名称为
点 Create。
KataConfig
CR 会被创建并在 worker 节点上安装kata-remote
运行时类。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。
验证
-
在 KataConfig 选项卡中,点
KataConfig
CR 查看其详情。 点 YAML 选项卡查看
status
小节。status
小节包含conditions
和kataNodes
键。status.kataNodes
的值是一个节点数组,每个节点都列出处于kata-remote
安装的特定状态的节点。每次有更新时都会出现一条消息。点 Reload 以刷新 YAML。
当
status.kataNodes
数组中的所有 worker 都会显示installed
和conditions.InProgress: False
时,集群中会安装kata-remote
。
其他资源
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
- 进入 Workloads → ConfigMaps。
- 点供应商配置映射查看其详情。
- 点 YAML 标签。
检查 YAML 文件
的状态
小节。如果
AZURE_IMAGE_ID
参数被填充,则 pod 虚拟机镜像已被成功创建。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
如果您无法解决这个问题,请提交红帽支持问题单并附加这两个日志的输出。
4.3.8. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
您可以通过在 YAML 文件中添加注解,定义工作负载是否使用配置映射中定义的默认实例大小进行部署。
如果您不想手动定义实例大小,您可以添加注解来使用自动实例大小,具体取决于可用内存。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
- 在 OpenShift Container Platform Web 控制台中,导航到 Workloads → workload type,如 Pods。
- 在工作负载类型页面中,点对象查看其详情。
- 点 YAML 标签。
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
向 pod 模板对象添加注解,以使用手动定义的实例大小或自动实例大小:
要使用手动定义的实例大小,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "Standard_B2als_v2" 1 # ...
- 1
- 指定配置映射中定义的实例大小。
要使用自动实例大小,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
定义可供工作负载使用的内存量。工作负载将根据可用内存量在自动实例大小上运行。
点 Save 应用更改。
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
4.4. 使用命令行部署 OpenShift 沙盒容器
您可以使用命令行界面(CLI)在 Azure 上部署 OpenShift 沙盒容器,以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:更改每个 worker 节点上运行的虚拟机数量。
- 可选:如果您卸载了 Cloud Credential Operator,它与 OpenShift 沙盒容器 Operator 一起安装的,则创建 peer pod secret。
- 可选: 选择自定义 pod 虚拟机镜像。
- 创建对等 pod 配置映射。
- 可选:创建 Azure secret。
- 可选:自定义 Kata 代理策略。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
4.4.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
osc-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
运行以下命令创建命名空间:
Copy to clipboardCopied$ oc apply -f osc-namespace.yaml
创建
osc-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f osc-operatorgroup.yaml
创建
osc-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f osc-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n openshift-sandboxed-containers-operator
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedNAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
4.4.2. 创建对等 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。
先决条件
- 已安装并配置了 Azure CLI 工具。
流程
运行以下命令来检索 Azure 订阅 ID:
Copy to clipboardCopied$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \ -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
运行以下命令来生成 RBAC 内容:
Copy to clipboardCopied$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID \ --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"
输出示例
Copy to clipboardCopied{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }
-
记录要在
secret
对象中使用的 RBAC 输出。 根据以下示例创建
peer-pods-secret.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<azure_client_id>" 1 AZURE_CLIENT_SECRET: "<azure_client_secret>" 2 AZURE_TENANT_ID: "<azure_tenant_id>" 3 AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>" 4
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc apply -f peer-pods-secret.yaml
4.4.3. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
流程
从 Azure 实例获取以下值:
检索并记录 Azure 资源组:
Copy to clipboardCopied$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
检索并记录 Azure VNet 名称:
Copy to clipboardCopied$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
这个值用于检索 Azure 子网 ID。
检索并记录 Azure 子网 ID:
Copy to clipboardCopied$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
检索并记录 Azure 网络安全组(NSG) ID:
Copy to clipboardCopied$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
检索并记录 Azure 区域:
Copy to clipboardCopied$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 2 AZURE_SUBNET_ID: "<azure_subnet_id>" 3 AZURE_NSG_ID: "<azure_nsg_id>" 4 PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>" 5 AZURE_REGION: "<azure_region>" 6 AZURE_RESOURCE_GROUP: "<azure_resource_group>" 7 PEERPODS_LIMIT_PER_NODE: "10" 8 TAGS: "key1=value1,key2=value2" 9 DISABLECVM: "true"
- 1
- 如果工作负载中没有定义实例大小,
"Standard_B2als_v2"
实例大小为默认值。 - 2
- 列出创建 pod 时可以指定的所有实例大小。这可让您为大型工作负载需要较少的内存和更小的实例大小的工作负载定义较小的实例大小。
- 3
- 指定您检索的
AZURE_SUBNET_ID
值。 - 4
- 指定您检索的
AZURE_NSG_ID
值。 - 5
- 可选:默认情况下,这个值会在运行
KataConfig
CR 时填充,使用基于集群凭证的 Azure 镜像 ID。如果创建自己的 Azure 镜像,请指定正确的镜像 ID。 - 6
- 指定您检索到的
AZURE_REGION
值。 - 7
- 指定您检索的
AZURE_RESOURCE_GROUP
值。 - 8
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 9
- 您可以将自定义标签配置为 pod 虚拟机实例的
key:value
对,以跟踪对等 pod 成本或标识不同集群中的对等 pod。
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
4.4.4. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
通过添加
io.katacontainers.config.hypervisor.image
注解来编辑 pod 清单,并将其保存到pod-manifest.yaml
文件中:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc apply -f pod-manifest.yaml
4.4.5. 创建 Azure secret
您必须创建 SSH 密钥 secret,这是 Azure 虚拟机(VM)创建 API 所需的。Azure 只需要 SSH 公钥。机密容器会禁用虚拟机中的 SSH,因此这些密钥对虚拟机没有影响。
流程
运行以下命令来生成 SSH 密钥对:
Copy to clipboardCopied$ ssh-keygen -f ./id_rsa -N ""
运行以下命令来创建
Secret
对象:
Copy to clipboardCopied$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub \ --from-file=id_rsa=./id_rsa
删除您创建的 SSH 密钥:
Copy to clipboardCopied$ shred --remove id_rsa.pub id_rsa
4.4.6. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ oc apply -f my-pod.yaml
4.4.7. 创建 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
清单文件:
Copy to clipboardCopiedapiVersion: 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:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
获取您为对等 pod 创建的配置映射:
Copy to clipboardCopied$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
检查 YAML 文件
的状态
小节。如果
AZURE_IMAGE_ID
参数被填充,则 pod 虚拟机镜像已被成功创建。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
如果您无法解决这个问题,请提交红帽支持问题单并附加这两个日志的输出。
4.4.8. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
您可以通过在 YAML 文件中添加注解,定义工作负载是否使用配置映射中定义的默认实例大小进行部署。
如果您不想手动定义实例大小,您可以添加注解来使用自动实例大小,具体取决于可用内存。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
向 pod 模板对象添加注解,以使用手动定义的实例大小或自动实例大小:
要使用手动定义的实例大小,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "Standard_B2als_v2" 1 # ...
- 1
- 指定配置映射中定义的实例大小。
要使用自动实例大小,请添加以下注解:
Copy to clipboardCopiedapiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
定义可供工作负载使用的内存量。工作负载将根据可用内存量在自动实例大小上运行。
运行以下命令,将更改应用到工作负载对象:
Copy to clipboardCopied$ oc apply -f <object.yaml>
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
第 5 章 在 Google Cloud 上部署 OpenShift 沙盒容器
您可以在 Google Cloud 上部署 OpenShift 沙盒容器。
OpenShift 沙盒容器部署对等 pod。对等 pod 设计对嵌套虚拟化的需求。如需更多信息,请参阅 对等 pod 和 Peer pod 技术深入了解。
集群要求
- 您已在为 Google Cloud 安装 OpenShift 沙盒容器 Operator 的集群上安装了 OpenShift Container Platform 4.17 或更高版本。
- 您的集群至少有一个 worker 节点。
如需更多信息,请参阅 OpenShift Container Platform 文档中的在 Google Cloud 上安装。
5.1. 对等 pod 资源要求
您必须确保集群有足够的资源。
对等 pod 虚拟机(VM)需要位于两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2
)、remote-hypervisor 资源(cloud-api-adaptor
),以及 worker 节点和对等 pod 虚拟机之间的隧道设置。 - 云实例。这是在云中运行的实际对等 pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由 RuntimeClass (kata-remote
)定义中包含的 pod 开销 处理,用于创建对等 pod。
在云中运行的对等 pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peer-pods-cm
配置映射中的 PEERPODS_LIMIT_PER_NODE
属性设置。
扩展资源名为 kata.peerpods.io/vm
,并允许 Kubernetes 调度程序处理容量跟踪和核算。
在安装 OpenShift 沙盒容器 Operator 后,您可以根据环境要求编辑每个节点的限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm
添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度对等 pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 会检查 pod 是否有预期的
RuntimeClassName
值,在TARGET_RUNTIME_CLASS
环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIME_CLASS
的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName
值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources
字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm
)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm
用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除 OpenShift Container Platform 中的特定系统命名空间。如果在这些系统命名空间中创建了对等 pod,则使用 Kubernetes 扩展资源的资源核算不起作用,除非 pod spec 包含扩展资源。
作为最佳实践,定义集群范围的策略,仅允许在特定命名空间中创建对等 pod。
5.2. 使用 Web 控制台部署 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台在 Google Cloud 上部署 OpenShift 沙盒容器以执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:启用端口 15150,以允许内部与对等 pod 进行通信。
- 可选:如果您卸载了 Cloud Credential Operator,它与 OpenShift 沙盒容器 Operator 一起安装的,则创建 peer pod secret。
- 可选:自定义 Kata 代理策略。
- 创建对等 pod 配置映射。
- 可选:创建对等 pod 虚拟机(VM)镜像和虚拟机镜像配置映射。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
5.2.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
- 在 Web 控制台中,导航到 Operators → OperatorHub。
-
在 Filter by keyword 字段中,输入
OpenShift sandboxed containers
。 - 选择 OpenShift 沙盒容器 Operator 标题并点 Install。
- 在 Install Operator 页面中,从可用 Update Channel 选项列表中选择 stable。
验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在
openshift-sandboxed-containers-operator
命名空间中安装 Operator。如果此命名空间尚不存在,则会自动创建。注意尝试在
openshift-sandboxed-containers-operator
以外的命名空间中安装 OpenShift 沙盒容器 Operator 会导致安装失败。- 验证是否为 Approval Strategy 选择了 Automatic。Automatic 是默认值,当有新的 z-stream 发行版本可用时,自动启用对 OpenShift 沙盒容器的自动更新。
- 点 Install。
- 导航到 Operators → Installed Operators,以验证是否已安装 Operator。
5.2.2. 为 Google Cloud 启用端口 15150
您必须在 OpenShift Container Platform 上启用端口 15150,以允许内部与 Compute Engine 上运行的对等 pod 通信。
先决条件
- 已安装 Google Cloud 命令行界面(CLI)工具。
-
您可以使用具有
roles/container.admin
角色的用户访问 OpenShift Container Platform 集群。
流程
运行以下命令来设置项目 ID 变量:
Copy to clipboardCopied$ export GCP_PROJECT_ID="<project_id>"
运行以下命令登录到 Google Cloud:
Copy to clipboardCopied$ gcloud auth login
运行以下命令来设置 Google Cloud 项目 ID:
Copy to clipboardCopied$ gcloud config set project ${GCP_PROJECT_ID}
运行以下命令打开端口 15150 :
Copy to clipboardCopied$ 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.2.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 控制台中,导航到 IAM & Admin → Service Accounts → Keys,并将您的密钥保存为 JSON 文件。
运行以下命令,将 JSON 文件转换为一行字符串:
Copy to clipboardCopied$ cat <key_file>.json | jq -c .
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 点 OpenShift 沙盒容器 Operator 标题。
- 单击右上角的 Import 图标(+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: 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 文件创建的单行字符串替换。
- 点 Save 应用更改。
- 导航到 Workloads → Secrets 以验证对等 pod secret。
5.2.4. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
流程
登录到您的 Compute Engine 实例以设置以下环境变量:
运行以下命令来获取项目 ID:
Copy to clipboardCopied$ GCP_PROJECT_ID=$(gcloud config get-value project)
运行以下命令来获取区:
Copy to clipboardCopied$ GCP_ZONE=$(gcloud config get-value compute/zone)
运行以下命令来检索网络名称列表:
Copy to clipboardCopied$ gcloud compute networks list --format="value(name)"
运行以下命令来指定网络:
Copy to clipboardCopied$ GCP_NETWORK=<network_name> 1
- 1
- 将
<network_name
> 替换为网络的名称。
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: 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"
- 点 Save 应用更改。
- 导航到 Workloads → ConfigMaps 以查看新的配置映射。
5.2.5. 创建对等 pod 虚拟机镜像
您必须创建一个 QCOW2 peer pod 虚拟机(VM)镜像。
先决条件
-
已安装
podman
。 - 您可以访问容器 registry。
流程
运行以下命令克隆 OpenShift 沙盒容器存储库:
Copy to clipboardCopied$ git clone https://github.com/openshift/sandboxed-containers-operator.git
运行以下命令,进入
sandboxed-containers-operator/config/peerpods/podvm/bootc
:
Copy to clipboardCopied$ cd sandboxed-containers-operator/config/peerpods/podvm/bootc
运行以下命令登录到
registry.redhat.io
:
Copy to clipboardCopied$ podman login registry.redhat.io
您必须登录
registry.redhat.io
,因为podman 构建进程
必须访问托管在 registry 上的Containerfile.rhel
容器镜像。运行以下命令,为您的容器 registry 设置镜像路径:
$ IMG="<container_registry_url>/<username>/podvm-bootc:latest"
运行以下命令构建 pod 虚拟机
bootc
镜像:
Copy to clipboardCopied$ podman build -t ${IMG} -f Containerfile.rhel .
运行以下命令登录到您的容器 registry:
Copy to clipboardCopied$ podman login <container_registry_url>
运行以下命令将镜像推送到容器 registry 中:
Copy to clipboardCopied$ podman push ${IMG}
对于测试和开发,您可以使镜像变为公共镜像。
运行以下命令验证
podvm-bootc
镜像:
Copy to clipboardCopied$ podman images
输出示例
Copy to clipboardCopiedREPOSITORY TAG IMAGE ID CREATED SIZE example.com/example_user/podvm-bootc latest 88ddab975a07 2 seconds ago 1.82 GB
5.2.6. 创建对等 pod 虚拟机镜像配置映射
为 pod 虚拟机(VM)镜像创建配置映射。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单:
Copy to clipboardCopiedapiVersion: 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"
- 点 Save 应用更改。
- 导航到 Workloads → ConfigMaps 以查看新的配置映射。
5.2.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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
- 单击右上角的 Import 图标 (+)。
在 Import YAML 窗口中,粘贴以下 YAML 清单,并将 Base64 编码的策略添加到其中:
Copy to clipboardCopiedapiVersion: 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
- 点 Save 应用更改。
5.2.8. 创建 KataConfig 自定义资源
您必须创建 KataConfig
自定义资源(CR),以便在 worker 节点上作为 RuntimeClass
安装 kata-remote
。
kata-remote
运行时类默认安装在所有 worker 节点上。如果要在特定节点上安装 kata-remote
,您可以向这些节点添加标签,然后在 KataConfig
CR 中定义该标签。
OpenShift 沙盒容器将 kata-remote
安装为集群上的 辅助 可选运行时,而不是主运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。以下因素可能会增加重启时间:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
- 选择 OpenShift 沙盒容器 Operator。
- 在 KataConfig 选项卡中,点 Create KataConfig。
输入以下详情:
-
Name: 可选:默认名称为
example-kataconfig
。 -
标签 :可选:输入任何相关的、识别到
KataConfig
资源的属性。每个标签代表一个键值对。 - enablePeerPods :为公共云、IBM Z® 和 IBM® LinuxONE 部署选择。
kataConfigPoolSelector.可选: 要在所选节点上安装
kata-remote
,请在所选节点上安装标签的匹配表达式:- 展开 kataConfigPoolSelector 区域。
- 在 kataConfigPoolSelector 区域中,展开 matchExpressions。这是标签选择器要求列表。
- 点 Add matchExpressions。
- 在 Key 字段中,输入选择器应用到的标签键。
-
在 Operator 字段中,输入键与标签值的关系。有效的运算符为
In
、NotIn
、Exists
和DoesNotExist
。 - 展开 Values 区域,然后点 Add value。
-
在 Value 字段中,为 key 标签值输入
true
或false
。
-
loglevel :定义使用
kata-remote
运行时类为节点检索的日志数据级别。
-
Name: 可选:默认名称为
点 Create。
KataConfig
CR 会被创建并在 worker 节点上安装kata-remote
运行时类。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。
验证
-
在 KataConfig 选项卡中,点
KataConfig
CR 查看其详情。 点 YAML 选项卡查看
status
小节。status
小节包含conditions
和kataNodes
键。status.kataNodes
的值是一个节点数组,每个节点都列出处于kata-remote
安装的特定状态的节点。每次有更新时都会出现一条消息。点 Reload 以刷新 YAML。
当
status.kataNodes
数组中的所有 worker 都会显示installed
和conditions.InProgress: False
时,集群中会安装kata-remote
。
其他资源
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
- 进入 Workloads → ConfigMaps。
- 点供应商配置映射查看其详情。
- 点 YAML 标签。
检查 YAML 文件
的状态
小节。如果
PODVM_IMAGE_NAME
参数被填充,则 pod 虚拟机镜像已被成功创建。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
如果您无法解决这个问题,请提交红帽支持问题单并附加这两个日志的输出。
5.2.9. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
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
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
运行以下命令创建命名空间:
Copy to clipboardCopied$ oc apply -f osc-namespace.yaml
创建
osc-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f osc-operatorgroup.yaml
创建
osc-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f osc-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n openshift-sandboxed-containers-operator
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedNAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
5.3.2. 为 Google Cloud 启用端口 15150
您必须在 OpenShift Container Platform 上启用端口 15150,以允许内部与 Compute Engine 上运行的对等 pod 通信。
先决条件
- 已安装 Google Cloud 命令行界面(CLI)工具。
-
您可以使用具有
roles/container.admin
角色的用户访问 OpenShift Container Platform 集群。
流程
运行以下命令来设置项目 ID 变量:
Copy to clipboardCopied$ export GCP_PROJECT_ID="<project_id>"
运行以下命令登录到 Google Cloud:
Copy to clipboardCopied$ gcloud auth login
运行以下命令来设置 Google Cloud 项目 ID:
Copy to clipboardCopied$ gcloud config set project ${GCP_PROJECT_ID}
运行以下命令打开端口 15150 :
Copy to clipboardCopied$ 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 文件:
Copy to clipboardCopied$ gcloud iam service-accounts keys create <key_filename>.json \ --iam-account=<service_account_email_address>
运行以下命令,将 JSON 文件转换为一行字符串:
Copy to clipboardCopied$ cat <key_file>.json | jq -c .
根据以下示例创建
peer-pods-secret.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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:
Copy to clipboardCopied$ oc apply -f peer-pods-secret.yaml
5.3.4. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
流程
登录到您的 Compute Engine 实例以设置以下环境变量:
运行以下命令来获取项目 ID:
Copy to clipboardCopied$ GCP_PROJECT_ID=$(gcloud config get-value project)
运行以下命令来获取区:
Copy to clipboardCopied$ GCP_ZONE=$(gcloud config get-value compute/zone)
运行以下命令来检索网络名称列表:
Copy to clipboardCopied$ gcloud compute networks list --format="value(name)"
运行以下命令来指定网络:
Copy to clipboardCopied$ GCP_NETWORK=<network_name> 1
- 1
- 将
<network_name
> 替换为网络的名称。
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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"
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
5.3.5. 创建对等 pod 虚拟机镜像
您必须创建一个 QCOW2 peer pod 虚拟机(VM)镜像。
先决条件
-
已安装
podman
。 - 您可以访问容器 registry。
流程
运行以下命令克隆 OpenShift 沙盒容器存储库:
Copy to clipboardCopied$ git clone https://github.com/openshift/sandboxed-containers-operator.git
运行以下命令,进入
sandboxed-containers-operator/config/peerpods/podvm/bootc
:
Copy to clipboardCopied$ cd sandboxed-containers-operator/config/peerpods/podvm/bootc
运行以下命令登录到
registry.redhat.io
:
Copy to clipboardCopied$ podman login registry.redhat.io
您必须登录
registry.redhat.io
,因为podman 构建进程
必须访问托管在 registry 上的Containerfile.rhel
容器镜像。运行以下命令,为您的容器 registry 设置镜像路径:
$ IMG="<container_registry_url>/<username>/podvm-bootc:latest"
运行以下命令构建 pod 虚拟机
bootc
镜像:
Copy to clipboardCopied$ podman build -t ${IMG} -f Containerfile.rhel .
运行以下命令登录到您的容器 registry:
Copy to clipboardCopied$ podman login <container_registry_url>
运行以下命令将镜像推送到容器 registry 中:
Copy to clipboardCopied$ podman push ${IMG}
对于测试和开发,您可以使镜像变为公共镜像。
运行以下命令验证
podvm-bootc
镜像:
Copy to clipboardCopied$ podman images
输出示例
Copy to clipboardCopiedREPOSITORY 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
的配置映射清单,其内容如下:
Copy to clipboardCopiedapiVersion: 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ 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
清单文件:
Copy to clipboardCopiedapiVersion: 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:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
验证 pod 虚拟机镜像
在集群中安装 kata-remote
后,OpenShift 沙盒容器 Operator 会创建一个 pod 虚拟机镜像,用于创建对等 pod。此过程可能需要很长时间,因为镜像是在云实例上创建的。您可以通过检查您为云供应商创建的配置映射来验证 pod 虚拟机镜像是否已成功创建。
流程
获取您为对等 pod 创建的配置映射:
Copy to clipboardCopied$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
检查 YAML 文件
的状态
小节。如果
PODVM_IMAGE_NAME
参数被填充,则 pod 虚拟机镜像已被成功创建。
故障排除
运行以下命令来检索事件日志:
Copy to clipboardCopied$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
运行以下命令来检索作业日志:
Copy to clipboardCopied$ 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 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
第 6 章 在 IBM Z 和 IBM LinuxONE 上部署 OpenShift 沙盒容器
您可以在 IBM Z® 和 IBM® LinuxONE 上部署 OpenShift 沙盒容器。
OpenShift 沙盒容器部署对等 pod。对等 pod 设计对嵌套虚拟化的需求。如需更多信息,请参阅 对等 pod 和 Peer pod 技术深入了解。
IBM Z® 和 IBM® LinuxONE 上的 OpenShift 沙盒容器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
集群要求
- 您已在要安装 OpenShift 沙盒容器 Operator 的集群中安装 Red Hat OpenShift Container Platform 4.14 或更高版本。
- 集群有三个 control plane 节点,以及至少两个 worker 节点。
- 您的集群节点和对等 pod 位于同一 IBM Z® KVM 主机逻辑分区(LPAR)中。
- 您的集群节点和对等 pod 连接到同一子网。
有关在 IBM Z® 和 IBM® LinuxONE 上安装 OpenShift Container Platform 的详情,请参考在 IBM Z® 和 IBM® LinuxONE 上安装 OpenShift Container Platform。
6.1. 对等 pod 资源要求
您必须确保集群有足够的资源。
对等 pod 虚拟机(VM)需要位于两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2
)、remote-hypervisor 资源(cloud-api-adaptor
),以及 worker 节点和对等 pod 虚拟机之间的隧道设置。 - libvirt 虚拟机实例。这是在 LPAR (KVM 主机)中运行的实际对等 pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由 RuntimeClass (kata-remote
)定义中包含的 pod 开销 处理,用于创建对等 pod。
在云中运行的对等 pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peer-pods-cm
配置映射中的 PEERPODS_LIMIT_PER_NODE
属性设置。
扩展资源名为 kata.peerpods.io/vm
,并允许 Kubernetes 调度程序处理容量跟踪和核算。
在安装 OpenShift 沙盒容器 Operator 后,您可以根据环境要求编辑每个节点的限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm
添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度对等 pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 会检查 pod 是否有预期的
RuntimeClassName
值,在TARGET_RUNTIME_CLASS
环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIME_CLASS
的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName
值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources
字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm
)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm
用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除 OpenShift Container Platform 中的特定系统命名空间。如果在这些系统命名空间中创建了对等 pod,则使用 Kubernetes 扩展资源的资源核算不起作用,除非 pod spec 包含扩展资源。
作为最佳实践,定义集群范围的策略,仅允许在特定命名空间中创建对等 pod。
6.2. 在 IBM Z 和 IBM LinuxONE 上部署 OpenShift 沙盒容器
您可以使用命令行界面(CLI)在 IBM Z® 和 IBM® LinuxONE 上部署 OpenShift 沙盒容器来执行以下任务:
- 安装 OpenShift 沙盒容器 Operator。
- 可选:更改每个 worker 节点上运行的虚拟机数量。
- 可选:配置 libvirt 卷。
- 可选:创建自定义对等 pod 虚拟机镜像。
- 创建对等 pod secret。
- 创建对等 pod 配置映射。
- 创建 pod 虚拟机镜像配置映射。
- 创建 KVM 主机 secret。
- 可选: 选择自定义对等 pod 虚拟机镜像。
- 可选:自定义 Kata 代理策略。
-
创建
KataConfig
自定义资源。 - 配置 OpenShift 沙盒容器工作负载对象。
6.2.1. 安装 OpenShift 沙盒容器 Operator
您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
osc-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
运行以下命令创建命名空间:
Copy to clipboardCopied$ oc apply -f osc-namespace.yaml
创建
osc-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f osc-operatorgroup.yaml
创建
osc-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f osc-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n openshift-sandboxed-containers-operator
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedNAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
6.2.2. 配置 libvirt 卷
OpenShift 沙盒容器 Operator 在安装过程中自动配置 KVM 主机上的 libvirt 卷和池。如果需要,您可以手动配置或创建额外的 libvirt 卷和池。
先决条件
- 已使用 OpenShift Container Platform Web 控制台或命令行在 OpenShift Container Platform 集群上安装 OpenShift 沙盒容器 Operator。
- 您有 KVM 主机的管理员特权。
-
您已在 KVM 主机上安装了
podman
。 -
您已在 KVM 主机上安装了
virt-customize
。 -
您的镜像有一个
/var/lib/libvirt/images/
目录。
流程
- 登录到 KVM 主机。
运行以下命令设置 libvirt 池的名称:
Copy to clipboardCopied$ export LIBVIRT_POOL=<libvirt_pool>
您需要
LIBVIRT_POOL
值来为 libvirt 提供程序创建 secret。运行以下命令设置 libvirt 卷的名称:
Copy to clipboardCopied$ export LIBVIRT_VOL_NAME=<libvirt_volume>
您需要
LIBVIRT_VOL_NAME
值来为 libvirt 提供程序创建 secret。运行以下命令,设置默认存储池位置的路径:
Copy to clipboardCopied$ export LIBVIRT_POOL_DIRECTORY="/var/lib/libvirt/images/"
运行以下命令来创建 libvirt 池:
Copy to clipboardCopied$ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"
运行以下命令来启动 libvirt 池:
Copy to clipboardCopied$ virsh pool-start $LIBVIRT_POOL
运行以下命令,为池创建 libvirt 卷:
Copy to clipboardCopied$ virsh -c qemu:///system \ vol-create-as --pool $LIBVIRT_POOL \ --name $LIBVIRT_VOL_NAME \ --capacity 20G \ --allocation 2G \ --prealloc-metadata \ --format qcow2
6.2.3. 创建自定义对等 pod 虚拟机镜像
您可以创建自定义对等 pod 虚拟机(VM)镜像,而不是使用默认的 Operator 构建镜像。
您可以使用对等 pod QCOW2 镜像构建开放容器项目(OCI)容器。之后,您将容器 registry URL 和镜像路径添加到对等 pod 虚拟机镜像配置映射。
流程
创建
Dockerfile.podvm-oci
文件:
Copy to clipboardCopiedFROM scratch ARG PODVM_IMAGE_SRC ENV PODVM_IMAGE_PATH="/image/podvm.qcow2" COPY $PODVM_IMAGE_SRC $PODVM_IMAGE_PATH
运行以下命令,使用 pod 虚拟机 QCOW2 镜像构建容器:
Copy to clipboardCopied$ docker build -t podvm-libvirt \ --build-arg PODVM_IMAGE_SRC=<podvm_image_source> \ 1 --build-arg PODVM_IMAGE_PATH=<podvm_image_path> \ 2 -f Dockerfile.podvm-oci .
6.2.4. 创建对等 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。
先决条件
LIBVIRT_URI
.这个值是 libvirt 网络的默认网关 IP 地址。检查 libvirt 网络设置以获取此值。注意如果 libvirt 使用默认网桥虚拟网络,您可以通过运行以下命令来获取
LIBVIRT_URI
:
Copy to clipboardCopied$ virtint=$(bridge_line=$(virsh net-info default | grep Bridge); echo "${bridge_line//Bridge:/}" | tr -d [:blank:]) $ LIBVIRT_URI=$( ip -4 addr show $virtint | grep -oP '(?<=inet\s)\d+(\.\d+){3}') $ LIBVIRT_GATEWAY_URI="qemu+ssh://root@${LIBVIRT_URI}/system?no_verify=1"
-
红帽_OFFLINE_TOKEN
.您已生成此令牌,以通过 Red Hat API Tokens 下载 RHEL 镜像。
流程
根据以下示例创建
peer-pods-secret.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: CLOUD_PROVIDER: "libvirt" LIBVIRT_URI: "<libvirt_gateway_uri>" 1 REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 2
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc apply -f peer-pods-secret.yaml
6.2.5. 创建对等 pod 配置映射
您必须为 OpenShift 沙盒容器创建对等 pod 配置映射。
流程
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "libvirt" PEERPODS_LIMIT_PER_NODE: "10" 1 LIBVIRT_POOL: "<libvirt_pool>" 2 LIBVIRT_VOL_NAME: "<libvirt_volume>" 3 LIBVIRT_DIR_NAME: "/var/lib/libvirt/images/<directory_name>" 4 LIBVIRT_NET: "default" 5 DISABLECVM: "true"
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
6.2.6. 创建对等 pod 虚拟机镜像配置映射
您必须为对等 pod 虚拟机(VM)镜像创建配置映射。
先决条件
- 您必须使用 Red Hat Hybrid Cloud Console 创建激活码。
- 可选:如果要使用 Cloud API Adaptor 自定义镜像,则必须有镜像的名称、URL 和分支或标签。
流程
根据以下示例创建
libvirt-podvm-image-cm.yaml
清单:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: libvirt-podvm-image-cm namespace: openshift-sandboxed-containers-operator data: PODVM_DISTRO: "rhel" DOWNLOAD_SOURCES: "no" 1 CAA_SRC: "https://github.com/confidential-containers/cloud-api-adaptor" 2 CAA_REF: "main" 3 CONFIDENTIAL_COMPUTE_ENABLED: "yes" UPDATE_PEERPODS_CM: "yes" ORG_ID: "<rhel_organization_id>" ACTIVATION_KEY: "<rhel_activation_key>" 4 IMAGE_NAME: "<podvm_libvirt_image>" 5 PODVM_IMAGE_URI: "oci::<image_repo_url>:<image_tag>::<image_path>" 6 SE_BOOT: "true" 7 BASE_OS_VERSION: "<rhel_image_os_version>" 8
- 1
- 如果要使用自定义 Cloud API Adaptor 源来构建 pod 虚拟机镜像,请指定
yes
。 - 2
- 可选:指定 Cloud API Adaptor 自定义镜像的 URL。
- 3
- 可选:指定 Cloud API Adaptor 自定义镜像的分支或标签。
- 4
- 指定 RHEL 激活码。
- 5
- 指定自定义 peer pod VM 镜像名称。
- 6
- 可选:如果您创建了自定义对等 pod 虚拟机镜像,请指定容器 registry URL、镜像标签和镜像路径(默认为
/image/podvm.qcow2)。
否则,将值设为""
。 - 7
- 默认值为
true
,为默认 Operator 构建的镜像启用 IBM Secure Execution。如果您使用自定义对等 pod 虚拟机镜像,请将其设置为false
。 - 8
- 指定 RHEL 镜像操作系统版本。IBM Z® Secure Execution 支持 RHEL 9.5 及更新的版本。
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f libvirt-podvm-image-cm.yaml
libvirt pod 虚拟机镜像配置映射为您的 libvirt 供应商创建。
6.2.7. 创建 KVM 主机 secret
您必须为 KVM 主机创建 secret。
流程
运行以下命令来生成 SSH 密钥对:
Copy to clipboardCopied$ ssh-keygen -f ./id_rsa -N ""
将公共 SSH 密钥复制到 KVM 主机:
Copy to clipboardCopied$ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_IP> 1
- 1
- 指定 KVM 主机的 IP 地址或运行对等 pod 虚拟机的 LPAR。例如,192.168.2.1
。
运行以下命令来创建
Secret
对象:
Copy to clipboardCopied$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub \ --from-file=id_rsa=./id_rsa
删除您创建的 SSH 密钥:
Copy to clipboardCopied$ shred --remove id_rsa.pub id_rsa
6.2.8. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。您可以在 libvirt 池中创建新的 libvirt 卷,并将自定义对等 pod 虚拟机镜像上传到新卷。然后,您将 pod 清单更新为使用自定义对等 pod 虚拟机镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
运行以下命令设置 libvirt 池的名称:
Copy to clipboardCopied$ export LIBVIRT_POOL=<libvirt_pool> 1
- 1
- 指定现有的 libvirt 池名称。
运行以下命令,设置新 libvirt 卷的名称:
Copy to clipboardCopied$ export LIBVIRT_VOL_NAME=<new_libvirt_volume>
运行以下命令,为池创建 libvirt 卷:
Copy to clipboardCopied$ virsh -c qemu:///system \ vol-create-as --pool $LIBVIRT_POOL \ --name $LIBVIRT_VOL_NAME \ --capacity 20G \ --allocation 2G \ --prealloc-metadata \ --format qcow2
将自定义对等 pod 虚拟机镜像上传到 libvirt 卷:
Copy to clipboardCopied$ virsh -c qemu:///system vol-upload \ --vol $LIBVIRT_VOL_NAME <custom_podvm_image.qcow2> \ 1 --pool $LIBVIRT_POOL --sparse
- 1
- 指定自定义 peer pod VM 镜像名称。
根据以下示例创建
pod-manifest.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<new_libvirt_volume>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc apply -f pod-manifest.yaml
6.2.9. 自定义 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
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ oc apply -f my-pod.yaml
6.2.10. 创建 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
清单文件:
Copy to clipboardCopiedapiVersion: 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:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令,验证您是否已构建对等 pod 镜像并将其上传到 libvirt 卷中:
Copy to clipboardCopied$ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedName: peer-pods-cm Namespace: openshift-sandboxed-containers-operator Labels: <none> Annotations: <none> Data ==== CLOUD_PROVIDER: libvirt BinaryData ==== Events: <none>
运行以下命令,监控
kata-oc
机器配置池进度,以确保它处于UPDATED
状态,当UPDATED
等于 MACHINECOUNT 时:MACHINECOUNT
Copy to clipboardCopied$ watch oc get mcp/kata-oc
运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
6.2.11. 配置工作负载对象
您必须通过将 kata-remote
设置为以下 pod 模板对象的运行时类来配置 OpenShift 沙盒容器工作负载对象:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。
先决条件
-
您已创建了
KataConfig
自定义资源(CR)。
流程
将
spec.runtimeClassName: kata-remote
添加到每个 pod 模板工作负载对象的清单中,如下例所示:
Copy to clipboardCopiedapiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata-remote
,则工作负载在 OpenShift 沙盒容器上运行,使用对等 pod。
第 7 章 在 Azure 上部署机密容器
在部署 OpenShift 沙盒容器后,您可以在 Microsoft Azure Cloud Computing Services 上部署机密容器。
Azure 上的机密容器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
集群要求
- 您已为 pod 虚拟机子网配置了出站连接。
- 您已在安装 Confidential compute attestation Operator 的集群上安装了 Red Hat OpenShift Container Platform 4.15 或更高版本。
您可以执行以下步骤来部署机密容器:
- 安装 Confidential compute attestation Operator。
- 为 Trustee 创建路由。
- 启用机密容器功能门。
- 创建 initdata。
- 更新对等 pod 配置映射。
- 可选:自定义 Kata 代理策略。
-
删除
KataConfig
自定义资源(CR)。 -
重新创建
KataConfig
CR。 - 创建 Trustee 身份验证 secret。
- 创建 Trustee 配置映射。
- 配置 Trustee 值、策略和 secret。
-
创建
KbsConfig
CR。 - 验证 Trustee 配置。
- 验证 attestation 进程。
7.1. 安装 Confidential compute attestation Operator
您可以使用 CLI 在 Azure 上安装 Confidential compute attestation Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
trustee-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: trustee-operator-system
运行以下命令来创建
trustee-operator-system
命名空间:
Copy to clipboardCopied$ oc apply -f trustee-namespace.yaml
创建
trustee-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: trustee-operator-group namespace: trustee-operator-system spec: targetNamespaces: - trustee-operator-system
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f trustee-operatorgroup.yaml
创建
trustee-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: trustee-operator-system namespace: trustee-operator-system spec: channel: stable installPlanApproval: Automatic name: trustee-operator source: redhat-operators sourceNamespace: openshift-marketplace
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f trustee-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n trustee-operator-system
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME DISPLAY PHASE trustee-operator.v0.3.0 Trustee Operator 0.3.0 Succeeded
7.2. 启用机密容器功能门
您必须启用 Confidential Containers 功能门。
先决条件
- 已订阅 OpenShift 沙盒容器 Operator。
流程
创建
cc-feature-gate.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: osc-feature-gates namespace: openshift-sandboxed-containers-operator data: confidential: "true"
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f cc-feature-gate.yaml
7.3. 为 Trustee 创建路由
您可以为 Trustee 使用边缘 TLS 终止创建安全路由。外部入口流量以 HTTPS 的形式到达路由器 pod,并以 HTTP 的形式传递给 Trustee pod。
先决条件
- 已安装 Confidential compute attestation Operator。
流程
运行以下命令来创建边缘路由:
Copy to clipboardCopied$ oc create route edge --service=kbs-service --port kbs-port \ -n trustee-operator-system
注意注: 目前,只支持带有有效 CA 签名证书的路由。您不能使用带有自签名证书的路由。
运行以下命令设置
TRUSTEE_HOST
变量:
Copy to clipboardCopied$ TRUSTEE_HOST=$(oc get route -n trustee-operator-system kbs-service \ -o jsonpath={.spec.host})
运行以下命令验证路由:
Copy to clipboardCopied$ echo $TRUSTEE_HOST
输出示例
Copy to clipboardCopiedkbs-service-trustee-operator-system.apps.memvjias.eastus.aroapp.io
为对等 pod 配置映射记录这个值。
7.4. 关于 initdata
initdata 规格提供了一种灵活的方法,来在运行时初始化具有敏感或特定工作负载的对等 pod,以避免在虚拟机(VM)镜像中嵌入此类数据。这通过减少机密信息暴露并通过删除自定义镜像构建来提高灵活性来提高安全性。例如,initdata 可以包含三个配置设置:
- 用于安全通信的 X.509 证书。
- 用于身份验证的加密密钥。
-
可选的 Kata Agent
policy.rego
文件,在覆盖默认的 Kata Agent 策略时强制执行运行时行为。
您可以使用以下方法之一应用 initdata 配置:
- 通过在对等 pod 配置映射中包括它,为所有 pod 设置集群范围的默认值。
在配置 pod 工作负载对象时,对于特定的 pod,可以自定义单个工作负载。
您在配置 pod 工作负载对象时指定的
io.katacontainers.config.runtime.cc_init_data
注解会覆盖该特定 pod 的对等 pod 配置映射中的全局INITDATA
设置。Kata 运行时在创建 pod 时自动处理这个优先级。
initdata 内容配置以下组件:
- attestation Agent (AA),它通过向信任者发送证据来验证对等 pod 的可信度。
- 机密数据 Hub (CDH),用于管理对等 pod 虚拟机中的 secret 和保护数据访问。
- Kata Agent,它强制执行运行时策略并管理 pod 虚拟机内容器的生命周期。
7.5. 创建 initdata
使用 initdata 创建 TOML 文件,并将其转换为 Base64 编码的字符串。使用此字符串指定对等 pod 配置映射中、对等 pod 清单中或 verification-pod.yaml
文件中的值。
如果在 Trustee 配置映射中配置 insecure_http = true
,您必须删除 kbs_cert
设置。
流程
创建
initdata.toml
配置文件:
Copy to clipboardCopied```toml algorithm = "sha384" version = "0.1.0" [data] "aa.toml" = ''' [token_configs] [token_configs.coco_as] url = '<url>:<port>' 1 [token_configs.kbs] url = '<url>:<port>' cert = """ -----BEGIN CERTIFICATE----- <kbs_certificate> 2 -----END CERTIFICATE----- """ ''' "cdh.toml" = ''' socket = 'unix:///run/confidential-containers/cdh.sock' credentials = [] [kbc] name = 'cc_kbc' url = '<url>:<port>' kbs_cert = """ 3 -----BEGIN CERTIFICATE----- <kbs_certificate> 4 -----END CERTIFICATE----- """ ''' "policy.rego" = ''' 5 package agent_policy default AddARPNeighborsRequest := true default AddSwapRequest := true default CloseStdinRequest := true default CopyFileRequest := true default CreateContainerRequest := true default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true default GetMetricsRequest := true default GetOOMEventRequest := true default GuestDetailsRequest := true default ListInterfacesRequest := true default ListRoutesRequest := true default MemHotplugByProbeRequest := true default OnlineCPUMemRequest := true default PauseContainerRequest := true default PullImageRequest := true default ReadStreamRequest := true default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default ReseedRandomDevRequest := true default ResumeContainerRequest := true default SetGuestDateTimeRequest := true default SetPolicyRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StartTracingRequest := true default StatsContainerRequest := true default StopTracingRequest := true default TtyWinResizeRequest := true default UpdateContainerRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := true ''' ```
- 1
- 指定 Trustee 实例的 URL 和端口。如果您使用
insecure_http
配置 Trustee 用于测试目的,请使用 HTTP。否则,请使用 HTTPS。对于生产环境系统,请避免使用insecure_http
,除非您将环境配置为外部处理 TLS,例如使用代理。 - 2
- 为 attestation 代理指定 Base64 编码的 TLS 证书。对于测试目的,这不是必要的,但建议在生产系统中使用。
- 3
- 如果您在 Trustee 配置映射中配置
insecure_http = true
,请删除kbs_cert
设置。 - 4
- 为 Trustee 实例指定 Base64 编码的 TLS 证书。
- 5
- 可选: 您可以指定一个自定义 Kata Agent 策略。
运行以下命令,将
initdata.toml
文件转换为文本文件中的 Base64 编码字符串:
Copy to clipboardCopied$ base64 -w0 initdata.toml > initdata.txt
7.6. 更新对等 pod 配置映射
您必须为机密容器更新对等 pod 配置映射。
将安全引导设置为 true
以默认启用。默认值为 false
,这代表存在安全风险。
流程
从 Azure 实例获取以下值:
检索并记录 Azure 资源组:
Copy to clipboardCopied$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
检索并记录 Azure VNet 名称:
Copy to clipboardCopied$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
这个值用于检索 Azure 子网 ID。
检索并记录 Azure 子网 ID:
Copy to clipboardCopied$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
检索并记录 Azure 网络安全组(NSG) ID:
Copy to clipboardCopied$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
检索并记录 Azure 区域:
Copy to clipboardCopied$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_DC2as_v5" 1 AZURE_INSTANCE_SIZES: "Standard_DC2as_v5, Standard_DC4as_v5, Standard_DC8as_v5" 2 AZURE_SUBNET_ID: "<azure_subnet_id>" 3 AZURE_NSG_ID: "<azure_nsg_id>" 4 PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>" 5 AZURE_REGION: "<azure_region>" 6 AZURE_RESOURCE_GROUP: "<azure_resource_group>" 7 PEERPODS_LIMIT_PER_NODE: "10" 8 TAGS: "key1=value1,key2=value2" 9 INITDATA: "<base64_encoded_initdata>" 10 ENABLE_SECURE_BOOT: "true" 11 DISABLECVM: "false"
- 1
- 如果工作负载中没有定义实例大小,
"Standard_DC2as_v5"
值是默认值。确保实例类型支持可信环境。默认的"Standard_DC2as_v5"
值用于 AMD SEV-SNP。如果您的 TEE 是 Intel TDX,请指定Standard_EC4eds_v5
。 - 2
- 列出创建 pod 时可以指定的所有实例大小。这可让您为大型工作负载需要较少的内存和更小的实例大小的工作负载定义较小的实例大小。对于 Intel TDX,指定
"Standard_EC4eds_v5、Standard_EC8eds_v5、Standard_EC16eds_v5
"。 - 3
- 指定您检索的
AZURE_SUBNET_ID
值。 - 4
- 指定您检索的
AZURE_NSG_ID
值。 - 5
- 可选:默认情况下,这个值会在运行
KataConfig
CR 时填充,使用基于集群凭证的 Azure 镜像 ID。如果创建自己的 Azure 镜像,请指定正确的镜像 ID。 - 6
- 指定您检索到的
AZURE_REGION
值。 - 7
- 指定您检索的
AZURE_RESOURCE_GROUP
值。 - 8
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 9
- 您可以将自定义标签配置为 pod 虚拟机实例的
key:value
对,以跟踪对等 pod 成本或标识不同集群中的对等 pod。 - 10
- 指定您在
initdata.txt
文件中创建的 Base64 编码字符串。 - 11
- 指定
true
以启用安全引导。
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
运行以下命令重启
ds/osc-caa-ds
守护进程集:
Copy to clipboardCopied$ oc set env ds/osc-caa-ds \ -n openshift-sandboxed-containers-operator REBOOT="$(date)"
7.7. 自定义 Kata 代理策略
Kata 代理策略是一种安全机制,用于控制使用 Kata 运行时运行的 pod 的代理 API 请求。使用 Rego 编写并由 Pod 虚拟机(VM)中的 Kata 代理强制,此策略决定哪些操作被允许或拒绝。
默认情况下,Kata 代理策略禁用 exec
和日志
API,因为它们可能会通过 control plane 传输或接收未加密的数据,这是不安全的。
您可以针对特定用例使用自定义策略来覆盖默认策略,如在安全不是关注的地方进行开发和测试。例如,您可以在 control plane 可以被信任的环境中运行。您可以通过几种方法应用自定义策略:
- 将其嵌入到 pod 虚拟机镜像中。
- 修补对等 pod 配置映射。
- 为工作负载 pod YAML 添加注解。
对于生产环境系统,首选的方法是使用 initdata 覆盖 Kata 代理策略。以下流程使用 io.katacontainers.config.agent.policy
注解将自定义策略应用到单独的 pod。该策略以 Base64 编码的 Rego 格式提供。此方法会在创建 Pod 时覆盖默认策略,而不修改 pod 虚拟机镜像。
在机密容器工作负载中启用 exec
或 日志
API 可能会公开敏感信息。不要在生产环境中启用这些 API。
自定义策略完全替换了默认策略。要只修改特定的 API,请包含完整的策略并调整相关规则。
流程
使用自定义策略创建
policy.rego
文件。以下示例显示了所有可配置的 API,并且为演示启用了exec
和log
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ oc apply -f my-pod.yaml
7.8. 删除 KataConfig 自定义资源
您可以使用命令行删除 KataConfig
自定义资源(CR)。
删除 KataConfig
CR 会从集群中移除运行时及其相关资源。
删除 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
运行以下命令来删除
KataConfig
CR:
Copy to clipboardCopied$ oc delete kataconfig example-kataconfig
OpenShift 沙盒容器 Operator 会删除最初为在集群中启用运行时创建的所有资源。
重要当您删除
KataConfig
CR 时,CLI 会停止响应,直到所有 worker 节点重启为止。在执行验证前,您必须等待删除过程完成。运行以下命令验证自定义资源是否已删除:
Copy to clipboardCopied$ oc get kataconfig example-kataconfig
输出示例
Copy to clipboardCopiedNo example-kataconfig instances exist
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
7.9. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
通过添加
io.katacontainers.config.hypervisor.image
注解来编辑 pod 清单,并将其保存到pod-manifest.yaml
文件中:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc apply -f pod-manifest.yaml
7.10. 重新创建 KataConfig 自定义资源
您必须为机密容器重新创建 KataConfig
自定义资源(CR)。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
根据以下示例创建
example-kataconfig.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
,请指定键和值,例如cc: 'true'
。
运行以下命令来创建
KataConfig
CR:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
7.11. 创建信任身份验证 secret
您必须为 Trustee 创建身份验证 secret。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
运行以下命令来创建私钥:
Copy to clipboardCopied$ openssl genpkey -algorithm ed25519 > privateKey
运行以下命令来创建公钥:
Copy to clipboardCopied$ openssl pkey -in privateKey -pubout -out publicKey
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc create secret generic kbs-auth-public-key --from-file=publicKey -n trustee-operator-system
运行以下命令验证 secret:
Copy to clipboardCopied$ oc get secret -n trustee-operator-system
7.12. 创建信任配置映射
您必须创建配置映射来配置 Trustee 服务器。
以下配置示例关闭了安全功能,以启用技术预览功能演示。它不适用于生产环境。
先决条件
- 您已为 Trustee 创建了路由。
流程
创建
kbs-config-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: kbs-config-cm namespace: trustee-operator-system data: kbs-config.json: | { "insecure_http" : true, "sockets": ["0.0.0.0:8080"], "auth_public_key": "/etc/auth-secret/publicKey", "attestation_token_config": { "attestation_token_type": "CoCo" }, "repository_config": { "type": "LocalFs", "dir_path": "/opt/confidential-containers/kbs/repository" }, "as_config": { "work_dir": "/opt/confidential-containers/attestation-service", "policy_engine": "opa", "attestation_token_broker": "Simple", "attestation_token_config": { "duration_min": 5 }, "rvps_config": { "store_type": "LocalJson", "store_config": { "file_path": "/opt/confidential-containers/rvps/reference-values/reference-values.json" } } }, "policy_engine_config": { "policy_path": "/opt/confidential-containers/opa/policy.rego" } }
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f kbs-config-cm.yaml
7.13. 配置信任值、策略和 secret
您可以为 Trustee 配置以下值、策略和 secret:
- 可选:参考值提供程序服务的引用值。
- 可选: 验证策略。
- 为 Intel Trust Domain Extensions (TDX)置备证书缓存服务。
- 可选: Trustee 客户端的自定义密钥的 Secret。
- 可选:用于容器镜像签名验证的 Secret。
- 容器镜像签名验证策略。这个策略是必需的。如果不使用容器镜像签名验证,您必须创建一个不验证签名的策略。
- 资源访问策略。
7.13.1. 配置参考值
您可以通过指定硬件平台的可信摘要来配置参考值。
客户端从正在运行的软件、受信任的执行环境(TEE)硬件和固件中收集测量,并将声明中的引用提交到 Attestation Server。这些测量必须与注册到 Trustee 的可信摘要匹配。此过程可确保机密虚拟机(CVM)正在运行预期的软件堆栈,并且未被篡改。
流程
创建
rvps-configmap.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: rvps-reference-values namespace: trustee-operator-system data: reference-values.json: | [ 1 ]
- 1
- 如果需要,为您的硬件平台指定可信摘要。否则,将它留空。
运行以下命令来创建 RVPS 配置映射:
Copy to clipboardCopied$ oc apply -f rvps-configmap.yaml
7.13.2. 创建 attestation 策略
您可以创建一个 attestation 策略来覆盖默认的 attestation 策略。
流程
根据以下示例创建
attestation-policy.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: attestation-policy namespace: trustee-operator-system data: default.rego: | package policy 1 import future.keywords.every default allow = false allow { every k, v in input { judge_field(k, v) } } judge_field(input_key, input_value) { has_key(data.reference, input_key) reference_value := data.reference[input_key] match_value(reference_value, input_value) } judge_field(input_key, input_value) { not has_key(data.reference, input_key) } match_value(reference_value, input_value) { not is_array(reference_value) input_value == reference_value } match_value(reference_value, input_value) { is_array(reference_value) array_include(reference_value, input_value) } array_include(reference_value_array, input_value) { reference_value_array == [] } array_include(reference_value_array, input_value) { reference_value_array != [] some i reference_value_array[i] == input_value } has_key(m, k) { _ = m[k] }
- 1
- attestation 策略遵循 Open Policy Agent 规格。在本例中,attestation 策略将 attestation 报告中提供的声明与 RVPS 数据库中注册的引用值进行比较。只有所有值都匹配时才会成功 attestation 进程。
运行以下命令来创建 attestation 策略配置映射:
Copy to clipboardCopied$ oc apply -f attestation-policy.yaml
7.13.3. 为 TDX 配置 PCCS
如果使用 Intel Trust Domain Extensions (TDX),您必须将 Trustee 配置为使用 Provisioning Certificate Caching Service (PCCS)。
PCCS 检索配置认证密钥(PCK)证书,并将其缓存在本地数据库中。
不要使用公共 Intel PCCS 服务。在内部或公共云中使用本地缓存服务。
流程
根据以下示例创建
tdx-config.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: tdx-config namespace: trustee-operator-system data: sgx_default_qcnl.conf: | \ { "collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/", "pccs_url": "<pccs_url>" 1 }
- 1
- 指定 PCCS URL,例如
https://localhost:8081/sgx/certification/v4/
。
运行以下命令来创建 TDX 配置映射:
Copy to clipboardCopied$ oc apply -f tdx-config.yaml
7.13.4. 使用客户端自定义密钥创建 secret
您可以为 Trustee 客户端创建一个包含一个或多个自定义密钥的 secret。
在本例中,kbsres1
机密有两个条目(key
1、key2),
客户端会检索它们。您可以使用相同的格式根据您的要求添加额外的 secret。
先决条件
- 您已创建了一个或多个自定义密钥。
流程
根据以下示例,为自定义密钥创建 secret:
Copy to clipboardCopied$ oc apply secret generic kbsres1 \ --from-literal key1=<custom_key1> \ 1 --from-literal key2=<custom_key2> \ -n trustee-operator-system
- 1
- 指定自定义密钥。
kbsres1
secret 在KbsConfig
自定义资源的spec.kbsSecretResources
键中指定。
7.13.5. 为容器镜像签名验证创建 secret
如果使用容器镜像签名验证,您必须创建一个包含公共容器镜像签名密钥的 secret。
Confidential compute attestation Operator 使用 secret 来验证签名,确保环境中仅部署可信和经过身份验证的容器镜像。
您可以使用 Red Hat Trusted Artifact Signer 或其他工具为容器镜像签名。
流程
运行以下命令,为容器镜像签名验证创建 secret:
Copy to clipboardCopied$ oc apply secret generic <type> \ 1 --from-file=<tag>=./<public_key_file> \ 2 -n trustee-operator-system
-
记录 <
;type>
; 值。在创建KbsConfig
自定义资源时,您必须将这个值添加到spec.kbsSecretResources
键中。
7.13.6. 创建容器镜像签名验证策略
您可以创建容器镜像签名验证策略,因为始终启用签名验证。如果缺少此策略,则 pod 不会启动。
如果您不使用容器镜像签名验证,您可以在不签名验证的情况下创建策略。
如需更多信息,请参阅 containers-policy.json 5。
流程
根据以下示例创建
security-policy-config.json
文件:没有签名验证:
Copy to clipboardCopied{ "default": [ { "type": "insecureAcceptAnything" }], "transports": {} }
使用签名验证:
Copy to clipboardCopied{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "<transport>": { 1 "<registry>/<image>": 2 [ { "type": "sigstoreSigned", "keyPath": "kbs:///default/<type>/<tag>" 3 } ] } } }
运行以下命令来创建安全策略:
Copy to clipboardCopied$ oc apply secret generic security-policy \ --from-file=osc=./<security-policy-config.json> \ -n trustee-operator-system
不要更改机密类型
security-policy
或 key,osc
。security-policy
secret 在KbsConfig
自定义资源的spec.kbsSecretResources
键中指定。
7.13.7. 创建资源访问策略
您可以为 Trustee 策略引擎配置资源访问策略。此策略决定信任哪个资源可以访问。
Trustee 策略引擎与 Attestation Service 策略引擎不同,后者决定了 TEE 证据的有效性。
流程
创建
resourcepolicy-configmap.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: resource-policy namespace: trustee-operator-system data: policy.rego: | 1 package policy 2 default allow = false allow { input["tee"] != "sample" }
- 1
- 资源策略
policy.rego
的名称必须与 Trustee 配置映射中定义的资源策略匹配。 - 2
- 资源策略遵循 Open Policy Agent 规格。当 TEE 不是 tester 的示例时,此示例允许检索所有资源。
运行以下命令来创建资源策略配置映射:
Copy to clipboardCopied$ oc apply -f resourcepolicy-configmap.yaml
7.14. 创建 KbsConfig 自定义资源
您可以创建 KbsConfig
自定义资源(CR)来启动 Trustee。
然后,您可以检查 Trustee pod 和 pod 日志以验证配置。
流程
创建
kbsconfig-cr.yaml
清单文件:
Copy to clipboardCopiedapiVersion: confidentialcontainers.org/v1alpha1 kind: KbsConfig metadata: labels: app.kubernetes.io/name: kbsconfig app.kubernetes.io/instance: kbsconfig app.kubernetes.io/part-of: trustee-operator app.kubernetes.io/managed-by: kustomize app.kubernetes.io/created-by: trustee-operator name: kbsconfig namespace: trustee-operator-system spec: kbsConfigMapName: kbs-config-cm kbsAuthSecretName: kbs-auth-public-key kbsDeploymentType: AllInOneDeployment kbsRvpsRefValuesConfigMapName: rvps-reference-values kbsSecretResources: ["kbsres1", "security-policy", "<type>"] 1 kbsResourcePolicyConfigMapName: resource-policy # tdxConfigSpec: # kbsTdxConfigMapName: tdx-config 2 # kbsAttestationPolicyConfigMapName: attestation-policy 3 # kbsServiceType: <service_type> 4
- 1
- 可选:如果您创建了 secret,指定容器镜像签名验证 secret 的
type
值,如img-sig
。如果您没有创建 secret,将kbsSecretResources
值设置为["kbsres1", "security-policy
"]。 - 2
- 取消注释
tdxConfigSpec.kbsTdxConfigMapName: tdx-config
for Intel Trust Domain Extensions。 - 3
- 如果您创建了一个自定义的 attestation 策略,取消注释
kbsAttestationPolicyConfigMapName: attestation-policy
。 - 4
- 取消注释
kbsServiceType: <service_type
>,如果您创建服务类型,而不是默认ClusterIP
服务,以在集群外部流量中公开应用程序。您可以指定NodePort
、LoadBalancer
或ExternalName
。
运行以下命令来创建
KbsConfig
CR:
Copy to clipboardCopied$ oc apply -f kbsconfig-cr.yaml
7.15. 验证信任配置
您可以通过检查 Trustee pod 和 logs 来验证 Trustee 配置。
流程
运行以下命令来设置默认项目:
Copy to clipboardCopied$ oc project trustee-operator-system
运行以下命令检查 Trustee pod:
Copy to clipboardCopied$ oc get pods -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME READY STATUS RESTARTS AGE trustee-deployment-8585f98449-9bbgl 1/1 Running 0 22m trustee-operator-controller-manager-5fbd44cd97-55dlh 2/2 Running 0 59m
运行以下命令设置
POD_NAME
环境变量:
Copy to clipboardCopied$ POD_NAME=$(oc get pods -l app=kbs -o jsonpath='{.items[0].metadata.name}' -n trustee-operator-system)
运行以下命令检查 pod 日志:
Copy to clipboardCopied$ oc logs -n trustee-operator-system $POD_NAME
输出示例
Copy to clipboardCopied[2024-05-30T13:44:24Z INFO kbs] Using config file /etc/kbs-config/kbs-config.json [2024-05-30T13:44:24Z WARN attestation_service::rvps] No RVPS address provided and will launch a built-in rvps [2024-05-30T13:44:24Z INFO attestation_service::token::simple] No Token Signer key in config file, create an ephemeral key and without CA pubkey cert [2024-05-30T13:44:24Z INFO api_server] Starting HTTPS server at [0.0.0.0:8080] [2024-05-30T13:44:24Z INFO actix_server::builder] starting 12 workers [2024-05-30T13:44:24Z INFO actix_server::server] Tokio runtime found; starting in existing Tokio runtime
7.16. 验证测试过程
您可以通过创建测试 pod 并检索其机密来验证 attestation 过程。
此流程是验证 attestation 是否正常工作的示例。不要将敏感数据写入标准 I/O,因为可使用内存转储捕获数据。只有写入内存的数据才会被加密。
默认情况下,嵌入在 pod 虚拟机(VM)镜像中的 Kata 代理策略会禁用机密容器 pod 的 exec
和日志
API。此策略可防止集群管理员执行 pod 中的进程来减轻敏感数据,同时阻止意外将敏感数据写入标准 I/O。
在测试场景中,您可以通过向 pod 添加策略注解来覆盖运行时的限制。对于技术预览,远程测试不会验证运行时策略注解。
先决条件
- 如果 Trustee 服务器和测试 pod 没有在同一集群中运行,则已创建了路由。
流程
创建
verification-pod.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: ocp-cc-pod labels: app: ocp-cc-pod annotations: io.katacontainers.config.agent.policy: <base64_encoded_policy> 1 io.katacontainers.config.runtime.cc_init_data: <base64_initdata> 2 spec: runtimeClassName: kata-remote containers: - name: skr-openshift image: registry.access.redhat.com/ubi9/ubi:9.3 command: - sleep - "36000" securityContext: privileged: false seccompProfile: type: RuntimeDefault
如果您使用代理策略同时指定
io.katacontainers.config.agent.policy
注解和io.katacontainers.config.runtime.cc_init_data
注解,则 initdata 注解优先于代理策略注解。运行以下命令来创建 pod:
Copy to clipboardCopied$ oc create -f verification-pod.yaml
运行以下命令,连接到
ocp-cc-pod
的 Bash shell:
Copy to clipboardCopied$ oc exec -it ocp-cc-pod -- bash
运行以下命令来获取 pod secret:
Copy to clipboardCopied$ curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
输出示例
Copy to clipboardCopiedres1val1
只有当 attestation 成功时才会返回 secret。
第 8 章 在 IBM Z 和 IBM LinuxONE 上部署机密容器
在部署 OpenShift 沙盒容器后,您可以在 IBM Z® 和 IBM® LinuxONE 上部署机密容器。
IBM Z® 和 IBM® LinuxONE 上的机密容器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
集群要求
- 您已在安装 Confidential compute attestation Operator 的集群上安装了 Red Hat OpenShift Container Platform 4.15 或更高版本。
LPAR 要求
- 您有 LinuxONE Emperor 4。
- 您已在逻辑分区(LPAR)上启用了安全 Unpack Facility,这是 IBM Secure Execution 所必需的。如需更多信息,请参阅为 IBM 安全执行启用 KVM 主机。
您可以执行以下步骤来部署机密容器:
- 安装 Confidential compute attestation Operator。
- 为 Trustee 创建路由。
- 启用机密容器功能门。
- 创建 initdata。
- 更新对等 pod 配置映射。
- 可选:自定义 Kata 代理策略。
-
删除
KataConfig
自定义资源(CR)。 - 更新对等 pod secret。
- 可选: 选择自定义对等 pod 虚拟机镜像。
-
重新创建
KataConfig
CR。 - 创建 Trustee 身份验证 secret。
- 创建 Trustee 配置映射。
- 获取 IBM Secure Execution (SE)标头。
- 配置 SE 证书和密钥。
- 创建持久性存储组件。
- 配置 Trustee 值、策略和 secret。
-
创建
KbsConfig
CR。 - 验证 Trustee 配置。
- 验证 attestation 进程。
8.1. 安装 Confidential compute attestation Operator
您可以使用 CLI 在 IBM Z® 和 IBM® LinuxONE 上安装 Confidential compute attestation Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建
trustee-namespace.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Namespace metadata: name: trustee-operator-system
运行以下命令来创建
trustee-operator-system
命名空间:
Copy to clipboardCopied$ oc apply -f trustee-namespace.yaml
创建
trustee-operatorgroup.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: trustee-operator-group namespace: trustee-operator-system spec: targetNamespaces: - trustee-operator-system
运行以下命令来创建 operator 组:
Copy to clipboardCopied$ oc apply -f trustee-operatorgroup.yaml
创建
trustee-subscription.yaml
清单文件:
Copy to clipboardCopiedapiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: trustee-operator-system namespace: trustee-operator-system spec: channel: stable installPlanApproval: Automatic name: trustee-operator source: trustee-operator-catalog sourceNamespace: openshift-marketplace
运行以下命令来创建订阅:
Copy to clipboardCopied$ oc apply -f trustee-subscription.yaml
运行以下命令验证 Operator 是否已正确安装:
Copy to clipboardCopied$ oc get csv -n trustee-operator-system
此命令可能需要几分钟来完成。
运行以下命令监控进程:
Copy to clipboardCopied$ watch oc get csv -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME DISPLAY PHASE trustee-operator.v0.3.0 Trustee Operator 0.3.0 Succeeded
8.2. 启用机密容器功能门
您必须启用 Confidential Containers 功能门。
先决条件
- 已订阅 OpenShift 沙盒容器 Operator。
流程
创建
cc-feature-gate.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: osc-feature-gates namespace: openshift-sandboxed-containers-operator data: confidential: "true"
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f cc-feature-gate.yaml
8.3. 为 Trustee 创建路由
您可以为 Trustee 使用边缘 TLS 终止创建安全路由。外部入口流量以 HTTPS 的形式到达路由器 pod,并以 HTTP 的形式传递给 Trustee pod。
先决条件
- 已安装 Confidential compute attestation Operator。
流程
运行以下命令来创建边缘路由:
Copy to clipboardCopied$ oc create route edge --service=kbs-service --port kbs-port \ -n trustee-operator-system
注意注: 目前,只支持带有有效 CA 签名证书的路由。您不能使用带有自签名证书的路由。
运行以下命令设置
TRUSTEE_HOST
变量:
Copy to clipboardCopied$ TRUSTEE_HOST=$(oc get route -n trustee-operator-system kbs-service \ -o jsonpath={.spec.host})
运行以下命令验证路由:
Copy to clipboardCopied$ echo $TRUSTEE_HOST
输出示例
Copy to clipboardCopiedkbs-service-trustee-operator-system.apps.memvjias.eastus.aroapp.io
8.4. 关于 initdata
initdata 规格提供了一种灵活的方法,来在运行时初始化具有敏感或特定工作负载的对等 pod,以避免在虚拟机(VM)镜像中嵌入此类数据。这通过减少机密信息暴露并通过删除自定义镜像构建来提高灵活性来提高安全性。例如,initdata 可以包含三个配置设置:
- 用于安全通信的 X.509 证书。
- 用于身份验证的加密密钥。
-
可选的 Kata Agent
policy.rego
文件,在覆盖默认的 Kata Agent 策略时强制执行运行时行为。
您可以使用以下方法之一应用 initdata 配置:
- 通过在对等 pod 配置映射中包括它,为所有 pod 设置集群范围的默认值。
在配置 pod 工作负载对象时,对于特定的 pod,可以自定义单个工作负载。
您在配置 pod 工作负载对象时指定的
io.katacontainers.config.runtime.cc_init_data
注解会覆盖该特定 pod 的对等 pod 配置映射中的全局INITDATA
设置。Kata 运行时在创建 pod 时自动处理这个优先级。
initdata 内容配置以下组件:
- attestation Agent (AA),它通过向信任者发送证据来验证对等 pod 的可信度。
- 机密数据 Hub (CDH),用于管理对等 pod 虚拟机中的 secret 和保护数据访问。
- Kata Agent,它强制执行运行时策略并管理 pod 虚拟机内容器的生命周期。
8.5. 创建 initdata
使用 initdata 创建 TOML 文件,并将其转换为 Base64 编码的字符串。使用此字符串指定对等 pod 配置映射中的值,在 peer pod 清单中,或者在 busybox.yaml
文件中指定。
如果在 Trustee 配置映射中配置 insecure_http = true
,您必须删除 kbs_cert
设置。
流程
运行以下命令来获取信任 IP 地址:
Copy to clipboardCopied$ oc get node $(oc get pod -n trustee-operator-system -o jsonpath='{.items[0].spec.nodeName}') -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}'
输出示例
Copy to clipboardCopied192.168.122.22
运行以下命令来获取 Trustee 端口:
Copy to clipboardCopied$ oc get svc kbs-service -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kbs-service NodePort 172.30.116.11 <none> 8080:32178/TCP 12d
创建
initdata.toml
配置文件:
Copy to clipboardCopied```toml algorithm = "sha384" version = "0.1.0" [data] "aa.toml" = ''' [token_configs] [token_configs.coco_as] url = 'https://<worker_node_ip>:<node_port>' 1 [token_configs.kbs] url = 'https://<worker_node_ip>:<node_port>' cert = """ -----BEGIN CERTIFICATE----- <kbs_certificate> 2 -----END CERTIFICATE----- """ ''' "cdh.toml" = ''' socket = 'unix:///run/confidential-containers/cdh.sock' credentials = [] [kbc] name = 'cc_kbc' url = 'https://<worker_node_ip>:<node_port>' kbs_cert = """ 3 -----BEGIN CERTIFICATE----- <kbs_certificate> 4 -----END CERTIFICATE----- """ ''' "policy.rego" = ''' 5 package agent_policy default AddARPNeighborsRequest := true default AddSwapRequest := true default CloseStdinRequest := true default CopyFileRequest := true default CreateContainerRequest := true default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true default GetMetricsRequest := true default GetOOMEventRequest := true default GuestDetailsRequest := true default ListInterfacesRequest := true default ListRoutesRequest := true default MemHotplugByProbeRequest := true default OnlineCPUMemRequest := true default PauseContainerRequest := true default PullImageRequest := true default ReadStreamRequest := true default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default ReseedRandomDevRequest := true default ResumeContainerRequest := true default SetGuestDateTimeRequest := true default SetPolicyRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StartTracingRequest := true default StatsContainerRequest := true default StopTracingRequest := true default TtyWinResizeRequest := true default UpdateContainerRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := true ''' ```
运行以下命令,将
initdata.toml
文件转换为文本文件中的 Base64 编码字符串:
Copy to clipboardCopied$ base64 -w0 initdata.toml > initdata.txt
8.6. 更新对等 pod 配置映射
您必须为机密容器更新对等 pod 配置映射。
将安全引导设置为 true
以默认启用。默认值为 false
,这代表存在安全风险。
流程
根据以下示例创建
peer-pods-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "libvirt" PEERPODS_LIMIT_PER_NODE: "10" 1 LIBVIRT_POOL: "<libvirt_pool>" 2 LIBVIRT_VOL_NAME: "<libvirt_volume>" 3 LIBVIRT_DIR_NAME: "/var/lib/libvirt/images/<directory_name>" 4 LIBVIRT_NET: "default" 5 INITDATA: "<base64_encoded_initdata>" 6 DISABLECVM: "false"
- 1
- 指定每个节点可以创建的对等 pod 的最大数量。默认值为
10
。 - 2
- 指定 libvirt 池。如果您手动配置了 libvirt 池,请使用与 KVM 主机配置相同的名称。
- 3
- 指定 libvirt 卷名称。如果您手动配置 libvirt 卷,请使用与 KVM 主机配置相同的名称。
- 4
- 指定用于存储虚拟机磁盘镜像的 libvirt 目录,如
.qcow2
或.raw
文件。为确保 libvirt 具有读写访问权限,请使用 libvirt 存储目录的子目录。默认为/var/lib/libvirt/images/
。 - 5
- 可选:如果您不想使用默认网络,请指定 libvirt 网络。
- 6
- 指定您在
initdata.txt
文件中创建的 Base64 编码字符串。
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f peer-pods-cm.yaml
运行以下命令重启
ds/osc-caa-ds
守护进程集:
Copy to clipboardCopied$ oc set env ds/osc-caa-ds \ -n openshift-sandboxed-containers-operator REBOOT="$(date)"
8.7. 自定义 Kata 代理策略
Kata 代理策略是一种安全机制,用于控制使用 Kata 运行时运行的 pod 的代理 API 请求。使用 Rego 编写并由 Pod 虚拟机(VM)中的 Kata 代理强制,此策略决定哪些操作被允许或拒绝。
默认情况下,Kata 代理策略禁用 exec
和日志
API,因为它们可能会通过 control plane 传输或接收未加密的数据,这是不安全的。
您可以针对特定用例使用自定义策略来覆盖默认策略,如在安全不是关注的地方进行开发和测试。例如,您可以在 control plane 可以被信任的环境中运行。您可以通过几种方法应用自定义策略:
- 将其嵌入到 pod 虚拟机镜像中。
- 修补对等 pod 配置映射。
- 为工作负载 pod YAML 添加注解。
对于生产环境系统,首选的方法是使用 initdata 覆盖 Kata 代理策略。以下流程使用 io.katacontainers.config.agent.policy
注解将自定义策略应用到单独的 pod。该策略以 Base64 编码的 Rego 格式提供。此方法会在创建 Pod 时覆盖默认策略,而不修改 pod 虚拟机镜像。
在机密容器工作负载中启用 exec
或 日志
API 可能会公开敏感信息。不要在生产环境中启用这些 API。
自定义策略完全替换了默认策略。要只修改特定的 API,请包含完整的策略并调整相关规则。
流程
使用自定义策略创建
policy.rego
文件。以下示例显示了所有可配置的 API,并且为演示启用了exec
和log
:
Copy to clipboardCopiedpackage 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 编码的字符串:
Copy to clipboardCopied$ base64 -w0 policy.rego
将输出保存到 yaml 文件中。
将 Base64 编码的策略添加到
my-pod.yaml
pod 规格文件中:
Copy to clipboardCopiedapiVersion: 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 清单:
Copy to clipboardCopied$ oc apply -f my-pod.yaml
8.8. 删除 KataConfig 自定义资源
您可以使用命令行删除 KataConfig
自定义资源(CR)。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
运行以下命令来删除
KataConfig
CR:
Copy to clipboardCopied$ oc delete kataconfig example-kataconfig
运行以下命令验证自定义资源是否已删除:
Copy to clipboardCopied$ oc get kataconfig example-kataconfig
输出示例
Copy to clipboardCopiedNo example-kataconfig instances exist
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
8.9. 更新对等 pod secret
如果对等 pod secret 为空并安装 Cloud Credential Operator (CCO),OpenShift 沙盒容器 Operator 会使用 CCO 检索 secret。如果您卸载了 CCO,您必须手动更新对等容器的对等 pod secret,否则对等 pod 将无法操作。
secret 存储用于创建 pod 虚拟机(VM)镜像和对等 pod 实例的凭证。
默认情况下,OpenShift 沙盒容器 Operator 根据用于创建集群的凭证创建 secret。但是,您可以手动创建使用不同的凭证的 secret。
先决条件
-
红帽_OFFLINE_TOKEN
.您已生成此令牌,以通过 Red Hat API Tokens 下载 RHEL 镜像。 -
HOST_KEY_CERTS
.Host Key Document (HKD)证书在 IBM Z® 上启用安全执行。如需更多信息,请参阅 IBM 文档中的资源链接中的获取 主机密钥文档。
流程
根据以下示例创建
peer-pods-secret.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: CLOUD_PROVIDER: "libvirt" LIBVIRT_URI: "<libvirt_gateway_uri>" 1 REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 2 HOST_KEY_CERTS: "<host_key_crt_value>" 3
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc apply -f peer-pods-secret.yaml
8.10. 选择自定义对等 pod 虚拟机镜像
您可以通过向 pod 清单添加注解来选择自定义对等 pod 虚拟机(VM)镜像,根据您的工作负载要求量身定制。自定义镜像覆盖对等 pod 配置映射中指定的默认镜像。您可以在 libvirt 池中创建新的 libvirt 卷,并将自定义对等 pod 虚拟机镜像上传到新卷。然后,您将 pod 清单更新为使用自定义对等 pod 虚拟机镜像。
先决条件
- 要使用的自定义 pod 虚拟机镜像的 ID,与云供应商或 hypervisor 兼容。
流程
运行以下命令设置 libvirt 池的名称:
Copy to clipboardCopied$ export LIBVIRT_POOL=<libvirt_pool> 1
- 1
- 指定现有的 libvirt 池名称。
运行以下命令,设置新 libvirt 卷的名称:
Copy to clipboardCopied$ export LIBVIRT_VOL_NAME=<new_libvirt_volume>
运行以下命令,为池创建 libvirt 卷:
Copy to clipboardCopied$ virsh -c qemu:///system \ vol-create-as --pool $LIBVIRT_POOL \ --name $LIBVIRT_VOL_NAME \ --capacity 20G \ --allocation 2G \ --prealloc-metadata \ --format qcow2
将自定义对等 pod 虚拟机镜像上传到 libvirt 卷:
Copy to clipboardCopied$ virsh -c qemu:///system vol-upload \ --vol $LIBVIRT_VOL_NAME <custom_podvm_image.qcow2> \ 1 --pool $LIBVIRT_POOL --sparse
- 1
- 指定自定义 peer pod VM 镜像名称。
根据以下示例创建
pod-manifest.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<new_libvirt_volume>" 1 spec: runtimeClassName: kata-remote 2 containers: - name: <example_container> 3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc apply -f pod-manifest.yaml
8.11. 重新创建 KataConfig 自定义资源
您必须为机密容器重新创建 KataConfig
自定义资源(CR)。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
根据以下示例创建
example-kataconfig.yaml
清单文件:
Copy to clipboardCopiedapiVersion: 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
,请指定键和值,例如cc: 'true'
。
运行以下命令来创建
KataConfig
CR:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令,验证您是否已构建对等 pod 镜像并将其上传到 libvirt 卷中:
Copy to clipboardCopied$ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
输出示例
Copy to clipboardCopiedName: peer-pods-cm Namespace: openshift-sandboxed-containers-operator Labels: <none> Annotations: <none> Data ==== CLOUD_PROVIDER: libvirt DISABLECVM: false 1 LIBVIRT_IMAGE_ID: fa-pp-vol 2 BinaryData ==== Events: <none>
运行以下命令,监控
kata-oc
机器配置池进度,以确保它处于UPDATED
状态,当UPDATED
等于 MACHINECOUNT 时:MACHINECOUNT
Copy to clipboardCopied$ watch oc get mcp/kata-oc
运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
8.12. 创建信任身份验证 secret
您必须为 Trustee 创建身份验证 secret。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
运行以下命令来创建私钥:
Copy to clipboardCopied$ openssl genpkey -algorithm ed25519 > privateKey
运行以下命令来创建公钥:
Copy to clipboardCopied$ openssl pkey -in privateKey -pubout -out publicKey
运行以下命令来创建 secret:
Copy to clipboardCopied$ oc create secret generic kbs-auth-public-key --from-file=publicKey -n trustee-operator-system
运行以下命令验证 secret:
Copy to clipboardCopied$ oc get secret -n trustee-operator-system
8.13. 创建信任配置映射
您必须创建配置映射来配置 Trustee 服务器。
以下配置示例关闭了安全功能,以启用技术预览功能演示。它不适用于生产环境。
先决条件
- 您已为 Trustee 创建了路由。
流程
创建
kbs-config-cm.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: kbs-config-cm namespace: trustee-operator-system data: kbs-config.toml: | [http_server] sockets = ["0.0.0.0:8080"] insecure_http = false private_key = "/etc/https-key/https.key" certificate = "/etc/https-cert/https.crt" [admin] insecure_api = false auth_public_key = "/etc/auth-secret/publicKey" [attestation_token] insecure_key = true attestation_token_type = "CoCo" [attestation_service] type = "coco_as_builtin" work_dir = "/opt/confidential-containers/attestation-service" policy_engine = "opa" [attestation_service.attestation_token_broker] type = "Simple" policy_dir = "/opt/confidential-containers/attestation-service/policies" [attestation_service.attestation_token_config] duration_min = 5 [attestation_service.rvps_config] type = "BuiltIn" [attestation_service.rvps_config.storage] type = "LocalJson" file_path = "/opt/confidential-containers/rvps/reference-values/reference-values.json" [[plugins]] name = "resource" type = "LocalFs" dir_path = "/opt/confidential-containers/kbs/repository" [policy_engine] policy_path = "/opt/confidential-containers/opa/policy.rego"
运行以下命令来创建配置映射:
Copy to clipboardCopied$ oc apply -f kbs-config-cm.yaml
8.14. 配置 IBM 安全执行证书和密钥
您必须为 worker 节点配置 IBM Secure Execution (SE)证书和密钥。
先决条件
- 有堡垒节点的 IP 地址。
- 您有 worker 节点的内部 IP 地址。
流程
通过执行以下步骤生成 Key Broker 服务(KBS)证书和密钥:
根据以下示例创建
kbs.conf
配置文件:
Copy to clipboardCopied[req] default_bits = 2048 default_keyfile = localhost.key distinguished_name = req_distinguished_name req_extensions = req_ext x509_extensions = v3_ca [req_distinguished_name] countryName = Country Name (2-letter code) countryName_default = <country_name> stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = <state_name> localityName = Locality Name (eg, city) localityName_default = <locality_name> organizationName = Organization Name (eg, company) organizationName_default = Red Hat organizationalUnitName = organizationalunit organizationalUnitName_default = Development commonName = Common Name (e.g. server FQDN or YOUR name) commonName_default = kbs-service commonName_max = 64 [req_ext] subjectAltName = @alt_names [v3_ca] subjectAltName = @alt_names [alt_names] IP.1 = <trustee_ip> DNS.1 = localhost DNS.2 = 127.0.0.1
运行以下命令生成 KBS 密钥和自签名证书:
Copy to clipboardCopiedopenssl req -x509 -nodes -days 365 \ -newkey rsa:2048 \ -keyout kbs.key \ -out kbs.crt \ -config kbs.conf \ -passin pass:
运行以下命令,将 KBS 密钥复制到
ibmse
目录中:
Copy to clipboardCopied$ cp kbs.key /tmp/ibmse/kbs.key
运行以下命令,将 KBS 证书复制到
ibmse
目录中:
Copy to clipboardCopied$ cp kbs.crt /tmp/ibmse/kbs.crt
通过执行以下步骤来获取 attestation 策略字段:
运行以下命令,创建一个目录来下载
GetRvps.sh
脚本:
Copy to clipboardCopied$ mkdir -p Rvps-Extraction/
运行以下命令来下载脚本:
Copy to clipboardCopied$ wget https://github.com/openshift/sandboxed-containers-operator/raw/devel/scripts/rvps-extraction/GetRvps.sh -O $PWD/GetRvps.sh
运行以下命令来创建子目录:
Copy to clipboardCopied$ mkdir -p Rvps-Extraction/static-files
运行以下命令进入
static-files
目录:
Copy to clipboardCopied$ cd Rvps-Extraction/static-files
运行以下命令下载
pvextract-hdr
工具:
Copy to clipboardCopied$ wget https://github.com/openshift/sandboxed-containers-operator/raw/devel/scripts/rvps-extraction/static-files/pvextract-hdr -O $PWD/pvextract-hdr
运行以下命令使工具可执行:
Copy to clipboardCopied$ chmod +x pvextract-hdr
运行以下命令下载
se_parse_hdr.py
脚本:
Copy to clipboardCopied$ wget https://github.com/openshift/sandboxed-containers-operator/raw/devel/scripts/rvps-extraction/static-files/se_parse_hdr.py -O $PWD/se_parse_hdr.py
运行以下命令,将主机密钥文档(HKD)证书复制到
static-files
目录中:
Copy to clipboardCopied$ cp ~/path/to/<hkd_cert.crt> .
static-files
目录包含以下文件:-
HKD.crt
-
pvextract-hdr
-
se_parse_hdr.py
-
运行以下命令进入
Rvps-Extraction
目录:
Copy to clipboardCopied$ cd ..
运行以下命令使
GetRvps.sh
脚本可执行:
Copy to clipboardCopied$ chmod +x GetRvps.sh
运行脚本:
Copy to clipboardCopied$ ./GetRvps.sh
输出示例
Copy to clipboardCopied***Installing necessary packages for RVPS values extraction *** Updating Subscription Management repositories. Last metadata expiration check: 0:37:12 ago on Mon Nov 18 09:20:29 2024. Package python3-3.9.19-8.el9_5.1.s390x is already installed. Package python3-cryptography-36.0.1-4.el9.s390x is already installed. Package kmod-28-10.el9.s390x is already installed. Dependencies resolved. Nothing to do. Complete! ***Installation Finished *** 1) Generate the RVPS From Local Image from User pc 2) Generate RVPS from Volume 3) Quit Please enter your choice:
输入
2
从卷生成参考值提供程序服务:
Copy to clipboardCopiedPlease enter your choice: 2
为 libvirt 池名称输入
fa-pp
:
Copy to clipboardCopiedEnter the Libvirt Pool Name: fa-pp
输入 libvirt 网关 URI:
Copy to clipboardCopiedEnter the Libvirt URI Name: <libvirt-uri> 1
- 1
- 指定用于创建 对等 pod secret 的
LIBVIRT_URI
值。
为 libvirt 卷名称输入
fa-pp-vol
:
Copy to clipboardCopiedEnter the Libvirt Volume Name: fa-pp-vol
输出示例
Copy to clipboardCopiedDownloading from PODVM Volume... mount: /mnt/myvm: special device /dev/nbd3p1 does not exist. Error: Failed to mount the image. Retrying... Mounting on second attempt passed /dev/nbd3 disconnected SE header found at offset 0x014000 SE header written to '/root/Rvps-Extraction/output-files/hdr.bin' (640 bytes) se.tag: 42f3fe61e8a7e859cab3bb033fd11c61 se.image_phkh: 92d0aff6eb86719b6b1ea0cb98d2c99ff2ec693df3efff2158f54112f6961508 provenance = ewogICAgInNlLmF0dGVzdGF0aW9uX3Boa2giOiBbCiAgICAgICAgIjkyZDBhZmY2ZWI4NjcxOWI2YjFlYTBjYjk4ZDJjOTlmZjJlYzY5M2RmM2VmZmYyMTU4ZjU0MTEyZjY5NjE1MDgiCiAgICBdLAogICAgInNlLnRhZyI6IFsKICAgICAgICAiNDJmM2ZlNjFlOGE3ZTg1OWNhYjNiYjAzM2ZkMTFjNjEiCiAgICBdLAogICAgInNlLmltYWdlX3Boa2giOiBbCiAgICAgICAgIjkyZDBhZmY2ZWI4NjcxOWI2YjFlYTBjYjk4ZDJjOTlmZjJlYzY5M2RmM2VmZmYyMTU4ZjU0MTEyZjY5NjE1MDgiCiAgICBdLAogICAgInNlLnVzZXJfZGF0YSI6IFsKICAgICAgICAiMDAiCiAgICBdLAogICAgInNlLnZlcnNpb24iOiBbCiAgICAgICAgIjI1NiIKICAgIF0KfQo= -rw-r--r--. 1 root root 640 Dec 16 10:57 /root/Rvps-Extraction/output-files/hdr.bin -rw-r--r--. 1 root root 446 Dec 16 10:57 /root/Rvps-Extraction/output-files/ibmse-policy.rego -rw-r--r--. 1 root root 561 Dec 16 10:57 /root/Rvps-Extraction/output-files/se-message
通过执行以下步骤来获取证书和证书撤销列表(CRL):
运行以下命令,为证书创建一个临时目录:
Copy to clipboardCopied$ mkdir /tmp/ibmse/certs
运行以下命令,下载
ibm-z-host-key-signing-gen2.crt
证书:
Copy to clipboardCopied$ wget https://www.ibm.com/support/resourcelink/api/content/public/ibm-z-host-key-signing-gen2.crt -O /tmp/ibmse/certs/ibm-z-host-key-signing-gen2.crt
运行以下命令下载
DigiCertCA.crt
证书:
Copy to clipboardCopied$ wget https://www.ibm.com/support/resourcelink/api/content/public/DigiCertCA.crt -O /tmp/ibmse/certs/DigiCertCA.crt
运行以下命令,为 CRL 创建临时目录:
Copy to clipboardCopied$ mkdir /tmp/ibmse/crls
运行以下命令,下载
ibm-z-host-key-gen2.crl
文件:
Copy to clipboardCopied$ wget https://www.ibm.com/support/resourcelink/api/content/public/ibm-z-host-key-gen2.crl -O /tmp/ibmse/crls/ibm-z-host-key-gen2.crl
运行以下命令下载
DigiCertTrustedRootG4.crl
文件:
Copy to clipboardCopied$ wget http://crl3.digicert.com/DigiCertTrustedRootG4.crl -O /tmp/ibmse/crls/DigiCertTrustedRootG4.crl
运行以下命令下载
DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
文件:
Copy to clipboardCopied$ wget http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl -O /tmp/ibmse/crls/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
运行以下命令,为
hdr.bin
文件创建一个临时目录:
Copy to clipboardCopied$ mkdir -p /tmp/ibmse/hdr/
运行以下命令,将
hdr
.bin
Copy to clipboardCopied$ cp /root/Rvps-Extraction/output-files/hdr.bin /tmp/ibmse/hdr/
运行以下命令,为主机密钥文档(HKD)证书创建一个临时目录:
Copy to clipboardCopied$ mkdir -p /tmp/ibmse/hkds
运行以下命令,将 HKD 证书复制到
hkds
目录中:
Copy to clipboardCopied$ cp ~/path/to/<hkd_cert.crt> /tmp/ibmse/hkds/
生成 RSA 密钥:
运行以下命令来生成 RSA 密钥对:
Copy to clipboardCopied$ openssl genrsa -aes256 -passout pass:<password> -out /tmp/encrypt_key-psw.pem 4096 1
- 1
- 指定 RSA 密钥密码。
运行以下命令,为 RSA 密钥创建一个临时目录:
Copy to clipboardCopied$ mkdir -p /tmp/ibmse/rsa
运行以下命令来创建
encrypt_key.pub
密钥:
Copy to clipboardCopied$ openssl rsa -in /tmp/encrypt_key-psw.pem -passin pass:<password> -pubout -out /tmp/ibmse/rsa/encrypt_key.pub
运行以下命令来创建
encrypt_key.pem
密钥:
Copy to clipboardCopied$ openssl rsa -in /tmp/encrypt_key-psw.pem -passin pass:<password> -out /tmp/ibmse/rsa/encrypt_key.pem
运行以下命令,验证
/tmp/ibmse
目录的结构:
Copy to clipboardCopied$ tree /tmp/ibmse
输出示例
Copy to clipboardCopied/tmp/ibmse ├──kbs.key ├──kbs.crt | ├── certs │ ├── ibm-z-host-key-signing-gen2.crt | └── DigiCertCA.crt ├── crls │ └── ibm-z-host-key-gen2.crl │ └── DigiCertTrustedRootG4.crl │ └── DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl ├── hdr │ └── hdr.bin ├── hkds │ └── <hkd_cert.crt> └── rsa ├── encrypt_key.pem └── encrypt_key.pub
通过执行以下步骤将这些文件复制到 OpenShift Container Platform worker 节点:
运行以下命令,从
/tmp/ibmse
目录创建一个压缩文件:
Copy to clipboardCopied$ tar -czf ibmse.tar.gz -C /tmp/ ibmse
运行以下命令,将
.tar.gz
文件复制到集群中的堡垒节点:
Copy to clipboardCopied$ scp /tmp/ibmse.tar.gz root@<ocp_bastion_ip>:/tmp 1
- 1
- 指定堡垒节点的 IP 地址。
运行以下命令,通过 SSH 连接到 bastion 节点:
Copy to clipboardCopied$ ssh root@<ocp_bastion_ip>
运行以下命令,将
.tar.gz
文件复制到每个 worker 节点:
Copy to clipboardCopied$ scp /tmp/ibmse.tar.gz core@<worker_node_ip>:/tmp 1
- 1
- 指定 worker 节点的 IP 地址。
运行以下命令,提取每个 worker 节点上的
.tar.gz
:
Copy to clipboardCopied$ ssh core@<worker_node_ip> 'sudo mkdir -p /opt/confidential-containers/ && sudo tar -xzf /tmp/ibmse.tar.gz -C /opt/confidential-containers/'
运行以下命令更新
ibmse
文件夹权限:
Copy to clipboardCopied$ ssh core@<worker_node_ip> 'sudo chmod -R 755 /opt/confidential-containers/ibmse/'
通过执行以下步骤,使用 KBS 密钥和证书在集群中创建 secret:
根据以下示例创建
kbs-https-certificate.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: kbs-https-certificate namespace: trustee-operator-system data: https.crt: $(cat /tmp/ibmse/kbs.crt | base64 -w 0)
运行以下命令,使用 KBS 证书创建 secret:
Copy to clipboardCopied$ oc apply -f kbs-https-certificate.yaml
根据以下示例创建
kbs-https-key.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Secret metadata: name: kbs-https-key namespace: trustee-operator-system data: https.key: $(cat /tmp/ibmse/kbs.key | base64 -w 0)
运行以下命令,使用 KBS 密钥创建 secret:
Copy to clipboardCopied$ oc apply -f kbs-https-key.yaml
8.15. 创建持久性存储组件
您必须创建持久性存储组件、持久性卷(PV)和持久性卷声明(PVC),以便将 ibmse
文件夹挂载到 Trustee pod。
流程
创建
persistent-volume.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: PersistentVolume metadata: name: ibmse-pv namespace: trustee-operator-system spec: capacity: storage: 100Mi accessModes: - ReadOnlyMany storageClassName: "" local: path: /opt/confidential-containers/ibmse nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/worker operator: Exists
运行以下命令来创建持久性卷:
Copy to clipboardCopied$ oc apply -f persistent-volume.yaml
创建
persistent-volume-claim.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: PersistentVolumeClaim metadata: name: ibmse-pvc namespace: trustee-operator-system spec: accessModes: - ReadOnlyMany storageClassName: "" resources: requests: storage: 100Mi
运行以下命令来创建持久性卷声明:
Copy to clipboardCopied$ oc apply -f persistent-volume-claim.yaml
8.16. 配置信任值、策略和 secret
您可以为 Trustee 配置以下值、策略和 secret:
- Reference Value Provider Service 的引用值。
- IBM Secure Execution 的测试策略。
- Trustee 客户端的自定义密钥 secret。
- 用于容器镜像签名验证的 secret。
- 容器镜像签名验证策略。这个策略是必需的。如果不使用容器镜像签名验证,您必须创建一个不验证签名的策略。
- 资源访问策略。
8.16.1. 配置参考值
您可以通过指定硬件平台的可信摘要来配置参考值。
客户端从正在运行的软件、受信任的执行环境(TEE)硬件和固件中收集测量,并将声明中的引用提交到 Attestation Server。这些测量必须与注册到 Trustee 的可信摘要匹配。此过程可确保机密虚拟机(CVM)正在运行预期的软件堆栈,并且未被篡改。
流程
创建
rvps-configmap.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: rvps-reference-values namespace: trustee-operator-system data: reference-values.json: | [ 1 ]
- 1
- 该值留空。
运行以下命令来创建 RVPS 配置映射:
Copy to clipboardCopied$ oc apply -f rvps-configmap.yaml
8.16.2. 为 IBM 安全执行创建 attestation 策略
您必须为 IBM Secure Execution 创建 attestation 策略。
流程
创建
attestation-policy.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: attestation-policy namespace: trustee-operator-system data: default.rego: | 1 package policy import rego.v1 default allow = false converted_version := sprintf("%v", [input["se.version"]]) allow if { input["se.attestation_phkh"] == "<se.attestation_phkh>" 2 input["se.image_phkh"] == "<se.image_phkh>" input["se.tag"] == "<se.tag>" converted_version == "256" }
运行以下命令来创建 attestation 策略配置映射:
Copy to clipboardCopied$ oc apply -f attestation-policy.yaml
8.16.3. 使用客户端自定义密钥创建 secret
您可以为 Trustee 客户端创建一个包含一个或多个自定义密钥的 secret。
在本例中,kbsres1
机密有两个条目(key
1、key2),
客户端会检索它们。您可以使用相同的格式根据您的要求添加额外的 secret。
先决条件
- 您已创建了一个或多个自定义密钥。
流程
根据以下示例,为自定义密钥创建 secret:
Copy to clipboardCopied$ oc apply secret generic kbsres1 \ --from-literal key1=<custom_key1> \ 1 --from-literal key2=<custom_key2> \ -n trustee-operator-system
- 1
- 指定自定义密钥。
kbsres1
secret 在KbsConfig
自定义资源的spec.kbsSecretResources
键中指定。
8.16.4. 为容器镜像签名验证创建 secret
如果使用容器镜像签名验证,您必须创建一个包含公共容器镜像签名密钥的 secret。
Confidential compute attestation Operator 使用 secret 来验证签名,确保环境中仅部署可信和经过身份验证的容器镜像。
您可以使用 Red Hat Trusted Artifact Signer 或其他工具为容器镜像签名。
流程
运行以下命令,为容器镜像签名验证创建 secret:
Copy to clipboardCopied$ oc apply secret generic <type> \ 1 --from-file=<tag>=./<public_key_file> \ 2 -n trustee-operator-system
-
记录 <
;type>
; 值。在创建KbsConfig
自定义资源时,您必须将这个值添加到spec.kbsSecretResources
键中。
8.16.5. 创建容器镜像签名验证策略
您可以创建容器镜像签名验证策略,因为始终启用签名验证。如果缺少此策略,则 pod 不会启动。
如果您不使用容器镜像签名验证,您可以在不签名验证的情况下创建策略。
如需更多信息,请参阅 containers-policy.json 5。
流程
根据以下示例创建
security-policy-config.json
文件:没有签名验证:
Copy to clipboardCopied{ "default": [ { "type": "insecureAcceptAnything" }], "transports": {} }
使用签名验证:
Copy to clipboardCopied{ "default": [ ], "transports": { "docker": { "<container_registry_url>/<username>/busybox:latest": 1 [ { "type": "sigstoreSigned", "keyPath": "kbs:///default/img-sig/pub-key" 2 } ] } } }
运行以下命令来创建安全策略:
Copy to clipboardCopied$ oc apply secret generic security-policy \ --from-file=osc=./<security-policy-config.json> \ -n trustee-operator-system
不要更改机密类型
security-policy
或 key,osc
。security-policy
secret 在KbsConfig
自定义资源的spec.kbsSecretResources
键中指定。
8.16.6. 创建资源访问策略
您可以为 Trustee 策略引擎配置资源访问策略。此策略决定信任哪个资源可以访问。
Trustee 策略引擎与 Attestation Service 策略引擎不同,后者决定了 TEE 证据的有效性。
流程
创建
resourcepolicy-configmap.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: ConfigMap metadata: name: resource-policy namespace: trustee-operator-system data: policy.rego: | 1 package policy 2 default allow = false allow { input["tee"] == "se" }
- 1
- 资源策略
policy.rego
的名称必须与 Trustee 配置映射中定义的资源策略匹配。 - 2
- 资源策略遵循 Open Policy Agent 规格。当 TEE 不是 tester 的示例时,此示例允许检索所有资源。
运行以下命令来创建资源策略配置映射:
Copy to clipboardCopied$ oc apply -f resourcepolicy-configmap.yaml
8.17. 创建 KbsConfig 自定义资源
您可以创建 KbsConfig
自定义资源(CR)来启动 Trustee。
然后,您可以检查 Trustee pod 和 pod 日志以验证配置。
流程
创建
kbsconfig-cr.yaml
清单文件:
Copy to clipboardCopiedapiVersion: confidentialcontainers.org/v1alpha1 kind: KbsConfig metadata: labels: app.kubernetes.io/name: kbsconfig app.kubernetes.io/instance: kbsconfig app.kubernetes.io/part-of: trustee-operator app.kubernetes.io/managed-by: kustomize app.kubernetes.io/created-by: trustee-operator name: kbsconfig namespace: trustee-operator-system spec: kbsConfigMapName: kbs-config-cm kbsAuthSecretName: kbs-auth-public-key kbsDeploymentType: AllInOneDeployment kbsRvpsRefValuesConfigMapName: rvps-reference-values kbsSecretResources: ["kbsres1", "security-policy", "<type>"] 1 kbsResourcePolicyConfigMapName: resource-policy kbsAttestationPolicyConfigMapName: attestation-policy kbsHttpsKeySecretName: kbs-https-key kbsHttpsCertSecretName: kbs-https-certificate kbsServiceType: NodePort ibmSEConfigSpec: certStorePvc: ibmse-pvc KbsEnvVars: SE_SKIP_CERTS_VERIFICATION: "false" 2
运行以下命令来创建
KbsConfig
CR:
Copy to clipboardCopied$ oc apply -f kbsconfig-cr.yaml
8.18. 验证信任配置
您可以通过检查 Trustee pod 和 logs 来验证 Trustee 配置。
流程
运行以下命令来设置默认项目:
Copy to clipboardCopied$ oc project trustee-operator-system
运行以下命令检查 Trustee pod:
Copy to clipboardCopied$ oc get pods -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME READY STATUS RESTARTS AGE trustee-deployment-8585f98449-9bbgl 1/1 Running 0 22m trustee-operator-controller-manager-5fbd44cd97-55dlh 2/2 Running 0 59m
运行以下命令设置
POD_NAME
环境变量:
Copy to clipboardCopied$ POD_NAME=$(oc get pods -l app=kbs -o jsonpath='{.items[0].metadata.name}' -n trustee-operator-system)
运行以下命令检查 pod 日志:
Copy to clipboardCopied$ oc logs -n trustee-operator-system $POD_NAME
输出示例
Copy to clipboardCopied[2024-05-30T13:44:24Z INFO kbs] Using config file /etc/kbs-config/kbs-config.json [2024-05-30T13:44:24Z WARN attestation_service::rvps] No RVPS address provided and will launch a built-in rvps [2024-05-30T13:44:24Z INFO attestation_service::token::simple] No Token Signer key in config file, create an ephemeral key and without CA pubkey cert [2024-05-30T13:44:24Z INFO api_server] Starting HTTPS server at [0.0.0.0:8080] [2024-05-30T13:44:24Z INFO actix_server::builder] starting 12 workers [2024-05-30T13:44:24Z INFO actix_server::server] Tokio runtime found; starting in existing Tokio runtime
运行以下命令,验证
kbs-service
是否在节点端口上公开:
Copy to clipboardCopied$ oc get svc kbs-service -n trustee-operator-system
输出示例
Copy to clipboardCopiedNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kbs-service NodePort 198.51.100.54 <none> 8080:31862/TCP 23h
运行以下命令来获取 Trustee 部署 pod 名称:
Copy to clipboardCopied$ oc get pods -n trustee-operator-system | grep -i trustee-deployment
输出示例
Copy to clipboardCopiedNAME READY STATUS RESTARTS AGE trustee-deployment-d746679cd-plq82 1/1 Running 0 2m32s
8.19. 验证测试过程
您可以通过创建一个 BusyBox pod 来验证 attestation 过程。pod 镜像部署机密工作负载,您可以在其中检索密钥。
此流程是验证 attestation 是否正常工作的示例。不要将敏感数据写入标准 I/O,因为可使用内存转储捕获数据。只有写入内存的数据才会被加密。
流程
创建一个
busybox.yaml
清单文件:
Copy to clipboardCopiedapiVersion: v1 kind: Pod metadata: name: busybox namespace: default labels: run: busybox spec: runtimeClassName: kata-remote restartPolicy: Never containers: - name: busybox image: quay.io/prometheus/busybox:latest imagePullPolicy: Always command: - "sleep" - "3600"
运行以下命令来创建 pod:
Copy to clipboardCopied$ oc create -f busybox.yaml
运行以下命令登录到 pod:
Copy to clipboardCopied$ oc exec -it busybox -n default -- /bin/sh
运行以下命令来获取 secret 密钥:
Copy to clipboardCopied$ wget http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
输出示例
Copy to clipboardCopiedConnecting to 127.0.0.1:8006 (127.0.0.1:8006) saving to 'key1' key1 100% |*******************************************| 8 0:00:00 ETA 'key1' saved
运行以下命令显示
key1
值:
Copy to clipboardCopied$ cat key1
输出示例
Copy to clipboardCopiedres1val1/ #
第 9 章 监控
您可以使用 OpenShift Container Platform Web 控制台监控与沙盒工作负载和节点的健康状态相关的指标。
OpenShift 沙盒容器在 OpenShift Container Platform Web 控制台中有一个预先配置的仪表板。管理员还可以通过 Prometheus 访问和查询原始指标。
9.1. 关于指标
OpenShift 沙盒容器指标让管理员能够监控沙盒容器的运行方式。您可以在 OpenShift Container Platform Web 控制台中的 Metrics UI 中查询这些指标。
OpenShift 沙盒容器指标为以下类别收集:
- Kata 代理指标
-
Kata 代理指标显示有关嵌入在沙盒容器中运行的 kata 代理进程的信息。这些指标包括
/proc/<pid>/[io, stat, status]
中的数据。 - Kata 客户机操作系统指标
-
Kata 客户机操作系统指标显示沙盒容器中运行的客户机操作系统中的数据。这些指标包括
/proc/[stats, diskstats, meminfo, vmstats]
和/proc/net/dev
中的数据。 - hypervisor 指标
-
hypervisor 指标显示有关运行嵌入在沙盒容器中虚拟机的虚拟机监控程序的数据。这些指标主要包括
/proc/<pid>/[io, stat, status]
中的数据。 - Kata 监控指标
- Kata 监控器是收集指标数据并提供给 Prometheus 的进程。kata 监控指标显示有关 kata-monitor 进程本身的资源使用情况的详细信息。这些指标还包括 Prometheus 数据收集的计数器。
- Kata containerd shim v2 指标
-
Kata containerd shim v2 指标显示有关 kata shim 进程的详细信息。这些指标包括来自
/proc/<pid>/[io, stat, status]
和详细的资源使用量指标的数据。
9.2. 查看指标
您可以在 OpenShift Container Platform Web 控制台的 Metrics 页面中访问 OpenShift 沙盒容器的指标。
先决条件
-
您可以使用具有
cluster-admin
角色或所有项目的查看权限的用户访问集群。
流程
- 在 OpenShift Container Platform web 控制台中进入到 Observe → Metrics。
在输入字段中,输入您要观察到的指标的查询。
所有与 kata 相关的指标都以 kata 开头。键入 kata 会显示所有可用 kata 指标的列表。
在页面中会视觉化查询的指标。
第 10 章 卸装
您可以卸载 OpenShift 沙盒容器并删除机密容器环境。
10.1. 卸载 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台或命令行卸载 OpenShift 沙盒容器。
您可以通过执行以下任务卸载 OpenShift 沙盒容器:
- 删除工作负载 pod。
-
删除
KataConfig
自定义资源(CR)。 - 卸载 OpenShift 沙盒容器 Operator。
-
删除
KataConfig
自定义资源定义(CRD)。
在删除 KataConfig
CR 前,您必须删除工作负载 pod。如果提供,pod 名称通常具有前缀 podvm
和自定义标签。如果您在云供应商上部署 OpenShift 沙盒容器或机密容器,且任何资源在遵循这些步骤后仍然保留,您可能会从云供应商收到这些资源的意外几率。在云供应商上卸载 OpenShift 沙盒容器后,检查云供应商控制台以确保删除所有资源的步骤。
10.1.1. 使用 Web 控制台卸载 OpenShift 沙盒容器
您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift 沙盒容器。
10.1.1.1. 删除工作负载 pod
您可以使用 OpenShift Container Platform Web 控制台删除 OpenShift 沙盒容器工作负载 pod。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 您有一个使用 OpenShift 沙盒容器运行时类的 pod 列表。
流程
- 在 OpenShift Container Platform Web 控制台中导航至 Workloads → Pods。
- 在 Search by name 字段中输入您要删除的 pod 的名称。
- 点 pod 名称打开它。
-
在 Details 页面中,检查是否为 Runtime 类 显示
kata
或kata-remote
。 -
点击 Options 菜单
并选择 Delete Pod。
- 点击 Delete。
为每个 pod 重复此步骤。
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.1.1.2. 删除 KataConfig 自定义资源
您可以使用 Web 控制台删除 KataConfig
自定义资源(CR)。
删除 KataConfig
CR 会从集群中移除并卸载 kata
或 kata-remote
运行时及其相关资源。
删除 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
-
在 Search by name 字段中输入
OpenShift 沙盒容器 Operator
。 - 点 Operator 打开它,然后点 KataConfig 选项卡。
-
点 Options 菜单
并选择 Delete
KataConfig
。 - 在确认窗口中点击 Delete。
等待 kata
或 kata-remote
运行时和资源卸载以及 worker 节点重启,然后继续下一步。
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.1.1.3. 卸载 OpenShift 沙盒容器 Operator
您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift 沙盒容器 Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KataConfig
自定义资源。
流程
- 导航到 Operators → Installed Operators。
-
在 Search by name 字段中输入
OpenShift 沙盒容器 Operator
。 在 Operator Details 页面右侧,从 Actions 列表中选择 Uninstall Operator。
此时会显示 Uninstall Operator? 对话框。
- 点 Uninstall 删除 Operator、Operator 部署和 pod。
- 导航至 Administration → Namespaces。
-
在 Search by name 字段中输入
openshift-sandboxed-containers-operator
。 -
点 Options 菜单
并选择 Delete Namespace。
-
在确认对话框中,输入
openshift-sandboxed-containers-operator
并点 Delete。
10.1.1.4. 删除 KataConfig CRD
您可以使用 OpenShift Container Platform Web 控制台删除 KataConfig
自定义资源定义(CRD)。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KataConfig
自定义资源。 - 您已卸载了 OpenShift 沙盒容器 Operator。
流程
- 在 Web 控制台中,导航到 Administration → CustomResourceDefinitions。
-
在 Search by name 字段中输入
KataConfig
名称。 - 点 Options 菜单并选择 Delete CustomResourceDefinition。
- 在确认窗口中点击 Delete。
10.1.2. 使用 CLI 卸载 OpenShift 沙盒容器
您可以使用命令行界面(CLI)卸载 OpenShift 沙盒容器。
10.1.2.1. 删除工作负载 pod
您可以使用 CLI 删除 OpenShift 沙盒容器工作负载 pod。
先决条件
-
已安装 JSON 处理器(
jq
)工具。
流程
运行以下命令来搜索 pod:
Copy to clipboardCopied$ oc get pods -A -o json | jq -r '.items[] | \ select(.spec.runtimeClassName == "<runtime>").metadata.name' 1
- 1
- 将
<runtime
> 替换为裸机部署的kata
,或使用 AWS、Azure、IBM Z® 和 IBM® LinuxONE 部署的kata-remote
。
运行以下命令来删除每个 pod:
Copy to clipboardCopied$ oc delete pod <pod>
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.1.2.2. 删除 KataConfig 自定义资源
您可以使用命令行删除 KataConfig
自定义资源(CR)。
删除 KataConfig
CR 会从集群中移除运行时及其相关资源。
删除 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。
流程
运行以下命令来删除
KataConfig
CR:
Copy to clipboardCopied$ oc delete kataconfig example-kataconfig
OpenShift 沙盒容器 Operator 会删除最初为在集群中启用运行时创建的所有资源。
重要当您删除
KataConfig
CR 时,CLI 会停止响应,直到所有 worker 节点重启为止。在执行验证前,您必须等待删除过程完成。运行以下命令验证自定义资源是否已删除:
Copy to clipboardCopied$ oc get kataconfig example-kataconfig
输出示例
Copy to clipboardCopiedNo example-kataconfig instances exist
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.1.2.3. 卸载 OpenShift 沙盒容器 Operator
您可以使用命令行卸载 OpenShift 沙盒容器 Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KataConfig
自定义资源。
流程
运行以下命令来删除订阅:
Copy to clipboardCopied$ oc delete subscription sandboxed-containers-operator -n openshift-sandboxed-containers-operator
运行以下命令来删除命名空间:
Copy to clipboardCopied$ oc delete namespace openshift-sandboxed-containers-operator
10.1.2.4. 删除 KataConfig CRD
您可以使用命令行删除 KataConfig
自定义资源定义(CRD)。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KataConfig
自定义资源。 - 您已卸载了 OpenShift 沙盒容器 Operator。
流程
运行以下命令来删除
KataConfig
CRD:
Copy to clipboardCopied$ oc delete crd kataconfigs.kataconfiguration.openshift.io
运行以下命令验证 CRD 已被删除:
Copy to clipboardCopied$ oc get crd kataconfigs.kataconfiguration.openshift.io
输出示例
Copy to clipboardCopiedUnknown CRD kataconfigs.kataconfiguration.openshift.io
10.2. 删除机密容器环境
您可以使用 OpenShift Container Platform Web 控制台或命令行删除机密容器环境。
您可以通过执行以下任务来删除机密容器环境:
-
删除
KbsConfig
自定义资源。 - 卸载 Confidential compute attestation Operator。
-
删除
KbsConfig
自定义资源定义。
10.2.1. 使用 Web 控制台删除机密容器环境
您可以使用 OpenShift Container Platform Web 控制台删除机密容器环境。
10.2.1.1. 删除 KbsConfig 自定义资源
您可以使用 Web 控制台删除 KbsConfig
自定义资源(CR)。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 您已卸载了 OpenShift 沙盒容器。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → Installed Operators。
-
在 Search by name 字段中输入
Confidential compute attestation
。 - 点 Operator 打开它,然后点 KbsConfig 选项卡。
-
点击 Options 菜单
并选择 Delete
KbsConfig
。 - 在确认窗口中点击 Delete。
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.2.1.2. 在测试 Operator 时卸载机密计算
您可以使用 OpenShift Container Platform Web 控制台卸载 Confidential compute attestation Operator。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KbsConfig
自定义资源。
流程
- 导航到 Operators → Installed Operators。
-
在 Search by name 字段中输入
Confidential compute attestation
。 在 Operator Details 页面右侧,从 Actions 列表中选择 Uninstall Operator。
此时会显示 Uninstall Operator? 对话框。
- 点 Uninstall 删除 Operator、Operator 部署和 pod。
- 导航至 Administration → Namespaces。
-
在 Search by name 字段中输入
trustee-operator-system
。 -
点 Options 菜单
并选择 Delete Namespace。
-
在确认对话框中,输入
trustee-operator-system
并点 Delete。
10.2.1.3. 删除 KbsConfig CRD
您可以使用 OpenShift Container Platform Web 控制台删除 KbsConfig
自定义资源定义(CRD)。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KbsConfig
自定义资源。 - 您已卸载了 Confidential compute attestation Operator。
流程
- 在 Web 控制台中,导航到 Administration → CustomResourceDefinitions。
-
在 Search by name 字段中输入
KbsConfig
名称。 - 点 Options 菜单并选择 Delete CustomResourceDefinition。
- 在确认窗口中点击 Delete。
10.2.2. 使用 CLI 删除机密容器环境
您可以使用命令行界面(CLI)删除机密容器环境。
10.2.2.1. 删除 KbsConfig 自定义资源
您可以使用命令行删除 KbsConfig
自定义资源(CR)。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 - 您已卸载了 OpenShift 沙盒容器。
流程
运行以下命令来删除
KbsConfig
CR:
Copy to clipboardCopied$ oc delete kbsconfig kbsconfig
运行以下命令验证自定义资源是否已删除:
Copy to clipboardCopied$ oc get kbsconfig kbsconfig
输出示例
Copy to clipboardCopiedNo kbsconfig instances exist
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
10.2.2.2. 在测试 Operator 时卸载机密计算
您可以使用命令行卸载 Confidential compute attestation Operator。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除
KbsConfig
自定义资源。
流程
运行以下命令来删除订阅:
Copy to clipboardCopied$ oc delete subscription trustee-operator -n trustee-operator-system
运行以下命令来删除命名空间:
Copy to clipboardCopied$ oc delete namespace trustee-operator-system
10.2.2.3. 删除 KbsConfig CRD
您可以使用命令行删除 KbsConfig
自定义资源定义(CRD)。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。 -
您已删除所有使用
kata
或kata-remote
作为runtimeClass
的 pod。 -
您已删除
KbsConfig
自定义资源。 - 您已卸载了 Confidential compute attestation Operator。
流程
运行以下命令来删除
KbsConfig
CRD:
Copy to clipboardCopied$ oc delete crd kbsconfigs.confidentialcontainers.org
运行以下命令验证 CRD 已被删除:
Copy to clipboardCopied$ oc get crd kbsconfigs.confidentialcontainers.org
输出示例
Copy to clipboardCopiedUnknown CRD kbsconfigs.confidentialcontainers.org
第 11 章 升级
OpenShift 沙盒容器组件的升级由以下步骤组成:
-
升级 OpenShift Container Platform 以更新
Kata
运行时及其依赖项。 - 升级 OpenShift 沙盒容器 Operator 以更新 Operator 订阅。
您可以在 OpenShift 沙盒容器 Operator 升级前或之后升级 OpenShift Container Platform,但有以下例外。在升级 OpenShift 沙盒容器 Operator 后,始终立即应用 KataConfig
补丁。
11.1. 升级资源
Red Hat Enterprise Linux CoreOS (RHCOS)扩展将 OpenShift 沙盒容器资源部署到集群中。
RHCOS 扩展 沙盒容器
包含运行 OpenShift 沙盒容器所需的组件,如 Kata 容器运行时、虚拟机监控程序 QEMU 和其他依赖项。您可以通过将集群升级到 OpenShift Container Platform 的新版本来升级扩展。
有关升级 OpenShift Container Platform 的更多信息,请参阅更新集群。
11.2. 升级 Operator
使用 Operator Lifecycle Manager (OLM) 手动或自动升级 OpenShift 沙盒容器 Operator。在初始部署期间,选择手动或自动升级可决定将来的升级模式。对于手动升级,OpenShift Container Platform Web 控制台会显示集群管理员可安装的可用更新。
有关在 Operator Lifecycle Manager (OLM)中升级 OpenShift 沙盒容器 Operator 的更多信息,请参阅更新已安装的 Operator。
11.3. 更新 pod 虚拟机镜像
对于 AWS、Azure 和 IBM 部署,您必须更新 pod 虚拟机镜像。当 enablePeerpods:
paramter 为 true
时,升级 OpenShift 沙盒容器 Operator 不会自动更新现有的 pod 虚拟机镜像。要在升级后更新 pod 虚拟机镜像,您必须删除并重新创建 KataConfig
CR。
您还可以检查 AWS 和 Azure 部署的对等 pod 配置映射,以确保在重新创建 KataConfig
CR 前镜像 ID 为空。
11.3.1. 删除 KataConfig 自定义资源
您可以使用命令行删除 KataConfig
自定义资源(CR)。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
运行以下命令来删除
KataConfig
CR:
Copy to clipboardCopied$ oc delete kataconfig example-kataconfig
运行以下命令验证自定义资源是否已删除:
Copy to clipboardCopied$ oc get kataconfig example-kataconfig
输出示例
Copy to clipboardCopiedNo example-kataconfig instances exist
卸载使用云供应商部署的 OpenShift 沙盒容器时,您必须删除所有 pod。任何剩余的 pod 资源都可能会导致云供应商出现意外几率。
11.3.2. 确保对等 pod CM 镜像 ID 为空
删除 KataConfig
CR 时,它应该删除 peer pod CM 镜像 ID。对于 AWS 和 Azure 部署,检查以确保对等 pod CM 镜像 ID 为空。
流程
获取您为对等 pod 创建的配置映射:
Copy to clipboardCopied$ oc get cm -n openshift-sandboxed-containers-operator peer-pods-cm -o jsonpath="{.data.AZURE_IMAGE_ID}"
AWS 使用
PODVM_AMI_ID
。Azure 使用AZURE_IMAGE_ID
。- 检查 YAML 文件的状态小节。
-
如果 AWS 的
PODVM_AMI_ID
参数或 Azure 的AZURE_IMAGE_ID
参数包含一个值,请将值设为 ""。 如果将值设为 "",请修补对等 pod 配置映射:
Copy to clipboardCopied$ oc patch configmap peer-pods-cm -n openshift-sandboxed-containers-operator -p '{"data":{"AZURE_IMAGE_ID":""}}'
AWS 使用
PODVM_AMI_ID
。Azure 使用AZURE_IMAGE_ID
。
11.3.3. 创建 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
清单文件:
Copy to clipboardCopiedapiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: enablePeerPods: true logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 1
运行以下命令来创建
KataConfig
CR:
Copy to clipboardCopied$ oc apply -f example-kataconfig.yaml
新的
KataConfig
CR 被创建,并在 worker 节点上作为运行时类安装kata-remote
。在验证安装前,等待
kata-remote
安装完成,以及 worker 节点重新引导。运行以下命令监控安装进度:
Copy to clipboardCopied$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
安装
kataNodes
下所有 worker 的状态并且条件InProgress
为False
时,而不指定原因,则会在集群中安装kata-remote
。运行以下命令验证守护进程集:
Copy to clipboardCopied$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
运行以下命令验证运行时类:
Copy to clipboardCopied$ oc get runtimeclass
输出示例
Copy to clipboardCopiedNAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
第 12 章 故障排除
当对 OpenShift 沙盒容器进行故障排除时,您可以创建一个支持问题单,并使用 must-gather
工具提供调试信息。
如果您是集群管理员,您还可以自行查看日志,启用更详细的日志级别。
12.1. 为红帽支持收集数据
在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。
您可使用 must-gather
工具来收集有关 OpenShift Container Platform 集群的诊断信息,包括虚拟机和有关 OpenShift 沙盒容器的其他数据。
为了获得快速支持,请提供 OpenShift Container Platform 和 OpenShift 沙盒容器的诊断信息。
使用 must-gather 工具
oc adm must-gather
CLI 命令可收集最有助于解决问题的集群信息,包括:
- 资源定义
- 服务日志
默认情况下,oc adm must-gather
命令使用默认的插件镜像,并写入 ./must-gather.local
。
另外,您可以使用适当的参数运行命令来收集具体信息,如以下部分所述:
要收集与一个或多个特定功能相关的数据,请使用
--image
参数和镜像,如以下部分所述。例如:
Copy to clipboardCopied$ oc adm must-gather --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.9.0
要收集审计日志,请使用
-- /usr/bin/gather_audit_logs
参数,如以下部分所述。例如:
Copy to clipboardCopied$ oc adm must-gather -- /usr/bin/gather_audit_logs
注意作为默认信息集合的一部分,不会收集审计日志来减小文件的大小。
当您运行 oc adm must-gather
时,集群的新项目中会创建一个带有随机名称的新 pod。在该 pod 上收集数据,并保存至以 must-gather.local
开头的一个新目录中。此目录在当前工作目录中创建。
例如:
NAMESPACE NAME READY STATUS RESTARTS AGE
...
openshift-must-gather-5drcj must-gather-bklx4 2/2 Running 0 72s
openshift-must-gather-5drcj must-gather-s8sdh 2/2 Running 0 72s
...
Copy to clipboardCopied
另外,您可以使用 --run-namespace
选项在特定命名空间中运行 oc adm must-gather
命令。
例如:
$ oc adm must-gather --run-namespace <namespace> --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.9.0
Copy to clipboardCopied12.2. 收集日志数据
以下功能和对象与 OpenShift 沙盒容器关联:
- 属于 OpenShift 沙盒容器资源的所有命名空间及其子对象
- 所有 OpenShift 沙盒容器自定义资源定义 (CRD)
您可以为使用 kata
运行时运行的每个 pod 收集以下组件日志:
- Kata 代理日志
- Kata 运行时日志
- QEMU 日志
- 审计日志
- CRI-O 日志
12.2.1. 为 CRI-O 运行时启用调试日志
您可以通过更新 KataConfig
CR 中的 logLevel
字段来启用调试日志。这会更改运行 OpenShift 沙盒容器的 worker 节点的 CRI-O 运行时中的日志级别。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
将现有
KataConfig
CR 中的logLevel
字段更改为debug
:
Copy to clipboardCopied$ oc patch kataconfig <kataconfig> --type merge --patch '{"spec":{"logLevel":"debug"}}'
监控
kata-oc
机器配置池,直到UPDATED
的值为True
,表示所有 worker 节点都已更新:
Copy to clipboardCopied$ oc get mcp kata-oc
输出示例
Copy to clipboardCopiedNAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE kata-oc rendered-kata-oc-169 False True False 3 1 1 0 9h
验证
使用机器配置池中的节点启动 debug 会话:
Copy to clipboardCopied$ oc debug node/<node_name>
将根目录改为
/host
:
Copy to clipboardCopied# chroot /host
验证
crio.conf
文件中的更改:
Copy to clipboardCopied# crio config | egrep 'log_level
输出示例
Copy to clipboardCopiedlog_level = "debug"
12.2.2. 查看组件的调试日志
集群管理员可以使用调试日志进行故障排除。每个节点的日志会输出到节点日志中。
您可以查看以下 OpenShift 沙盒容器组件的日志:
- Kata 代理
-
Kata runtime (
containerd-shim-kata-v2
) -
virtiofsd
QEMU 仅生成警告和错误日志。这些警告和错误会在 Kata 运行时日志和带有额外的 qemuPid
字段的 CRI-O 日志中打印到节点日志。
QEMU 日志示例
Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.587116986Z" level=info msg="Start logging QEMU (qemuPid=2241693)" name=containerd-shim-v2 pid=2241647 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu
Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.607339014Z" level=error msg="qemu-kvm: -machine q35,accel=kvm,kernel_irqchip=split,foo: Expected '=' after parameter 'foo'" name=containerd-shim-v2 pid=2241647 qemuPid=2241693 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu
Mar 11 11:57:28 openshift-worker-0 kata[2241647]: time="2023-03-11T11:57:28.60890737Z" level=info msg="Stop logging QEMU (qemuPid=2241693)" name=containerd-shim-v2 pid=2241647 sandbox=d1d4d68efc35e5ccb4331af73da459c13f46269b512774aa6bde7da34db48987 source=virtcontainers/hypervisor subsystem=qemu
Copy to clipboardCopied
当 QEMU 启动时,Kata 运行时会在 QEMU 启动时打印 Start logging QEMU
,并在 QEMU 停止时停止日志记录 QEMU
。使用 qemuPid
字段的两个日志消息之间会出现这个错误。QEMU 的实际错误消息以红色显示。
QEMU 客户机的控制台也会输出到节点日志中。您可以查看客户机控制台日志以及 Kata 代理日志。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
要查看 Kata 代理日志和客户机控制台日志,请运行以下命令:
Copy to clipboardCopied$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g “reading guest console”
要查看 Kata 运行时日志,请运行以下命令:
Copy to clipboardCopied$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata
要查看
virtiofsd
日志,请运行以下命令:
Copy to clipboardCopied$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t virtiofsd
要查看 QEMU 日志,请运行以下命令:
Copy to clipboardCopied$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g "qemuPid=\d+"
其他资源
- 在 OpenShift Container Platform 文档中收集有关集群的数据 https://docs.redhat.com/documentation/en/openshift_container_platform/4.18/html/support/index#support_gathering_data_gathering-cluster-data
附录 A. KataConfig 状态信息
下表显示了具有两个 worker 节点的集群的 KataConfig
自定义资源(CR)的状态消息。
Status | 描述 |
---|---|
初始安装
当创建 |
Copy to clipboardCopied |
安装 在几秒钟内,状态会改变。 |
Copy to clipboardCopied |
安装 (Worker-1 安装开始)
在短时间内,状态会改变,表示一个节点启动了 |
Copy to clipboardCopied |
安装 (安装了Worker-1,worker-0 安装已启动)
一段时间后, |
Copy to clipboardCopied |
已安装
安装后,两个 worker 都被列出为 installed, |
Copy to clipboardCopied |
Status | 描述 |
---|---|
初始卸载
如果在 worker 上同时安装了 |
Copy to clipboardCopied |
卸装 几秒钟后,其中一个 worker 开始卸载。 |
Copy to clipboardCopied |
卸装 worker-1 完成,worker-0 开始卸载。 |
Copy to clipboardCopied |
reason
字段也可以报告以下原因:
-
失败
:如果节点无法完成转换,则报告此报告。状态报告
True
,消息
为Node <node_name> Degraded: <error_message_from_the_node>
。 -
BlockedByExistingKataPods
:如果在卸载 kata-remote 的群集上运行有 pod,则报告使用kata-remote
status
字段为False
,消息
为Existing pod,使用 "kata-remote" RuntimeClass found。Please delete the pods for KataConfig delete to proceed
。如果与集群 control plane 的通信失败,则报告的技术错误消息,如Failed to list kata pod: <error_message
>。