Platform (GCP) 上的受管服务提供。 通过客户云订阅 (CCS) 模型，您可以在您拥有的现有 AWS 或 GCP 云帐户中部署集群。 另外，您可以在由红帽拥有的一个云帐户中安装 OpenShift Dedicated。 1.1.1. 使用客户云订阅 (CCS) 模型部署集群 客户云订阅 (CCS) 模型允许您在您拥有的现有 AWS 或 GCP 帐户中部署 Red Hat Managed 支持这个服务。 在 CCS 模型中，客户直接为云成本支付云基础架构供应商，云基础架构帐户是客户拥有的机构的一部 分，对红帽授予了特定访问权限。在此模式中，客户为 CCS 订阅支付红帽，并支付云供应商来实现云成 本。 通过使用 CCS 模型，除了红帽提供的服务外，您还可以使用云供应商提供的服务。 1.1.2. 在 Red Hat 云帐户中部署集群 作为 CCS 模型的替代选择，您可以在 Red Red Hat 拥有的 AWS 或 GCP 云帐户中部署 OpenShift Dedicated 集群。通过这种模型，红帽负责云帐户，并且红帽直接支付云基础架构成本。客户只支付红帽订阅成本。 1.2. 后续步骤 在 AWS 上创建集群 在 GCP 上创建集群 第 第 1 章 章 了解您的云部署 了解您的云部署选项 选项 3 第 2 章 OPENSHIFT DEDICATED 入门 按照以下步骤快速创建

(VM) CPU 模型取决于虚拟机和集群中的 CPU 模型的可用性。 如果虚拟机没有定义的 CPU 模型： defaultCPUModel 使用在集群范围级别上定义的 CPU 模型自动设置。 如果虚拟机和集群都有定义的 CPU 模型： 虚拟机的 CPU 模型具有优先权。 如果虚拟机或集群都没有定义的 CPU 模型： host-model 使用主机级别上定义的 CPU 模型自动设置。 10 OpenShift CLI（oc）。 流程 流程 1. 运行以下命令打开 HyperConverged CR： 2. 将 defaultCPUModel 字段添加到 CR，并将值设置为集群中存在的 CPU 模型的名称： error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission workload with dedicated resources (guaranteed policy)。 5. 点 Save。 10.15.9. 调度虚拟机 在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下，可在节点上调度 虚拟机（VM）。 10.15.9.1. 策略属性 策略属性 您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机（VM）。为虚拟机指定的

workload with dedicated resources (guaranteed policy)。 5. 点 Save。 8.15.9. 调度虚拟机 在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下，可在节点上调度 虚拟机（VM）。 8.15.9.1. 策略属性 策略属性 您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机（VM）。为虚拟机指定的 不支持虚拟机的 CPU，也是如 此。 require 在虚拟机没有使用特定 CPU 模型和功能规格配置时，应用于虚拟机的默认策 略。如果节点没有配置为支持使用此默认策略属性或其他策略属性的 CPU 节 点发现，则虚拟机不会调度到该节点上。主机 CPU 必须支持虚拟机的 CPU， 或者虚拟机监控程序必须可以模拟支持的 CPU 模型。 optional 如果主机物理机器 CPU 支持该虚拟机，则虚拟机会被添加到节点。 (VM) 配置 CPU 模型，将其调度到支持其 CPU 模型的节点。 流程 流程 编辑虚拟机配置文件的 domain spec。以下示例显示了为虚拟机定义的特定 CPU 模型： 虚拟机的 CPU 模型. 8.15.9.4. 使用主机模型 使用主机模型调度虚 度虚拟机 机 当将虚拟机（VM）的 CPU 模型设置为 host-model 时，虚拟机会继承调度节点的 CPU 模型。 流程 流程 编辑虚拟机配置文件的

SERVICE MESH 2.X 1.1. 关于 OPENSHIFT SERVICE MESH 1.2. SERVICE MESH 发行注记 1.3. 了解 SERVICE MESH 1.4. 服务网格部署模型 1.5. SERVICE MESH 和 ISTIO 的不同 1.6. 准备安装 SERVICE MESH 1.7. 安装 OPERATOR 1.8. 创建 SERVICEMESHCONTROLPLANE 环境中安装 Red Hat OpenShift Service Mesh 。 1.4. 服务网格部署模型 Red Hat OpenShift Service Mesh 支持几种不同的部署模型，它们可以以不同的方式组合以满足您的业务 需求。 1.4.1. 单网格部署模型 最简单的 Istio 部署模型是一个网格。 网格中的服务名称必须是唯一的，因为 Kubernetes 只允许一个服务在 mynamespace mynamespace 命名空间中被命名 为 myservice。但是，工作负载实例可以共享一个通用身份，因为服务帐户名称可以在同一个命名空间中 的工作负载之间共享 1.4.2. 单租赁部署模型 在 Istio 中，租户是为一组部署的工作负载共享共同访问权限和特权的用户组。您可以使用租户在不同的 OpenShift Container Platform 4.8 Service Mesh 32 在

OpenShift Data Science (RHODS) 允许用户集成数据和 AI 和机器学习软件，以运行端到端机器 学习工作流。它提供了一系列笔记本镜像，提供开发和部署数据模型所需的工具和库。这样，数据科学家 可轻松开发数据模型，将模型集成到应用程序中，并使用 Red Hat OpenShift 部署应用程序。RHODS 作 为 Red Hat 受管环境的附加组件提供，如 OpenShift Dedicated

