第 3 章 策略和服务定义

3.1. OpenShift Dedicated 服务定义

3.1.1. 帐户管理

3.1.1.1. 账单

每个 OpenShift Dedicated 集群都需要至少购买基础集群,并为每个集群提供两个账单选项: Standard 和 Customer Cloud Subscription(CCS)。

标准 OpenShift Dedicated 集群部署到自己的云基础架构帐户,每个帐户都由红帽所有。红帽负责这一帐户,而云基础架构成本则直接被红帽支付。客户仅支付红帽订阅成本。

在 CCS 模型中,客户直接为云成本支付云基础架构供应商,而云基础架构帐户则是客户组织的一部分,具有授予红帽的特定访问权限。在这种模式中,客户为 CCS 订阅支付红帽,并支付云提供商作为云成本。客户负责预先购买或提供保留的实例(RI)计算实例,以确保云基础架构成本较低。

可以为 OpenShift Dedicated 集群购买其他资源,包括:

  • 其他节点(可以使用机器池的不同类型和大小)
  • 中间件(JBoss EAP、JBoss Fuse 等)- 基于特定中间件组件的额外定价
  • 增大 500 GB 的额外存储(仅限标准;包含 100 GB)
  • 额外的 12 TiB 网络 I/O(仅限标准;12 TB 包括)
  • 服务的负载均衡器包括在 4 的捆绑包中 ; 启用非 HTTP/SNI 流量或非标准端口(仅限标准)

3.1.1.2. 集群自助服务

客户可从 OpenShift Cluster Manager Hybrid Cloud Console 创建、扩展和删除其集群,只要他们已购买了必要的订阅。

Red Hat OpenShift Cluster Manager 中的操作不能直接从集群内执行,因为这可能会造成负面影响,包括自动恢复所有操作。

3.1.1.3. 云供应商

OpenShift Dedicated 在以下云供应商中将 OpenShift Container Platform 集群作为受管服务提供:

  • Amazon Web Services (AWS)
  • Google Cloud Platform (GCP)

3.1.1.4. 实例类型

单一可用区集群至少需要 2 个 worker 节点,供客户云订阅(CCS)集群部署到单个可用区。标准集群至少需要 4 个 worker 节点。这些 4 个 worker 节点包含在基本订阅中。

多个可用区集群至少需要 3 个 worker 节点用于客户云订阅(CCS)集群,1 个部署到每个 3 个可用区。标准集群至少需要 9 个 worker 节点。这些 9 个 worker 节点包含在基本订阅中,且必须在 3 的多个节点中购买额外的节点,才能维护正确的节点分发。

Worker 节点必须在单个 OpenShift Dedicated 集群中都相同类型和大小。

注意

在集群创建后无法更改默认机器池节点类型和大小。

红帽还提供 control plane 和基础架构节点。至少 3 个 control plane 节点可以处理 etcd 和 API 相关的工作负载。至少有 2 个基础架构节点用于处理指标、路由、Web 控制台和其他工作负载。您不能在 control plane 和基础架构节点上运行任何工作负载。您要运行的所有工作负载都必须部署到 worker 节点上。有关必须在 worker 节点上部署的红帽工作负载的更多信息,请参阅下面的 Red Hat Operator 支持部分。

注意

每个 worker 节点上保留大约 1 个 vCPU 内核和 1 GiB 内存,并从可分配的资源中删除。这是运行 底层平台所需进程所必需的。这包括系统守护进程,如 udev、kubelet、容器运行时等,以及内核保留的帐户。OpenShift Container Platform 核心系统(如审计日志聚合、指标收集、DNS、镜像 registry、SDN 等)可能会消耗额外的可分配资源来维护集群的稳定性和维护性。消耗的额外资源可能会根据使用情况而有所不同。

重要

自 OpenShift Dedicated 版本 4.8.35, 4.9.26, 4.10.6 开始,OpenShift Dedicated 默认每个 pod pid pid 限制为 4096。如果要启用这个 PID 限制,必须将 OpenShift Dedicated 集群升级到这些版本或更新版本。带有之前版本的 OpenShift Dedicated 集群使用默认 PID 限制为 1024

您不能在任何 OpenShift Dedicated 集群上配置每个 pod 的 PID 限制。

3.1.1.5. 客户 Cloud Subscription 集群的 AWS 实例类型

