第 2 章 策略和服务定义
2.1. OpenShift Dedicated 服务定义
2.1.1. 帐户管理
2.1.1.1. 账单选项
客户可以选择购买 OpenShift Dedicated (OSD) 的年度订阅或通过云市场按需使用。客户可以决定使用自己的云基础架构帐户，称为客户云订阅(CCS)，或者在由红帽拥有的云供应商帐户中进行部署。下表提供有关计费的更多信息，以及相应的支持的部署选项。
| OSD 订阅类型 | 云基础架构帐户 | 计费过程 |
|---|---|---|
| 红帽年度固定容量订阅 | 红帽云帐户 | 红帽可以消耗 OSD 订阅和云基础架构 |
| 客户自己的云帐户 | 红帽使用 OSD 订阅的消耗 用于使用云基础架构的云供应商 | |
| 通过 Google Cloud Marketplace 进行按需使用 | 客户自己的 Google Cloud 帐户 | Google Cloud 用于云基础架构和 Red Hat OSD 订阅 |
| 通过 Red Hat Marketplace 进行按需使用 | 客户自己的云帐户 | 红帽使用 OSD 订阅的消耗 用于使用云基础架构的云供应商 |
使用自己的云基础架构帐户（称为客户云订阅(CSS)）的客户负责预先购买或提供保留实例(RI)计算实例以确保云基础架构成本较低。
可以为 OpenShift Dedicated 集群购买其他资源，包括：
- 额外的节点（可以通过使用机器池的不同类型和大小）
- 中间件(JBoss EAP、JBoss Fuse 等)- 根据特定中间件组件的额外定价
- 以 500 GB 为单位递增的额外存储（仅限标准，包括 100 GB）
- 额外的 12 TiB 网络 I/O （仅包含标准，仅包含 12 TB）
- 服务的负载均衡器在 4 的捆绑包中可用；启用非标准端口（仅限标准）
2.1.1.2. 集群自助服务
客户可以从 OpenShift Cluster Manager 创建、扩展和删除其集群，只要他们已经购买了必要的订阅。
Red Hat OpenShift Cluster Manager 中提供的操作不能直接从集群内直接执行，因为这可能导致负面影响，包括所有操作都自动恢复。
2.1.1.3. 云供应商
OpenShift Dedicated 在以下云供应商上将 OpenShift Container Platform 集群作为受管服务提供：
- Amazon Web Services (AWS)
- Google Cloud Platform (GCP)
2.1.1.4. 实例类型
单个可用区集群至少需要 2 个 worker 节点才能将客户云订阅 (CCS) 集群部署到一个可用区。标准集群至少需要 4 个 worker 节点。这 4 个 worker 节点包含在基本订阅中。
多个可用区集群至少需要 3 个 worker 节点用于客户云订阅(CCS) 集群，3 个可用区的每个都部署 1 个。标准集群至少需要 9 个 worker 节点。这 9 个 worker 节点包含在基本订阅中，必须以 3 的倍数购买额外的节点才能保持正确的节点分布。
单个 OpenShift Dedicated 机器池中的所有 worker 节点都必须有相同的类型和大小。但是，OpenShift Dedicated 集群中多个机器池的 worker 节点可以是不同的类型和大小。
control plane 和基础架构节点也由红帽提供。至少 3 个 control plane 节点可以处理 etcd 和 API 相关的工作负载。至少 2 个基础架构节点来处理指标、路由、Web 控制台和其他工作负载。您不能在 control plane 和基础架构节点上运行任何工作负载。任何您要运行的工作负载都必须部署到 worker 节点上。有关要在 worker 节点上部署的 Red Hat 工作负载的更多信息，请参阅下面的 Red Hat Operator 支持部分。
每个 worker 节点上都会保留 1 个 vCPU 内核和 1 GiB 内存，并从可分配的资源中删除。这是运行底层平台所需的进程所必需的。这包括 udev、kubelet、容器运行时等系统守护进程，以及内核保留的帐户。OpenShift Container Platform 核心系统（如审计日志聚合、指标集合、DNS、镜像 registry、SDN 等）可能会消耗额外的可分配资源来保持集群的稳定性和可维护性。所消耗的额外资源可能会因使用情况而异。
从 OpenShift Dedicated 4.11 开始，默认的每个 pod PID 的限制为 4096。如果要启用此 PID 限制，您必须将 OpenShift Dedicated 集群升级到这些版本或更新版本。在 4.11 之前的版本上运行的 OpenShift Dedicated 集群使用默认的 PID 限制 1024。
您无法在任何 OpenShift Dedicated 集群中配置每个 pod PID 限制。
其它资源
2.1.1.5. 客户订阅集群的 AWS 实例类型
OpenShift Dedicated 在 AWS 上提供以下 worker 节点实例类型和大小：
例 2.1. 常规目的
- m5.metal (96† vCPU, 384 GiB)
- m5.xlarge (4 vCPU, 16 GiB)
- m5.2xlarge (8 vCPU, 32 GiB)
- m5.4xlarge (16 vCPU, 64 GiB)
- m5.8xlarge (32 vCPU, 128 GiB)
- m5.12xlarge (48 vCPU, 192 GiB)
- m5.16xlarge (64 vCPU, 256 GiB)
- m5.24xlarge (96 vCPU, 384 GiB)
- m5a.xlarge (4 vCPU, 16 GiB)
- m5a.2xlarge (8 vCPU, 32 GiB)
- m5a.4xlarge (16 vCPU, 64 GiB)
- m5a.8xlarge (32 vCPU, 128 GiB)
- m5a.12xlarge (48 vCPU, 192 GiB)
- m5a.16xlarge (64 vCPU, 256 GiB)
- m5a.24xlarge (96 vCPU, 384 GiB)
- m5ad.xlarge (4 vCPU, 16 GiB)
- m5ad.2xlarge (8 vCPU, 32 GiB)
- m5ad.4xlarge (16 vCPU, 64 GiB)
- m5ad.8xlarge (32 vCPU, 128 GiB)
- m5ad.12xlarge (48 vCPU, 192 GiB)
- m5ad.16xlarge (64 vCPU, 256 GiB)
- m5ad.24xlarge (96 vCPU, 384 GiB)
- m5d.metal (96† vCPU, 384 GiB)
- m5d.xlarge (4 vCPU, 16 GiB)
- m5d.2xlarge (8 vCPU, 32 GiB)
- m5d.4xlarge (16 vCPU, 64 GiB)
- m5d.8xlarge (32 vCPU, 128 GiB)
- m5d.12xlarge (48 vCPU, 192 GiB)
- m5d.16xlarge (64 vCPU, 256 GiB)
- m5d.24xlarge (96 vCPU, 384 GiB)
- m5n.metal (96 vCPU, 384 GiB)
- m5n.xlarge (4 vCPU, 16 GiB)
- m5n.2xlarge (8 vCPU, 32 GiB)
- m5n.4xlarge (16 vCPU, 64 GiB)
- m5n.8xlarge (32 vCPU, 128 GiB)
- m5n.12xlarge (48 vCPU, 192 GiB)
- m5n.16xlarge (64 vCPU, 256 GiB)
- m5n.24xlarge (96 vCPU, 384 GiB)
- m5dn.metal (96 vCPU, 384 GiB)
- m5dn.xlarge (4 vCPU, 16 GiB)
- m5dn.2xlarge (8 vCPU, 32 GiB)
- m5dn.4xlarge (16 vCPU, 64 GiB)
- m5dn.8xlarge (32 vCPU, 128 GiB)
- m5dn.12xlarge (48 vCPU, 192 GiB)
- m5dn.16xlarge (64 vCPU, 256 GiB)
- m5dn.24xlarge (96 vCPU, 384 GiB)
- m5zn.metal (48 vCPU, 192 GiB)
- m5zn.xlarge (4 vCPU, 16 GiB)
- m5zn.2xlarge (8 vCPU, 32 GiB)
- m5zn.3xlarge (12 vCPU, 48 GiB)
- m5zn.6xlarge (24 vCPU, 96 GiB)
- m5zn.12xlarge (48 vCPU, 192 GiB)
- m6a.xlarge (4 vCPU, 16 GiB)
- m6a.2xlarge (8 vCPU, 32 GiB)
- m6a.4xlarge (16 vCPU, 64 GiB)
- m6a.8xlarge (32 vCPU, 128 GiB)
- m6a.12xlarge (48 vCPU, 192 GiB)
- m6a.16xlarge (64 vCPU, 256 GiB)
- m6a.24xlarge (96 vCPU, 384 GiB)
- m6a.32xlarge (128 vCPU, 512 GiB)
- m6a.48xlarge (192 vCPU, 768 GiB)
- m6i.metal (128 vCPU, 512 GiB)
- m6i.xlarge (4 vCPU, 16 GiB)
- m6i.2xlarge (8 vCPU, 32 GiB)
- m6i.4xlarge (16 vCPU, 64 GiB)
- m6i.8xlarge (32 vCPU, 128 GiB)
- m6i.12xlarge (48 vCPU, 192 GiB)
- m6i.16xlarge (64 vCPU, 256 GiB)
- m6i.24xlarge (96 vCPU，384 GiB)
- m6i.32xlarge (128 vCPU, 512 GiB)
- m6id.xlarge (4 vCPU, 16 GiB)
- m6id.2xlarge (8 vCPU, 32 GiB)
- m6id.4xlarge (16 vCPU, 64 GiB)
- m6id.8xlarge (32 vCPU, 128 GiB)
- m6id.12xlarge (48 vCPU, 192 GiB)
- m6id.16xlarge (64 vCPU, 256 GiB)
- m6id.24xlarge (96 vCPU, 384 GiB)
- m6id.32xlarge (128 vCPU, 512 GiB)
- m7i.xlarge (4 vCPU, 16 GiB)
- m7i.2xlarge (8 vCPU, 32 GiB)
- m7i.4xlarge (16 vCPU, 64 GiB)
- m7i.8xlarge (32 vCPU, 128 GiB)
- m7i.12xlarge (48 vCPU, 192 GiB)
- m7i.16xlarge (64 vCPU, 256 GiB)
- m7i.24xlarge (96 vCPU, 384 GiB)
- m7i.48xlarge (192 vCPU, 768 GiB)
- m7i.metal-24xl (96 vCPU, 384 GiB)
- m7i.metal-48xl (192 vCPU, 768 GiB)
- m7i-flex.xlarge (4 vCPU, 16 GiB)
- m7i-flex.2xlarge (8 vCPU, 32 GiB)
- m7i-flex.4xlarge (16 vCPU, 64 GiB)
- m7i-flex.8xlarge (32 vCPU, 128 GiB)
- m7a.xlarge (4 vCPU, 16 GiB)
- m7a.2xlarge (8 vCPU, 32 GiB)
- m7a.4xlarge (16 vCPU, 64 GiB)
- m7a.8xlarge (32 vCPU, 128 GiB)
- m7a.12xlarge (48 vCPU, 192 GiB)
- m7a.16xlarge (64 vCPU, 256 GiB)
- m7a.24xlarge (96 vCPU, 384 GiB)
- m7a.32xlarge (128 vCPU, 512 GiB)
- m7a.48xlarge (192 vCPU, 768 GiB)
- m7a.metal-48xl (192 vCPU, 768 GiB)
2.4.4 这些实例类型在 48 个物理内核中提供 96 个逻辑处理器。它们在两个物理 Intel 插槽的单台服务器上运行。
例 2.2. Burstable 常规目的
- t3.xlarge (4 vCPU, 16 GiB)
- t3.2xlarge (8 vCPU, 32 GiB)
- t3a.xlarge (4 vCPU, 16 GiB)
- t3a.2xlarge (8 vCPU, 32 GiB)
例 2.3. 内存密集型
- x1.16xlarge (64 vCPU, 976 GiB)
- x1.32xlarge (128 vCPU, 1952 GiB)
- x1e.xlarge (4 vCPU, 122 GiB)
- x1e.2xlarge (8 vCPU, 244 GiB)
- x1e.4xlarge (16 vCPU, 488 GiB)
- x1e.8xlarge (32 vCPU, 976 GiB)
- x1e.16xlarge (64 vCPU, 1,952 GiB)
- x1e.32xlarge (128 vCPU, 3,904 GiB)
- x2idn.16xlarge (64 vCPU, 1024 GiB)
- x2idn.24xlarge (96 vCPU, 1536 GiB)
- x2idn.32xlarge (128 vCPU, 2048 GiB)
- x2iedn.xlarge (4 vCPU, 128 GiB)
- x2iedn.2xlarge (8 vCPU, 256 GiB)
- x2iedn.4xlarge (16 vCPU, 512 GiB)
- x2iedn.8xlarge (32 vCPU, 1024 GiB)
- x2iedn.16xlarge (64 vCPU, 2048 GiB)
- x2iedn.24xlarge (96 vCPU, 3072 GiB)
- x2iedn.32xlarge (128 vCPU, 4096 GiB)
- x2iezn.2xlarge (8 vCPU, 256 GiB)
- x2iezn.4xlarge (16vCPU, 512 GiB)
- x2iezn.6xlarge (24vCPU, 768 GiB)
- x2iezn.8xlarge (32vCPU, 1,024 GiB)
- x2iezn.12xlarge (48vCPU, 1,536 GiB)
- x2idn.metal (128vCPU, 2,048 GiB)
- x2iedn.metal (128vCPU, 4,096 GiB)
- x2iezn.metal (48 vCPU, 1,536 GiB)
例 2.4. 内存优化
- r4.xlarge (4 vCPU, 30.5 GiB)
- r4.2xlarge (8 vCPU, 61 GiB)
- r4.4xlarge (16 vCPU, 122 GiB)
- r4.8xlarge (32 vCPU, 244 GiB)
- r4.16xlarge (64 vCPU, 488 GiB)
- r5.metal (96† vCPU, 768 GiB)
- r5.xlarge (4 vCPU, 32 GiB)
- r5.2xlarge (8 vCPU, 64 GiB)
- r5.4xlarge (16 vCPU, 128 GiB)
- r5.8xlarge (32 vCPU, 256 GiB)
- r5.12xlarge (48 vCPU, 384 GiB)
- r5.16xlarge (64 vCPU, 512 GiB)
- r5.24xlarge (96 vCPU, 768 GiB)
- r5a.xlarge (4 vCPU, 32 GiB)
- r5a.2xlarge (8 vCPU, 64 GiB)
- r5a.4xlarge (16 vCPU, 128 GiB)
- r5a.8xlarge (32 vCPU, 256 GiB)
- r5a.12xlarge (48 vCPU, 384 GiB)
- r5a.16xlarge (64 vCPU, 512 GiB)
- r5a.24xlarge (96 vCPU, 768 GiB)
- r5ad.xlarge (4 vCPU, 32 GiB)
- r5ad.2xlarge (8 vCPU, 64 GiB)
- r5ad.4xlarge (16 vCPU, 128 GiB)
- r5ad.8xlarge (32 vCPU, 256 GiB)
- r5ad.12xlarge (48 vCPU, 384 GiB)
- r5ad.16xlarge (64 vCPU, 512 GiB)
- r5ad.24xlarge (96 vCPU, 768 GiB)
- r5d.metal (96† vCPU, 768 GiB)
- r5d.xlarge (4 vCPU, 32 GiB)
- r5d.2xlarge (8 vCPU, 64 GiB)
- r5d.4xlarge (16 vCPU, 128 GiB)
- r5d.8xlarge (32 vCPU, 256 GiB)
- r5d.12xlarge (48 vCPU, 384 GiB)
- r5d.16xlarge (64 vCPU, 512 GiB)
- r5d.24xlarge (96 vCPU, 768 GiB)
- r5n.metal (96 vCPU, 768 GiB)
- r5n.xlarge (4 vCPU, 32 GiB)
- r5n.2xlarge (8 vCPU, 64 GiB)
- r5n.4xlarge (16 vCPU, 128 GiB)
- r5n.8xlarge (32 vCPU, 256 GiB)
- r5n.12xlarge (48 vCPU, 384 GiB)
- r5n.16xlarge (64 vCPU, 512 GiB)
- r5n.24xlarge (96 vCPU, 768 GiB)
- r5dn.metal (96 vCPU, 768 GiB)
- r5dn.xlarge (4 vCPU, 32 GiB)
- r5dn.2xlarge (8 vCPU, 64 GiB)
- r5dn.4xlarge (16 vCPU, 128 GiB)
- r5dn.8xlarge (32 vCPU, 256 GiB)
- r5dn.12xlarge (48 vCPU, 384 GiB)
- r5dn.16xlarge (64 vCPU, 512 GiB)
- r5dn.24xlarge (96 vCPU, 768 GiB)
- r6a.xlarge (4 vCPU, 32 GiB)
- r6a.2xlarge (8 vCPU, 64 GiB)
- r6a.4xlarge (16 vCPU, 128 GiB)
- r6a.8xlarge (32 vCPU, 256 GiB)
- r6a.12xlarge (48 vCPU, 384 GiB)
- r6a.16xlarge (64 vCPU, 512 GiB)
- r6a.24xlarge (96 vCPU, 768 GiB)
- r6a.32xlarge (128 vCPU, 1,024 GiB)
- r6a.48xlarge (192 vCPU, 1,536 GiB)
- r6i.metal (128 vCPU, 1,024 GiB)
- r6i.xlarge (4 vCPU, 32 GiB)
- r6i.2xlarge (8 vCPU, 64 GiB)
- r6i.4xlarge (16 vCPU, 128 GiB)
- r6i.8xlarge (32 vCPU，256 GiB)
- r6i.12xlarge (48 vCPU, 384 GiB)
- r6i.16xlarge (64 vCPU, 512 GiB)
- r6i.24xlarge (96 vCPU, 768 GiB)
- r6i.32xlarge (128 vCPU，1,024 GiB)
- r6id.xlarge (4 vCPU, 32 GiB)
- r6id.2xlarge (8 vCPU, 64 GiB)
- r6id.4xlarge (16 vCPU, 128 GiB)
- r6id.8xlarge (32 vCPU, 256 GiB)
- r6id.12xlarge (48 vCPU, 384 GiB)
- r6id.16xlarge (64 vCPU, 512 GiB)
- r6id.24xlarge (96 vCPU, 768 GiB)
- r6id.32xlarge (128 vCPU, 1,024 GiB)
- z1d.metal (48 vCPU, 384 GiB)
- z1d.xlarge (4 vCPU, 32 GiB)
- z1d.2xlarge (8 vCPU, 64 GiB)
- z1d.3xlarge (12 vCPU, 96 GiB)
- z1d.6xlarge (24 vCPU, 192 GiB)
- z1d.12xlarge (48 vCPU, 384 GiB)
- r7iz.xlarge (4 vCPU, 32 GiB)
- r7iz.2xlarge (8 vCPU, 64 GiB)
- r7iz.4xlarge (16 vCPU, 128 GiB)
- r7iz.8xlarge (32 vCPU, 256 GiB)
- r7iz.12xlarge (48 vCPU, 384 GiB)
- r7iz.16xlarge (64 vCPU, 512 GiB)
- r7iz.32xlarge (128 vCPU, 1024 GiB)
- r7iz.metal-16xl (64 vCPU, 512 GiB)
- r7iz.metal-32xl (128 vCPU, 1024 GiB)
2.4.4 这些实例类型在 48 个物理内核中提供 96 个逻辑处理器。它们在两个物理 Intel 插槽的单台服务器上运行。
此实例类型在 24 个物理内核上提供 48 个逻辑处理器。
例 2.5. 加速计算
- p3.2xlarge (8 vCPU, 61 GiB)
- p3.8xlarge (32 vCPU, 244 GiB)
- p3.16xlarge (64 vCPU, 488 GiB)
- p3dn.24xlarge (96 vCPU, 768 GiB)
- p4d.24xlarge (96 vCPU, 1,152 GiB)
- p4de.24xlarge (96 vCPU, 1,152 GiB)
- p5.48xlarge (192 vCPU, 2,048 GiB)
- g4dn.xlarge (4 vCPU, 16 GiB)
- g4dn.2xlarge (8 vCPU, 32 GiB)
- g4dn.4xlarge (16 vCPU, 64 GiB)
- g4dn.8xlarge (32 vCPU, 128 GiB)
- g4dn.12xlarge (48 vCPU, 192 GiB)
- g4dn.16xlarge (64 vCPU, 256 GiB)
- g4dn.metal (96 vCPU, 384 GiB)
- g5.xlarge (4 vCPU, 16 GiB)
- g5.2xlarge (8 vCPU, 32 GiB)
- g5.4xlarge (16 vCPU, 64 GiB)
- g5.8xlarge (32 vCPU, 128 GiB)
- g5.16xlarge (64 vCPU, 256 GiB)
- g5.12xlarge (48 vCPU, 192 GiB)
- g5.24xlarge (96 vCPU, 384 GiB)
- g5.48xlarge (192 vCPU, 768 GiB)
- dl1.24xlarge (96 vCPU, 768 GiB)
† 特定于 Intel；不被 Nvidia 支持
对 GPU 实例类型软件堆栈的支持由 AWS 提供。确保您的 AWS 服务配额可以容纳所需的 GPU 实例类型。
例 2.6. 计算优化
- c5.metal (96 vCPU, 192 GiB)
- c5.xlarge (4 vCPU, 8 GiB)
- c5.2xlarge (8 vCPU, 16 GiB)
- c5.4xlarge (16 vCPU, 32 GiB)
- c5.9xlarge (36 vCPU, 72 GiB)
- c5.12xlarge (48 vCPU, 96 GiB)
- c5.18xlarge (72 vCPU, 144 GiB)
- c5.24xlarge (96 vCPU, 192 GiB)
- c5d.metal (96 vCPU, 192 GiB)
- c5d.xlarge (4 vCPU, 8 GiB)
- c5d.2xlarge (8 vCPU, 16 GiB)
- c5d.4xlarge (16 vCPU, 32 GiB)
- c5d.9xlarge (36 vCPU, 72 GiB)
- c5d.12xlarge (48 vCPU, 96 GiB)
- c5d.18xlarge (72 vCPU, 144 GiB)
- c5d.24xlarge (96 vCPU, 192 GiB)
- c5a.xlarge (4 vCPU, 8 GiB)
- c5a.2xlarge (8 vCPU, 16 GiB)
- c5a.4xlarge (16 vCPU, 32 GiB)
- c5a.8xlarge (32 vCPU, 64 GiB)
- c5a.12xlarge (48 vCPU, 96 GiB)
- c5a.16xlarge (64 vCPU, 128 GiB)
- c5a.24xlarge (96 vCPU, 192 GiB)
- c5ad.xlarge (4 vCPU, 8 GiB)
- c5ad.2xlarge (8 vCPU, 16 GiB)
- c5ad.4xlarge (16 vCPU, 32 GiB)
- c5ad.8xlarge (32 vCPU, 64 GiB)
- c5ad.12xlarge (48 vCPU, 96 GiB)
- c5ad.16xlarge (64 vCPU, 128 GiB)
- c5ad.24xlarge (96 vCPU, 192 GiB)
- c5n.metal (72 vCPU, 192 GiB)
- c5n.xlarge (4 vCPU, 10.5 GiB)
- c5n.2xlarge (8 vCPU, 21 GiB)
- c5n.4xlarge (16 vCPU, 42 GiB)
- c5n.9xlarge (36 vCPU, 96 GiB)
- c5n.18xlarge (72 vCPU, 192 GiB)
- c6a.xlarge (4 vCPU, 8 GiB)
- c6a.2xlarge (8 vCPU, 16 GiB)
- c6a.4xlarge (16 vCPU, 32 GiB)
- c6a.8xlarge (32 vCPU, 64 GiB)
- c6a.12xlarge (48 vCPU, 96 GiB)
- c6a.16xlarge (64 vCPU, 128 GiB)
- c6a.24xlarge (96 vCPU, 192 GiB)
- c6a.32xlarge (128 vCPU, 256 GiB)
- c6a.48xlarge (192 vCPU, 384 GiB)
- c6i.metal (128 vCPU, 256 GiB)
- c6i.xlarge (4 vCPU, 8 GiB)
- c6i.2xlarge (8 vCPU, 16 GiB)
- c6i.4xlarge (16 vCPU, 32 GiB)
- c6i.8xlarge (32 vCPU, 64 GiB)
- c6i.12xlarge (48 vCPU，96 GiB)
- c6i.16xlarge (64 vCPU, 128 GiB)
- c6i.24xlarge (96 vCPU, 192 GiB)
- c6i.32xlarge (128 vCPU, 256 GiB)
- c6id.xlarge (4 vCPU, 8 GiB)
- c6id.2xlarge (8 vCPU, 16 GiB)
- c6id.4xlarge (16 vCPU, 32 GiB)
- c6id.8xlarge (32 vCPU, 64 GiB)
- c6id.12xlarge (48 vCPU, 96 GiB)
- c6id.16xlarge (64 vCPU, 128 GiB)
- c6id.24xlarge (96 vCPU, 192 GiB)
- c6id.32xlarge (128 vCPU, 256 GiB)
例 2.7. 存储优化
- i3.metal (72† vCPU, 512 GiB)
- i3.xlarge (4 vCPU, 30.5 GiB)
- i3.2xlarge (8 vCPU, 61 GiB)
- i3.4xlarge (16 vCPU, 122 GiB)
- i3.8xlarge (32 vCPU, 244 GiB)
- i3.16xlarge (64 vCPU, 488 GiB)
- i3en.metal (96 vCPU, 768 GiB)
- i3en.xlarge (4 vCPU, 32 GiB)
- i3en.2xlarge (8 vCPU, 64 GiB)
- i3en.3xlarge (12 vCPU, 96 GiB)
- i3en.6xlarge (24 vCPU, 192 GiB)
- i3en.12xlarge (48 vCPU, 384 GiB)
- i3en.24xlarge (96 vCPU, 768 GiB)
- i4i.xlarge (4 vCPU, 32 GiB)
- i4i.2xlarge (8 vCPU, 64 GiB)
- i4i.4xlarge (16 vCPU, 128 GiB)
- i4i.8xlarge (32 vCPU, 256 GiB)
- i4i.12xlarge (48 vCPU, 384 GiB)
- i4i.16xlarge (64 vCPU, 512 GiB)
- i4i.24xlarge (96 vCPU, 768 GiB)
- i4i.32xlarge (128 vCPU, 1024 GiB)
- i4i.metal (128 vCPU, 1024 GiB)
† 这个实例类型在 36 个物理内核中提供 72 个逻辑处理器。
虚拟实例类型初始化速度快于 ".metal" 实例类型。
例 2.8. 高内存
- u-3tb1.56xlarge (224 vCPU, 3,072 GiB)
- u-6tb1.56xlarge (224 vCPU, 6,144 GiB)
- u-6tb1.112xlarge (448 vCPU, 6,144 GiB)
- u-6tb1.metal (448 vCPU, 6,144 GiB)
- u-9tb1.112xlarge (448 vCPU, 9,216 GiB)
- u-9tb1.metal (448 vCPU, 9,216 GiB)
- u-12tb1.112xlarge (448 vCPU, 12,288 GiB)
- u-12tb1.metal (448 vCPU, 12,288 GiB)
- u-18tb1.metal (448 vCPU, 18,432 GiB)
- u-24tb1.metal (448 vCPU, 24,576 GiB)
其它资源
2.1.1.6. 标准集群的 AWS 实例类型
OpenShift Dedicated 在 AWS 上提供以下 worker 节点类型和大小：
例 2.9. 常规目的
- m5.xlarge (4 vCPU, 16 GiB)
- m5.2xlarge (8 vCPU, 32 GiB)
- m5.4xlarge (16 vCPU, 64 GiB)
例 2.10. 内存优化
- r5.xlarge (4 vCPU, 32 GiB)
- r5.2xlarge (8 vCPU, 64 GiB)
- r5.4xlarge (16 vCPU, 128 GiB)
例 2.11. 计算优化
- c5.2xlarge (8 vCPU, 16 GiB)
- c5.4xlarge (16 vCPU, 32 GiB)
2.1.1.7. Google Cloud 计算类型
OpenShift Dedicated 在 Google Cloud 上提供以下 worker 节点类型和大小，它们选择具有与其他云实例类型相同的通用 CPU 和内存容量：
e2 和 a2 计算类型仅适用于 CCS。
例 2.12. 常规目的
- custom-4-16384 (4 vCPU, 16 GiB)
- custom-8-32768 (8 vCPU, 32 GiB)
- custom-16-65536 (16 vCPU, 64 GiB)
- custom-32-131072 (32 vCPU, 128 GiB)
- custom-48-199608 (48 vCPU, 192 GiB)
- custom-64-262144 (64 vCPU, 256 GiB)
- custom-96-393216 (96 vCPU, 384 GiB)
- e2-standard-4 (4 vCPU, 16 GiB)
- n2-standard-4 (4 vCPU, 16 GiB)
- e2-standard-8 (8 vCPU, 32 GiB)
- n2-standard-8 (8 vCPU, 32 GiB)
- e2-standard-16 (16 vCPU, 64 GiB)
- n2-standard-16 (16 vCPU, 64 GiB)
- e2-standard-32 (32 vCPU, 128 GiB)
- n2-standard-32 (32 vCPU, 128 GiB)
- n2-standard-48 (48 vCPU, 192 GiB)
- n2-standard-64 (64 vCPU, 256 GiB)
- n2-standard-80 (80 vCPU, 320 GiB)
- n2-standard-96 (96 vCPU, 384 GiB)
- n2-standard-128 (128 vCPU, 512 GiB)
例 2.13. 内存优化
- custom-4-32768-ext (4 vCPU, 32 GiB)
- custom-8-65536-ext (8 vCPU, 64 GiB)
- custom-16-131072-ext (16 vCPU, 128 GiB)
- e2-highmem-4 (4 vCPU, 32 GiB)
- e2-highmem-8 (8 vCPU, 64 GiB)
- e2-highmem-16 (16 vCPU, 128 GiB)
- n2-highmem-4 (4 vCPU, 32 GiB)
- n2-highmem-8 (8 vCPU, 64 GiB)
- n2-highmem-16 (16 vCPU, 128 GiB)
- n2-highmem-32 (32 vCPU, 256 GiB)
- n2-highmem-48 (48 vCPU, 384 GiB)
- n2-highmem-64 (64 vCPU, 512 GiB)
- n2-highmem-80 (80 vCPU, 640 GiB)
- n2-highmem-96 (96 vCPU, 768 GiB)
- n2-highmem-128 (128 vCPU, 864 GiB)
例 2.14. 计算优化
- custom-8-16384 (8 vCPU, 16 GiB)
- custom-16-32768 (16 vCPU, 32 GiB)
- custom-36-73728 (36 vCPU, 72 GiB)
- custom-48-98304 (48 vCPU, 96 GiB)
- custom-72-147456 (72 vCPU, 144 GiB)
- custom-96-196608 (96 vCPU, 192 GiB)
- c2-standard-4 (4 vCPU, 16 GiB)
- c2-standard-8 (8 vCPU, 32 GiB)
- c2-standard-16 (16 vCPU, 64 GiB)
- c2-standard-30 (30 vCPU, 120 GiB)
- c2-standard-60 (60 vCPU, 240 GiB)
- e2-highcpu-8 (8 vCPU, 8 GiB)
- e2-highcpu-16 (16 vCPU, 16 GiB)
- e2-highcpu-32 (32 vCPU, 32 GiB)
- n2-highcpu-8 (8 vCPU, 8 GiB)
- n2-highcpu-16 (16 vCPU, 16 GiB)
- n2-highcpu-32 (32 vCPU, 32 GiB)
- n2-highcpu-48 (48 vCPU, 48 GiB)
- n2-highcpu-64 (64 vCPU, 64 GiB)
- n2-highcpu-80 (80 vCPU, 80 GiB)
- n2-highcpu-96 (96 vCPU, 96 GiB)
例 2.15. 加速计算
- a2-highgpu-1g (12 vCPU, 85 GiB)
- a2-highgpu-2g (24 vCPU, 170 GiB)
- a2-highgpu-4g (48 vCPU, 340 GiB)
- a2-highgpu-8g (96 vCPU, 680 GiB)
- a2-megagpu-16g (96 vCPU, 1.33 TiB)
2.1.1.8. 地区和可用性区域
OpenShift Container Platform 4 支持以下 AWS 区域，并受 OpenShift Dedicated 的支持：
- af-south-1 (Cape Town, AWS opt-in required)
- ap-east-1 (Hong Kong, AWS opt-in required)
- ap-northeast-1（东京）
- ap-northeast-2 （首尔）
- ap-northeast-3 (Osaka)
- ap-south-1（孟买）
- ap-south-2 (Hyderabad, 需要 AWS opt-in)
- ap-southeast-1（新加坡）
- ap-southeast-2（悉尼）
- ap-southeast-3(Jakarta, AWS opt-in required)
- ap-southeast-4 (Melbourne, AWS opt-in required)
- ca-central-1 (Central Canada)
- eu-central-1（法拉克福）
- eu-central-2 (Zurich, AWS opt-in required)
- eu-north-1（斯德哥尔摩）
- eu-south-1 (Milan、AWS opt-in required)
- eu-south-2 (Spain, AWS opt-in required)
- eu-west-1（爱尔兰）
- eu-west-2（伦敦）
- eu-west-3（巴黎）
- me-central-1 (UAE, AWS opt-in required)
- me-south-1 (Bahrain, AWS opt-in required)
- sa-east-1 （圣保罗）
- us-east-1（北弗吉尼亚）
- us-east-2（俄亥俄）
- us-west-1（北加利福尼亚）
- us-west-2（俄勒冈）
目前支持以下 Google Cloud 区域：
- asia-east1, Changhua County, Taiwan
- asia-east2, Hong Kong
- asia-northeast1, Tokyo, Japan
- asia-northeast2, Osaka, Japan
- asia-south1, Mumbai, India
- asia-south2, Delhi, India
- asia-southeast1, Jurong West, Singapore
- australia-southeast1, Sydney, Australia
- australia-southeast2, Melbourne, Australia
- europe-north1, Hamina, Finland
- europe-west1, St. Ghislain, Belgium
- europe-west2, London, England, UK
- europe-west3, Frankfurt, Germany
- europe-west4, Eemshaven, Netherlands
- europe-west6, Zürich, Switzerland
- europe-west8, Milan, Italy
- europe-west12, Turin, Italy
- europe-southwest1, Madrid, Span
- northamerica-northeast1, Montréal, Québec, Canada
- southamerica-east1, Osasco (São Paulo), Brazil
- southamerica-west1, Santiago, Chile
- us-central1, Council Bluffs, Iowa, USA
- us-east1, Moncks Corner, South Carolina, USA
- us-east4, Ashburn, Northern Virginia, USA
- us-west1, The Dalles, Oregon, USA
- us-west2, Los Angeles, California, USA
- me-central1, Doha, Qatar
- me-central2, Dammam, Saudi Arabia
多 AZ 集群只能部署到至少有 3 个可用区的区域（请参阅 AWS 和 Google Cloud）。
每个新的 OpenShift Dedicated 集群都在单一区域的专用虚拟私有云(VPC)中安装，可选择部署到单个可用区(Single-AZ)或多个可用区(Multi-AZ)中。这提供了集群级别的网络和资源隔离，并启用 cloud-provider VPC 设置，如 VPN 连接和 VPC Peering。持久性卷由云块存储支持，并特定于置备的可用区。在将关联的 pod 资源分配给特定的可用区前，持久性卷不会绑定到卷，以防止不可调度的 pod。特定于可用区的资源只可供同一可用区中的资源使用。
部署集群后，无法更改一个或多个可用区的区域和选择。
2.1.1.9. 服务级别协议 (SLA)
任何服务的 SLA 都在 红帽企业协议附录 4 （在线订阅服务）的附录 4 中定义。
2.1.1.10. 有限支持状态
当集群过渡到 有限支持 状态时，红帽不再主动监控集群，SLA 将不再适用，并拒绝对 SLA 的请求。这并不意味着您不再有产品支持。在某些情况下，如果您修复了违反因素，集群可以返回完全支持的状态。但是，在其他情况下，您可能需要删除并重新创建集群。
集群可能会因为许多原因移至有限支持状态，包括以下情况：
- 如果您没有在生命周期结束前将集群升级到支持的版本
红帽不会在其结束日期后为版本提供任何运行时或 SLA 保证。要继续获得支持，请在生命周期结束前将集群升级到受支持的版本。如果您没有在生命周期结束前升级集群，集群会过渡到有限支持状态，直到升级到一个支持版本。
红帽提供了合理的商业支持，从不受支持的版本升级到受支持的版本。但是，如果支持的升级路径不再可用，您可能需要创建新集群并迁移您的工作负载。
- 如果您删除或替换任何由红帽安装和管理的原生 OpenShift Dedicated 组件或任何其他组件
- 如果使用了集群管理员权限，红帽不负责您的任何或授权用户的操作，包括影响基础架构服务、服务可用性或数据丢失的人。如果红帽检测到此类操作，集群可能会过渡到有限支持状态。红帽通知您的状态变化，您应该恢复操作或创建支持问题单来探索可能需要删除和重新创建集群的补救步骤。
如果您对可能造成集群移至有限支持状态或需要进一步帮助的特定操作有疑问，请打开支持票据。
2.1.1.11. 支持
OpenShift Dedicated 包括红帽高级支持，可以使用 红帽客户门户网站 访问。
如需了解有关 OpenShift Dedicated 包含的支持的更多详情，请参阅 覆盖范围页面。
如需支持响应时间，请参阅 OpenShift Dedicated SLA。
2.1.2. 日志记录
OpenShift Dedicated 为 Amazon CloudWatch （在 AWS）或 Google Cloud Logging （在 GCP 上）提供可选集成日志转发。
如需更多信息，请参阅关于日志收集和转发。
2.1.2.1. 集群日志记录
如果启用了集成，可通过 Amazon CloudWatch (AWS)或 Google Cloud Logging (GCP)提供集群审计日志。如果没有启用集成，您可以通过打开支持问题单来请求审计日志。审计日志请求必须指定日期和时间范围，而不是超过 21 天。在请求审计日志时，客户应该注意审计日志的大小超过 GB。
2.1.2.2. 应用程序日志记录
如果已安装，发送到 STDOUT 的应用程序日志将通过集群日志记录堆栈转发到 Amazon CloudWatch （在 AWS 上）或 Google Cloud Logging （在 GCP 上）。
2.1.3. 监控
2.1.3.1. 集群指标
OpenShift Dedicated 集群附带了一个集成的 Prometheus/Grafana 堆栈，用于监控包括 CPU、内存和基于网络的指标。这可以通过 web 控制台访问，也可以通过 Grafana 仪表板查看集群级别状态和容量/使用情况。这些指标还允许 pod 横向自动扩展基于 OpenShift Dedicated 用户提供的 CPU 或内存指标。
2.1.3.2. 集群通知
集群通知是有关集群状态、健康或性能的信息。
集群通知是 Red Hat Site Reliability Engineering (SRE)与您有关受管集群健康状况的主要方法。SRE 也可能使用集群通知来提示您执行操作，以解决或防止集群出现问题。
集群所有者和管理员必须定期检查和操作集群通知，以确保集群保持健康且受支持。
您可以在集群的 Cluster history 选项卡中查看 Red Hat Hybrid Cloud Console 中的集群通知。默认情况下，只有集群所有者接收集群通知作为电子邮件。如果其他用户需要接收集群通知电子邮件，请将每个用户添加为集群的通知联系人。
2.1.4. 网络
2.1.4.1. 应用程序自定义域
从 OpenShift Dedicated 4.14 开始，自定义域 Operator 已被弃用。要在 OpenShift Dedicated 4.14 或更高版本中管理 Ingress，请使用 Ingress Operator。对于 OpenShift Dedicated 4.13 及更早版本，这个功能不会改变。
要将自定义主机名用于路由，您必须通过创建规范名称 (CNAME) 记录来更新 DNS 供应商。您的 CNAME 记录应当将 OpenShift 规范路由器主机名映射到您的自定义域。OpenShift 规范路由器主机名在创建路由后显示在 Route Details 页面中。或者，也可以创建通配符 CNAME 记录，以将给定主机名的所有子域路由到集群的路由器。
2.1.4.2. 集群服务的自定义域
自定义域和子域不适用于平台服务路由，如 API 或 Web 控制台路由，或用于默认应用程序路由。
2.1.4.3. 域验证证书
OpenShift Dedicated 包括集群中内部和外部服务所需的 TLS 安全证书。对于外部路由，每个集群中都提供并安装了两个单独的 TLS 通配符证书，一个用于 Web 控制台，路由默认主机名，另一个用于 API 端点。我们来加密是证书使用的证书颁发机构。集群内的路由（如内部 API 端点 ）使用由集群内置证书颁发机构签名的 TLS 证书，并要求每个 pod 中的 CA 捆绑包信任 TLS 证书。
2.1.4.4. 构建的自定义证书颁发机构
OpenShift Dedicated 支持在从镜像 registry 中拉取镜像时，使用自定义证书颁发机构来被构建信任。
2.1.4.5. 负载均衡器
OpenShift Dedicated 使用最多 5 个不同的负载均衡器：
- 集群内部的 control plane 负载均衡器，用于平衡内部集群通信的流量。
- 用于访问 OpenShift Container Platform 和 Kubernetes API 的外部 control plane 负载均衡器。此负载均衡器可以在 Red Hat OpenShift Cluster Manager 中被禁用。如果禁用了这个负载均衡器，红帽会重新配置 API DNS 以指向内部控制负载均衡器。
- 为红帽保留由红帽保留的外部 control plane 负载均衡器。访问是严格控制的，只有来自允许的堡垒主机的通信才可以进行。
-
默认路由器/入口负载均衡器是默认应用程序负载均衡器，由 URL 中的
apps表示。默认负载均衡器可以在 OpenShift Cluster Manager 中配置，以便可以通过互联网公开访问，或者只有通过已存在的私有连接来私有访问。集群上的所有应用程序路由都会在这个默认路由器负载均衡器上公开，包括日志记录 UI、指标 API 和 registry 等集群服务。 -
可选：一个作为二级应用程序负载均衡器的二级路由器/入口负载均衡器，由 URL 中的
apps2表示。辅助负载均衡器可以在 OpenShift Cluster Manager 中配置，以便可以通过互联网公开访问，或者只有通过已存在的私有连接来私有访问。如果为这个路由器负载均衡器配置了 'Label match'，则只有与此标签匹配的应用程序路由才会在此路由器负载均衡器上公开，否则所有应用程序路由也会在此路由器负载均衡器上公开。 - 可选：可映射到 OpenShift Dedicated 上运行的服务的负载均衡器，以启用高级入口功能，如非 HTTP/SNI 流量或使用非标准端口。对于标准集群，可以以 4 个为一组购买，或者可以在客户云订阅 (CCS) 集群中置备它们；但是，每个 AWS 帐户都有一个配额，用于限制每个集群中可以使用的 Classic Load Balancer 数量。
2.1.4.6. 网络使用量
对于标准 OpenShift Dedicated 集群，网络使用量根据入站、VPC 对等、VPN 和 AZ 流量之间的数据传输来衡量。在标准的 OpenShift Dedicated 基础集群中，提供了 12TB 网络 I/O。用户可以购买额外的网络 I/O，最少单位是 12 TB。对于 CCS OpenShift Dedicated 集群，网络使用量不会被监控，由云供应商直接计费。
2.1.4.7. 集群入口
项目管理员可以为许多不同的用途添加路由注解，包括通过 IP 允许列表进行入口控制。
也可以使用 NetworkPolicy 对象来更改 Ingress 策略，这利用了 ovs-networkpolicy 插件。这允许对入口网络策略进行完全控制到 pod 级别，包括在同一集群中的 pod 间，甚至在同一命名空间中。
所有集群入口流量都将通过定义的负载均衡器。云配置阻止对所有节点的直接访问。
2.1.4.8. 集群出口
通过 EgressNetworkPolicy 对象进行 Pod 出口流量控制可用于防止或限制 OpenShift Dedicated 中的出站流量。
需要来自 control plane 和基础架构节点的公共出站流量，并需要维护集群镜像安全性和集群监控。这要求 0.0.0.0/0 路由仅属于互联网网关；无法通过专用连接路由此范围。
OpenShift Dedicated 集群使用 NAT 网关为离开集群的任何公共出站流量提供一个公共静态 IP。集群部署到接收不同的 NAT 网关的每个子网。对于在多个可用区的 AWS 上部署的集群，最多可有 3 个唯一的静态 IP 地址用于集群出口流量。对于在 Google Cloud 上部署的集群，无论可用区拓扑是什么，worker 节点出口流量都会有 1 个静态 IP 地址。在集群中或未离开公共互联网的任何流量都不会通过 NAT 网关，并且具有属于源自于流量的来源 IP 地址的源 IP 地址。节点 IP 地址是动态的，因此客户在访问私有资源时不应依赖于允许列表中的单个 IP 地址。
客户可以通过在群集上运行 pod 并查询外部服务来确定其公共静态 IP 地址。例如：
$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"
2.1.4.9. 云网络配置
OpenShift Dedicated 允许通过几个云供应商管理的技术配置私有网络连接：
- VPN 连接
- AWS VPC 对等
- AWS Transit Gateway
- AWS Direct Connect
- Google Cloud VPC Network peering
- Google Cloud Classic VPN
- Google Cloud HA VPN
Red Hat SREs 不监控私有网络连接。监控这些连接是客户的职责。
2.1.4.10. DNS 转发
对于具有私有云网络配置的 OpenShift Dedicated 集群，客户可以指定该私有连接上应查询的用于显式提供的域的内部 DNS 服务器。
2.1.4.11. 网络验证
当您将 OpenShift Dedicated 集群部署到现有的 Virtual Private Cloud (VPC) 或创建带有集群新子网的额外机器池时，网络验证检查会自动运行。检查会验证您的网络配置并突出显示错误，允许您在部署前解决配置问题。
您还可以手动运行网络验证检查以验证现有集群的配置。
其他资源
- 有关网络验证检查的更多信息，请参阅 网络验证。
2.1.5. Storage
2.1.5.1. Encrypted-at-rest OS/node 存储
control plane 节点使用 encrypted-at-rest-EBS 存储。
2.1.5.2. encrypted-at-rest PV
默认情况下，用于持久性卷 (PV) 的 EBS 卷是 encrypted-at-rest。
2.1.5.3. 块存储 (RWO)
持久性卷 (PV) 由 AWS EBS 和 Google Cloud 持久磁盘块存储支持，该存储使用 ReadWriteOnce (RWO) 访问模式。在标准的 OpenShift Dedicated 基础集群中，为 PV 提供 100 GB 块存储，该块存储会根据应用程序请求动态置备和回收。额外的持久性存储可以 500 GB 的递增的形式购买。
PV 每次只能附加到一个节点，并特定于置备的可用区，但它们可以附加到可用区中的任何节点。
每个云供应商都有自己的限制，用于把 PV 附加到单一节点。详情请参阅 AWS 实例类型限值 或 Google Cloud Platform 自定义机器类型 。
2.1.6. 平台
2.1.6.1. 集群备份策略
客户对应用程序和应用程序数据进行备份计划至关重要。
应用程序和应用程序数据备份不是 OpenShift Dedicated 服务的一部分。每个 OpenShift Dedicated 集群中的所有 Kubernetes 对象都会被备份，以便在不太可能的情况下进行提示恢复，因为集群无法正常运行。
备份存储在与集群相同的帐户的安全对象存储(Multi-AZ)存储桶中。节点根卷不会被备份，因为 Red Hat Enterprise Linux CoreOS 完全由 OpenShift Container Platform 集群管理，且没有有状态的数据应存储在节点的 root 卷中。
下表显示了备份的频率：
| 组件 | 快照频率 | 保留 | 备注 |
|---|---|---|---|
| 完整对象存储备份 | 每天 0100 UTC | 7 天 | 这是所有 Kubernetes 对象的完整备份。在这个备份调度中没有备份持久性卷 (PV)。 |
| 完整对象存储备份 | 每周的周一 0200 UTC | 30 天 | 这是所有 Kubernetes 对象的完整备份。这个备份调度中没有备份 PV。 |
| 完整对象存储备份 | 每小时的第 17 分钟 | 24 小时 | 这是所有 Kubernetes 对象的完整备份。这个备份调度中没有备份 PV。 |
2.1.6.2. 自动缩放
OpenShift Dedicated 上提供了节点自动扩展功能。如需有关在集群中自动扩展节点的更多信息，请参阅关于集群中的自动扩展节点。
2.1.6.3. 守护进程集
客户可以在 OpenShift Dedicated 上创建并运行 DaemonSet。要将 DaemonSet 限制为仅在 worker 节点上运行，请使用以下 nodeSelector：
...
spec:
nodeSelector:
role: worker
...2.1.6.4. 多个可用区
在多个可用区集群中，控制节点分布在可用区中，每个可用区需要至少三个 worker 节点。
2.1.6.5. 节点标签
红帽会在节点创建过程中创建自定义节点标签，目前无法在 OpenShift Dedicated 集群中更改。
2.1.6.6. OpenShift version
OpenShift Dedicated 作为服务运行，并与最新的 OpenShift Container Platform 版本保持最新状态。
2.1.6.7. 升级
有关升级策略和步骤的更多信息，请参阅 OpenShift Dedicated 生命周期。
2.1.6.8. Windows 容器
目前，OpenShift Dedicated 不提供 Windows 容器。
2.1.6.9. 容器引擎
OpenShift Dedicated 在 OpenShift 4 上运行，并使用 CRI-O 作为唯一可用的容器引擎。
2.1.6.10. 操作系统
OpenShift Dedicated 在 OpenShift 4 上运行，并使用 Red Hat Enterprise Linux CoreOS 作为所有 control plane 和 worker 节点的操作系统。
2.1.6.11. Red Hat Operator 支持
红帽工作负载通常是指通过 Operator Hub 提供的红帽提供的 Operator。红帽工作负载不由红帽 SRE 团队管理，且必须在 worker 节点上部署。这些 Operator 可能需要额外的红帽订阅，并可能产生额外的云基础架构成本。这些红帽提供的 Operator 示例包括：
- Red Hat Quay
- Red Hat Advanced Cluster Management
- Red Hat Advanced Cluster Security
- Red Hat OpenShift Service Mesh
- OpenShift Serverless
- Red Hat OpenShift Logging
- Red Hat OpenShift Pipelines
2.1.6.12. Kubernetes Operator 支持
OperatorHub 市场中列出的所有 Operator 都应该可用于安装。从 OperatorHub 安装的 Operator （包括 Red Hat Operator）不会作为 OpenShift Dedicated 服务的一部分进行管理。如需有关给定 Operator 的支持性的更多信息，请参阅红帽客户门户网站。
2.1.7. 安全性
本节提供有关 OpenShift Dedicated 安全的服务定义的信息。
2.1.7.1. 身份验证供应商
集群的身份验证被配置为 Red Hat OpenShift Cluster Manager 集群创建过程的一部分。OpenShift 不是一个身份提供程序，对集群的所有访问都必须由客户管理，作为其集成解决方案的一部分。支持置备同时置备的多个身份提供程序。支持以下身份提供程序：
- GitHub 或 GitHub Enterprise OAuth
- GitLab OAuth
- Google OAuth
- LDAP
- OpenID 连接
2.1.7.2. 特权容器
默认情况下，OpenShift Dedicated 上无法使用特权容器。dedicated-admins 组的成员可以使用 anyuid 和 nonroot，这应该可以满足多种用例。特权容器仅适用于 cluster-admin 用户。
2.1.7.3. 客户管理员用户
除了普通用户外，OpenShift Dedicated 还提供对名为 dedicated-admin 的 OpenShift Dedicated 特定组的访问。属于 dedicated-admin 组成员的任何用户：
- 具有集群中所有客户创建项目的管理员访问权限。
- 可以管理集群的资源配额和限值。
-
可以添加和管理
NetworkPolicy对象。 - 可以查看集群中特定节点和 PV 的信息，包括调度程序信息。
-
可以访问集群上保留的
dedicated-admin项目，它允许使用提升的特权创建服务帐户，同时还能够为集群上的项目更新默认限值和配额。 -
可以安装来自 OperatorHub 的 Operator (
*verbs在所有*.operators.coreos.comAPI 组中)。
2.1.7.4. 集群管理角色
作为具有客户云订阅 (CCS) 的 OpenShift Dedicated 的管理员，您可以访问 cluster-admin 角色。使用 cluster-admin 角色登录到帐户时，用户最多具有控制和配置集群的不受限制的访问权限。Webhook 会阻止一些配置以防止集群的更改，或者由于它们被 OpenShift Cluster Manager 管理，所以任何集群内的更改都会被覆盖。
2.1.7.5. 项目自助服务
默认情况下，所有用户都能够创建、更新和删除他们的项目。如果 dedicated-admin 组的成员从经过身份验证的用户移除 self-provisioner 角色，则可以受限制：
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
通过应用可以恢复限制：
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
2.1.7.6. 法规合规性
OpenShift Dedicated 遵循常见的安全和控制最佳实践。下表中概述了认证。
| Compliance | AWS 上的 OpenShift Dedicated | GCP 上的 OpenShift Dedicated |
|---|---|---|
| HIPAA 认证的 | 是（仅限客户云订阅） | 是（仅限客户云订阅） |
| ISO 27001 | 是 | 是 |
| PCI DSS | 是 | 是 |
| SOC 2 类型 2 | 是 | 是 |
2.1.7.7. 网络安全性
每个 OpenShift Dedicated 集群都由云基础架构级别的安全网络配置使用防火墙规则(AWS 安全组或 Google Cloud Compute Engine 防火墙规则)进行保护。AWS 上的 OpenShift Dedicated 客户也会保护对 AWS Shield Standard 的 DDoS 攻击。同样，OpenShift Dedicated 在 GCP 上使用的所有 GCP 负载均衡器和公共 IP 地址都可以通过 Google Cloud Armor Standard 保护 DDoS 的攻击。
2.1.7.8. etcd 加密
在 OpenShift Dedicated 中，control plane 存储默认加密，这包括 etcd 卷的加密。这种存储级别加密通过云供应商的存储层提供。
您还可以启用 etcd 加密，加密 etcd 中的密钥值，而不是密钥。如果启用 etcd 加密，则会加密以下 Kubernetes API 服务器和 OpenShift API 服务器资源：
- Secrets
- 配置映射
- Routes
- OAuth 访问令牌
- OAuth 授权令牌
默认情况下不启用 etcd 加密功能，它只能在集群安装过程中启用。即使启用了 etcd 加密，则有权访问 control plane 节点或 cluster-admin 权限的任何人都可以访问 etcd 密钥值。
通过在 etcd 中为密钥值启用 etcd 加密，则会出现大约 20% 的性能开销。除了加密 etcd 卷的默认 control plane 存储加密外，还会引入第二层加密的开销。红帽建议仅在特别需要时才启用 etcd 加密。