Container Platform 功能，允许从其 data plane 和 worker 在 OpenShift Container Platform 集群上托管 control plane。这个模型执行以下操作： 优化 control plane 所需的基础架构成本。 改进集群创建时间。 启用使用 Kubernetes 原生高级别元语托管 control plane。例如，部署有状态的集合。 controller）是另一种特殊资产，用于指示一次需要运行多少个 pod 副本。您可以使用此功能来自 动扩展应用程序，以适应其当前的需求。 短短数年，Kubernetes 已在大量的云和本地环境中被采用。借助开源开发模型，拥护和可以通过为组件 （如网络、存储和身份验证）实施不同的技术来扩展 Kubernetes 的功能。 2.1.2. 容器化应用程序的好处 与使用传统部署方法相比，使用容器化应用程序具有许多优势。过去应用程序要安装到包含所有依赖项的 Linux 操作系统。它们的文件系统、网络、cgroups、进程表和命名空间与 主机 Linux 系统分开，但容器可以在必要时与主机无缝集成。容器以 Linux 为基础，因此可以利用快速创 新的开源开发模型带来的所有优势。 因为每个容器都使用专用的操作系统，所以您能够在同一主机上部署需要冲突软件依赖项的不同应用程 序。每个容器都带有各自的依赖软件，并且管理自己的接口，如网络和文件系统，因此应用程序无需争用

这些工具可组合使用，因此您可自由选择对您有用的工具。 2.1.3. Operator 成熟度模型 Operator 内部封装的管理逻辑的复杂程度各有不同。该逻辑通常还高度依赖于 Operator 所代表的服务类 型。 对于大部分 Operator 可能包含的特定功能集来说，可以大致推断出 Operator 封装操作的成熟度等级。就 此而言，以下 Operator 成熟度模型针对 Operator 的第二天通用操作定义了五个成熟度阶段： 的第二天通用操作定义了五个成熟度阶段： 图 2.1. Operator 成熟度模型 成熟度模型 以上模型还显示了如何通过 Operator SDK 的 Helm、Go 和 Ansible 功能更好地开发这些功能。 2.2. OPERATOR FRAMEWORK 打包格式 本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 所支持的 Operator CSV 拥有自定义资源定义（CRD），则该 CRD 必须存在于捆绑包中。 2.2.1.1. 清 清单 捆绑包清单指的是一组 Kubernetes 清单，用于定义 Operator 的部署和 RBAC 模型。 捆绑包包括每个目录的一个 CSV，一般情况下，用来定义 CRD 所拥有的 API 的 CRD 位于 /manifest 目 录中。 捆绑包格式布局示例 包格式布局示例 额外支持的 外支持的对象

controller）是另一种特殊资产，用于指示一次需要运行多少个 Pod 副本。您可以使用此功能来自 动扩展应用程序，以适应其当前的需求。 短短数年，Kubernetes 已在大量的云和本地环境中被采用。借助开源开发模型，拥护和可以通过为组件 （如网络、存储和身份验证）实施不同的技术来扩展 Kubernetes 的功能。 1.1.2. 容器化应用程序的好处 与使用传统部署方法相比，使用容器化应用程序具有许多优势。过去应用程序要安装到包含所有依赖项的 Linux 操作系统。它们的文件系统、网络、cgroups、进程表和命名空间与 主机 Linux 系统分开，但容器可以在必要时与主机无缝集成。容器以 Linux 为基础，因此可以利用快速创 新的开源开发模型带来的所有优势。 因为每个容器都使用专用的操作系统，所以您能够在同一主机上部署需要冲突软件依赖项的不同应用程 序。每个容器都带有各自的依赖软件，并且管理自己的接口，如网络和文件系统，因此应用程序无需争用 中的主要组件源自 Red Hat Enterprise Linux 和 相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件的严格测试和认证 计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管

controller）是另一种特殊资产，用于指示一次需要运行多少个 Pod 副本。您可以使用此功能来自 动扩展应用程序，以适应其当前的需求。 短短数年，Kubernetes 已在大量的云和本地环境中被采用。借助开源开发模型，拥护和可以通过为组件 （如网络、存储和身份验证）实施不同的技术来扩展 Kubernetes 的功能。 1.1.2. 容器化应用程序的好处 与使用传统部署方法相比，使用容器化应用程序具有许多优势。过去应用程序要安装到包含所有依赖项的 Linux 操作系统。它们的文件系统、网络、cgroups、进程表和命名空间与 主机 Linux 系统分开，但容器可以在必要时与主机无缝集成。容器以 Linux 为基础，因此可以利用快速创 新的开源开发模型带来的所有优势。 因为每个容器都使用专用的操作系统，所以您能够在同一主机上部署需要冲突软件依赖项的不同应用程 序。每个容器都带有各自的依赖软件，并且管理自己的接口，如网络和文件系统，因此应用程序无需争用 中的主要组件源自 Red Hat Enterprise Linux 和 相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件的严格测试和认证 计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管

-rapl 主机文件。 rapl-msr: 需要访问 /dev/cpu/*/msr 主机文件。 estimator 电 电源源 源源 如果没有访问内核电源上限子系统，Kepler 使用机器学习模型来估算节点上 CPU 的功耗。  OpenShift Container Platform 4.14 电 电源 源监 监控 控 4 警告 警告 estimator 目前只是实验性的功能，它不被支持，用户不应依赖它。 kepler_node_platform_joules_total 主机的总能源消耗。通常，这个指标是 Redfish BMC 或 ACPI 的主机能源消耗。 kepler_node_energy_stat 使用模型服务器中使用的容器资源利用率控制组指标 标记的节点有多个指标。 kepler_node_accelerator_intel_qat 在某个节点上利用 Intel QAT 加速器。如果系统包含 Intel