OpenShift Dedicated 在 AWS 上提供以下 worker 节点实例类型和大小:

例 3.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)
  • 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)

2.4.4 这些实例类型在 48 个物理内核中提供 96 个逻辑处理器。它们在两个物理 Intel 套接字的单台服务器上运行。

例 3.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)

例 3.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)

例 3.4. memory-optimized

  • 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)
  • 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)
  • 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)

2.4.4 这些实例类型在 48 个物理内核中提供 96 个逻辑处理器。它们在两个物理 Intel 套接字的单台服务器上运行。

此实例类型在 24 个物理内核上提供 48 个逻辑处理器。

例 3.5. compute-optimized

  • 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)
  • 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)

例 3.6. 存储优化

  • 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)

<.> 这个实例类型在 36 个物理内核中提供 72 个逻辑处理器。

注意

虚拟实例类型初始化速度快于"裸机"实例类型。

其它资源

3.1.1.6. 标准集群的 AWS 实例类型

OpenShift Dedicated 在 AWS 上提供以下 worker 节点类型和大小:

例 3.7. 常规用途

  • m5.xlarge(4 个 vCPU,16 GiB)
  • m5.2xlarge(8 vCPU,32 GiB)
  • m5.4xlarge(16 vCPU,64 GiB)

例 3.8. memory-optimized

  • r5.xlarge (4 vCPU, 32 GiB)
  • r5.2xlarge (8 vCPU, 64 GiB)
  • r5.4xlarge(16 vCPU,128 GiB)

例 3.9. compute-optimized

  • c5.2xlarge (8 vCPU, 16 GiB)
  • c5.4xlarge (16 vCPU, 32 GiB)

3.1.1.7. Google Cloud 计算类型

OpenShift Dedicated 在 Google Cloud 上提供以下 worker 节点类型和大小,它们被选择为具有与其它云实例类型相同的通用 CPU 和内存容量:

例 3.10. 常规用途

  • custom-4-16384(4 vCPU,16 GiB)
  • custom-8-32768(8 vCPU, 32 GiB)
  • 自定义-16-65536(16 vCPU,64 GiB)

例 3.11. memory-optimized

  • custom-4-32768-ext(4 vCPU,32 GiB)
  • custom-8-65536-ext(8 vCPU,64 GiB)
  • custom-16-131072-ext(16 vCPU,128 GiB)

例 3.12. compute-optimized

  • custom-8-16384(8 个 vCPU,16 GiB)
  • custom-16-32768(16 vCPU, 32 GiB)

3.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-southeast-1(新加坡)
  • ap-southeast-2(悉尼)
  • ap-southeast-3(Jakarta, AWS opt-in required)
  • ca-central-1(Central Canada)
  • eu-central-1(法拉克福)
  • eu-north-1(斯德哥尔摩)
  • eu-south-1(Milan,AWS opt-in required)
  • eu-west-1(爱尔兰)
  • eu-west-2(伦敦)
  • eu-west-3(巴黎)
  • 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, Kong Kong
  • asia-northeast1,东京,日本
  • asia-northeast2, Osaka, Japan
  • asia-northeast3, Seoul, Korea
  • asia-south1, Mumbai, India
  • asia-southeast1, Jurong West, Singapore
  • asia-southeast2, Jakarta, Indonesia
  • europe-north1, Hamina, Finland
  • europe-west1, St. Ghislain, Belgium
  • europe-west2、伦敦、England、英国
  • europe-west3、Frankfurt、德国
  • europe-west4, Eemshaven, Netherlands
  • europe-west6, Z-2020:08rich, Switzerland
  • northamerica-northeast1, Montréal, Québec, Canada
  • southamerica-east1, Osasco(巴西圣保罗)
  • 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
  • us-west3, Salt Lake City, Utah, USA
  • us-west4, Las Vegas, Nevada, USA

多AZ 集群只能在至少 3 个可用区的区域进行部署(请参阅 AWSGoogle Cloud)。

每个新的 OpenShift Dedicated 集群都在单一区域内安装在一个专用虚拟私有云(VPC),同时可选择部署到单一可用区(Single-AZ)或跨多个可用区(Multi-AZ)。这提供了集群级别的网络和资源隔离,并启用 cloud-provider VPC 设置,如 VPN 连接和 VPC Peering。持久性卷由云块存储支持,它们特定于置备它们的可用区。在关联的 pod 资源被分配到特定的可用区前,持久性卷不会绑定到卷,以防止不可调度的 pod。特定于区域的可用资源仅供同一可用区中的资源使用。

警告

部署集群后,单个区域和多可用区的选择不会更改。

3.1.1.9. 服务级别协议 (SLA)

服务本身的所有 SLA 均在 红帽企业协议附录 4(Online Subscription Services)的附录 4 中定义。

3.1.1.10. 有限的支持状态

当集群过渡到 有限支持状态时,红帽不再主动监控集群,SLA 将不再适用,并拒绝对 SLA 要求的信用。并不意味着您不再有产品支持。在某些情况下,如果修复违反因素,集群就可以返回完全支持的状态。然而,在其他情况下,您可能需要删除并重新创建集群。

出于很多原因,集群可能会转换到有限支持状态,包括以下情况:

如果您没有在生命周期结束前将集群升级到受支持的版本

红帽不会在其生命周期日期后为版本进行任何运行时或 SLA 保证。要继续获得支持,请在生命周期结束前将集群升级到受支持的版本。如果您没有在生命周期结束前升级集群,集群会变为有限支持状态,直到升级到支持版本。

红帽提供了商业合理的支持,从不受支持的版本升级到受支持的版本。但是,如果支持的升级路径不再可用,您可能需要创建新集群并迁移工作负载。

如果删除或替换任何原生 OpenShift Dedicated 组件或由红帽安装和管理的任何其他组件
如果使用集群管理员权限,红帽并不负责您或授权用户的操作,包括影响基础架构服务、服务可用性或数据丢失的那些操作。如果红帽检测到此类操作,集群可能会转换到有限支持状态。红帽通知您状态更改,您应该恢复操作或创建支持问题单,以探索可能需要删除并重新创建集群所需的补救步骤。

如果您对可能导致集群转换到有限支持状态或需要进一步帮助的具体操作有疑问,请打开支持票据。

3.1.1.11. 支持

OpenShift Dedicated 包括 Red Hat Premium 支持,它可使用 红帽客户门户网站 访问。

如需了解 OpenShift Dedicated 包括支持 的内容,请参阅 覆盖范围页

如需了解支持响应时间,请参阅 OpenShift Dedicated SLA

3.1.2. 日志记录

OpenShift Dedicated 提供可选的集成日志转发到 Amazon CloudWatch。

3.1.2.1. 集群审计日志记录

如果启用了集成,集群审计日志可以通过 Amazon CloudWatch 获取。如果没有启用集成,您可以通过打开支持问题单来请求审计日志。审计日志请求必须指定超过 21 天的日期和时间。在请求审计日志时,客户应注意审计日志的规模是每天的几 GB。

3.1.2.2. 应用程序日志记录

发送到 STDOUT 的应用程序日志由 Fluentd 收集,并通过集群日志记录堆栈转发到 Amazon CloudWatch(如果已安装)。

3.1.3. 监控

3.1.3.1. 集群指标

OpenShift Dedicated 集群附带集成的 Prometheus/Grafana 堆栈,用于集群监控,包括 CPU、内存和基于网络的指标。这可通过 Web 控制台访问,也可用于通过 Grafana 仪表板查看集群级别的状态和容量/使用。这些指标还允许根据 OpenShift Dedicated 用户提供的 CPU 或内存指标来横向 pod 自动扩展。

3.1.3.2. 集群状态通知

红帽通过 Red Hat OpenShift Cluster Manager 中的集群仪表板组合来沟通 OpenShift Dedicated 集群的健康和状态,并将电子邮件通知发送到最初部署集群的联系电子邮件地址。

3.1.4. 网络

3.1.4.1. 应用程序自定义域

要将自定义主机名用于路由,您必须通过创建规范名称(CNAME)记录来更新您的 DNS 供应商。您的 CNAME 记录应该将 OpenShift 规范路由器主机名映射到您的自定义域。OpenShift 规范路由器主机名在路由创建后显示在 Route Details 页面中。另外,也可以创建一个通配符 CNAME 记录,以将给定主机名的所有子域路由到集群的路由器。

3.1.4.2. 集群服务的自定义域

自定义域和子域不适用于平台服务路由,如 API 或 Web 控制台路由,或默认应用程序路由。

3.1.4.3. 域验证证书

OpenShift Dedicated 包括集群中内部和外部服务所需的 TLS 安全证书。对于外部路由,有两个,每个集群中提供了独立的 TLS 通配符证书,一个用于 Web 控制台,一个用于路由默认主机名,第二个用于 API 端点。让我们的 Encrypt 是用于证书的证书颁发机构。集群中的路由,例如内部 API 端点,使用由集群内置证书颁发机构签名的 TLS 证书,并需要每个 pod 中用于信任 TLS 证书的 CA 捆绑包。

3.1.4.4. 构建的自定义证书颁发机构

OpenShift Dedicated 支持在从镜像 registry 中拉取镜像时,使用构建信任自定义证书颁发机构。

3.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 中的应用程序表示。可以在 OpenShift Cluster Manager 中配置默认负载均衡器,以便可以通过互联网公开访问,或者只能通过已存在的私有连接进行私有访问。集群中的所有应用程序路由都会在这个默认路由器负载均衡器上公开,包括日志记录 UI、指标 API 和 registry 等集群服务。
  • 可选: Secondary router/ingress 负载均衡器,它是一个二级应用程序负载均衡器,由 URL 中的 apps2 表示。可以在 OpenShift Cluster Manager 中配置二级负载均衡器,以便可以通过互联网公开访问,或者只能通过已存在的私有连接进行私有访问。如果为这个路由器负载均衡器配置了 "Label match',则只有与该标签匹配的应用程序路由才会在这个路由器负载均衡器上公开,否则所有应用程序路由也会在这个路由器负载均衡器上公开。
  • 可选:可映射到 OpenShift Dedicated 上运行的服务的负载均衡器,以启用高级入口功能,如非 HTTP/SNI 流量或使用非标准端口。这些可以在 4 个标准集群内购买,也可以不对客户云订阅(CCS)集群进行置备,但每个 AWS 帐户都有一个 限制可在每个集群中使用的 Classic Load Balancer 数量 的配额。

3.1.4.6. 网络使用量

对于标准 OpenShift Dedicated 集群,网络使用量会根据入站、VPC 对等、VPN 和 AZ 流量之间的数据传输来衡量。在标准 OpenShift Dedicated 基础集群中,提供了 12 TB 的网络 I/O。可使用 12 TB 增量购买额外网络 I/O。对于 CCS OpenShift Dedicated 集群,网络使用量不会被监控,且被云供应商直接被禁止。

3.1.4.7. 集群入口

项目管理员可以为许多不同的用途添加路由注解,包括通过 IP 允许列表进行入口控制。

也可以使用利用 ovs-networkpolicy 插件的 NetworkPolicy 对象来更改 Ingress 策略。这允许对 ingress 网络策略进行完全控制到 pod 级别,包括同一集群上的 pod,甚至在同一命名空间中。

所有集群入口流量都通过定义的负载均衡器。云配置阻止对所有节点的直接访问。

3.1.4.8. 集群出口

Pod 出口流量控制通过 EgressNetworkPolicy 对象,以防止或限制 OpenShift Dedicated 中的出站流量。

需要来自 control plane 和基础架构节点的公共出站流量,需要维护集群镜像安全性和集群监控。这要求 0.0.0.0/0 路由只属于互联网网关;无法通过专用连接路由此范围。

OpenShift Dedicated 集群使用 NAT 网关为集群发出任何公共出站流量提供公共静态 IP。部署集群的每个子网都会获得不同的 NAT 网关。对于在带有多个可用区的 AWS 上部署的集群,集群出口流量可以包括 3 个唯一的静态 IP 地址。对于在 Google Cloud 上部署的集群,无论可用区拓扑,都需要一个用于 worker 节点出口流量的静态 IP 地址。任何保留在集群中或不进入公共互联网的流量都不会通过 NAT 网关,并将具有属于流量来源的节点的源 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.]+'"

3.1.4.9. 云网络配置

OpenShift Dedicated 允许通过多个云供应商管理技术配置私有网络连接:

  • VPN 连接
  • AWS VPC 对等
  • AWS Transit Gateway
  • AWS Direct Connect
  • Google Cloud VPC 网络 peering
  • Google Cloud Classic VPN
  • Google Cloud HA VPN
重要

Red Hat SRE 不监控私有网络连接。监控这些连接是客户的职责。

3.1.4.10. DNS 转发

对于具有私有云网络配置的 OpenShift Dedicated 集群,客户可以指定该私有连接上可用的内部 DNS 服务器,以便明确提供域。

3.1.5. 存储

3.1.5.1. encrypted-at-rest OS/node 存储

control plane 节点使用 encrypted-at-rest-EBS 存储。

3.1.5.2. encrypted-at-rest PV

默认情况下,用于持久性卷(PV)的 EBS 卷是 encrypted-at-rest。

3.1.5.3. 块存储(RWO)

AWS EBS 和 Google Cloud 持久磁盘块存储支持持久性卷(PV),它使用 ReadWriteOnce(RWO)访问模式。在标准的 OpenShift Dedicated 基础集群中,为 PV 提供 100 GB 的块存储,该 PV 根据应用程序请求动态置备和回收。可使用 500 GB 增量购买额外的持久性存储。

PV 一次只能附加到一个节点,并特定于置备它们的可用区,但可以附加到可用区中的任何节点。

每个云供应商都有自己的限制,对单个节点可以附加多少个 PV。详情请参阅 AWS 实例类型 限制或 Google Cloud Platform 自定义机器类型

3.1.5.4. 共享存储(RWX)

AWS CSI Driver 可用于为 AWS 上的 OpenShift Dedicated 提供 RWX 支持。提供了一个 community Operator 来简化设置。详情请参阅 AWS 上的 OpenShift Dedicated 和 Red Hat OpenShift Service 的 AWS EFS 设置

3.1.6. 平台

3.1.6.1. 集群备份策略

重要

客户为其应用程序和应用程序数据有备份计划非常重要。

应用程序和应用程序数据备份不是 OpenShift Dedicated 服务的一部分。每个 OpenShift Dedicated 集群中的所有 Kubernetes 对象都被备份,以便在不太可能出现提示恢复的情况下,集群无法正常运行。

备份存储在与集群相同的帐户中的安全对象存储(Multi-AZ)存储桶中。节点根卷没有备份,因为 Red Hat Enterprise Linux CoreOS 由 OpenShift Container Platform 集群完全管理,且没有有状态的数据存储在节点的根卷中。

下表显示了备份的频率:

组件快照频率保留备注

完整对象存储备份

每日为 0100 UTC

7 天

这是所有 Kubernetes 对象的完整备份。在此备份调度中不会备份持久性卷(PV)。

完整对象存储备份

每周一至 0200 UTC

30 天

这是所有 Kubernetes 对象的完整备份。这个备份调度没有备份 PV 备份。

完整对象存储备份

每小时每小时为 17 分钟。

24 小时

这是所有 Kubernetes 对象的完整备份。这个备份调度没有备份 PV 备份。

3.1.6.2. 自动缩放

目前,OpenShift Dedicated 不提供节点自动扩展。

3.1.6.3. 守护进程集

客户可以在 OpenShift Dedicated 上创建并运行 DaemonSet。要将 DaemonSet 限制为仅在 worker 节点上运行,请使用以下 nodeSelector:

...
spec:
  nodeSelector:
    role: worker
...

3.1.6.4. 多个可用区

在多个可用区集群中,控制节点分布到可用区,每个可用区需要至少三个 worker 节点。

3.1.6.5. 节点标签

红帽在创建节点的过程中创建自定义节点标签,目前无法在 OpenShift Dedicated 集群上更改。

3.1.6.6. OpenShift 版本

OpenShift Dedicated 作为一个服务运行,使用最新的 OpenShift Container Platform 版本保持最新状态。

3.1.6.7. 升级

如需有关升级策略和步骤的更多信息,请参阅 OpenShift Dedicated 生命周期

3.1.6.8. Windows 容器

目前,Windows 容器在 OpenShift Dedicated 上不可用。

3.1.6.9. 容器引擎

OpenShift Dedicated 在 OpenShift 4 上运行,并使用 CRI-O 作为唯一可用的容器引擎。

3.1.6.10. 操作系统

OpenShift Dedicated 在 OpenShift 4 上运行,并使用 Red Hat Enterprise Linux CoreOS 作为所有 control plane 和 worker 节点的操作系统。

3.1.6.11. Red Hat Operator 支持

红帽工作负载通常是指通过 Operator Hub 提供的红帽提供的 Operator。红帽工作负载不是由 Red Hat 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

3.1.6.12. Kubernetes Operator 支持

OperatorHub marketplace 中列出的所有 Operator 都应该可用于安装。从 OperatorHub 安装的 Operator(包括 Red Hat Operator)没有作为 OpenShift Dedicated 服务的一部分进行管理。如需有关给定 Operator 的支持性的更多信息,请参阅红帽客户门户网站

3.1.7. 安全性

本节提供有关 OpenShift Dedicated 安全性的服务定义的信息。

3.1.7.1. 身份验证供应商

集群的身份验证已配置为 Red Hat OpenShift Cluster Manager 集群创建过程的一部分。OpenShift 不是身份提供程序,所有对集群的访问都必须作为其集成解决方案的一部分由客户进行管理。支持置备多个身份提供程序。支持以下身份提供程序:

  • GitHub 或 GitHub Enterprise OAuth
  • GitLab OAuth
  • Google OAuth
  • LDAP
  • OpenID 连接

3.1.7.2. 特权容器

默认情况下,OpenShift Dedicated 不提供特权容器。anyuidnonroot 安全性上下文约束可供 dedicated-admins 组的成员使用,并且应处理许多用例。特权容器仅适用于 cluster-admin 用户。

3.1.7.3. 客户管理员用户

除了普通用户外,OpenShift Dedicated 还提供对特定 OpenShift Dedicated 组的访问权限,名为 dedicated-admin。属于 dedicated-admin 组成员的集群中的任何用户:

  • 具有集群中所有客户创建项目的管理员访问权限。
  • 可以管理集群上的资源配额和限值。
  • 您可以添加和管理 NetworkPolicy 对象。
  • 可以查看集群中特定节点和 PV 的信息,包括调度程序信息。
  • 可以访问集群上保留的 dedicated-admin 项目,允许创建具有升级权限的服务帐户,还可以为集群中的项目更新默认限值和配额。

3.1.7.4. 集群管理角色

作为带有客户 Cloud Subscriptions(CCS)的 OpenShift Dedicated 管理员,您可以访问 cluster-admin 角色。在登录到具有 cluster-admin 角色的帐户时,用户最多具有控制和配置集群的不受限制的访问权限。一些配置被 webhook 被阻止,以防止关闭集群,或者因为在 OpenShift Cluster Manager 中管理,并会覆盖集群内的任何更改。

3.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

3.1.7.6. 法规合规性

OpenShift Dedicated 遵循用于安全和控制的常见行业最佳实践。下表中列出了认证。

表 3.1. OpenShift Dedicated 的安全性和控制认证

认证AWS 上的 OpenShift DedicatedGCP 上的 OpenShift Dedicated

ISO 27001

PCI DSS

SOC 2 类型 2

3.1.7.7. 网络安全

使用 AWS 上的 OpenShift Dedicated,AWS 提供了对所有负载平衡器的标准 DDoS 保护,名为 AWS Shield。这针对所有面向 OpenShift Dedicated 的公共相关负载平衡,对最常用的 3 和 4 级攻击提供 95% 的保护。为进入 haproxy 路由器的 HTTP 请求添加 10 秒超时,以接收响应,或者连接无法提供额外的保护。

3.1.7.8. etcd 加密

在 OpenShift Dedicated 中,control plane 存储默认以静态方式加密,其中包括对 etcd 卷的加密。这种存储级别的加密通过云提供商的存储层提供。

您还可以启用 etcd 加密,它加密 etcd 中的键值,而不是密钥。如果启用 etcd 加密,则以下 Kubernetes API 服务器和 OpenShift API 服务器资源会被加密:

  • Secrets
  • 配置映射
  • Routes
  • OAuth 访问令牌
  • OAuth 授权令牌

etcd 加密功能没有被默认启用,且只能在集群安装时启用。即使启用了 etcd 加密,etcd 键值可以被具有 control plane 节点或 cluster-admin 权限的访问权限的用户访问。

重要

通过在 etcd 中为键值启用 etcd 加密,您将降低大约 20% 的性能开销。除了对 etcd 卷进行加密的默认 control plane 存储加密外,开销还引进了这个第二层加密的开销。红帽建议仅在为您的用例特殊需要时启用 etcd 加密。