Menu Close
Settings Close

Language and Page Formatting Options

OpenShift Dedicated 简介

OpenShift Dedicated 4

OpenShift Dedicated 架构概述

摘要

本文档概述了 OpenShift Dedicated 中的平台和应用程序架构。

第 1 章 了解 OpenShift Dedicated

OpenShift Dedicated 在 Kubernetes 中使用其基础,是一个完整的 OpenShift Container Platform 集群,作为云服务提供,为高可用性配置,并专用于单一客户。

1.1. OpenShift Dedicated 概述

OpenShift Dedicated 由 Red Hat 管理,并托管在 Amazon Web Services(AWS)或 Google Cloud Platform(GCP)上。每个 OpenShift Dedicated 集群都附带一个完全管理的 control plane (Control 和 Infrastructure 节点)、应用程序节点、由红帽站点可靠性工程师(SRE)、高级红帽支持以及集群服务,如日志记录、指标、监控、通知门户和集群门户等。

OpenShift Dedicated 为 Kubernetes 提供企业级改进,包括以下改进:

  • OpenShift Dedicated 集群部署在 AWS 或 GCP 环境中部署,并可作为应用程序管理的混合方法的一部分使用。
  • 集成了红帽技术。OpenShift Dedicated 中的主要组件源自 Red Hat Enterprise Linux 和相关的红帽技术。OpenShift Dedicated 得益于红帽企业级优质软件的严格测试和认证计划。
  • 开源开发模型。开发以开放方式完成,源代码可从公共软件存储库中获得。这种开放协作促进了快速创新和开发。

要了解在 OpenShift Container Platform 中构建和部署容器化 Kubernetes 应用程序时可以选择创建的资产,请参阅 OpenShift Container Platform 文档中的了解 OpenShift Container Platform 开发

1.1.1. 定制操作系统

OpenShift Dedicated 使用 Red Hat Enterprise Linux CoreOS(RHCOS),它是一个基于容器的操作系统,结合了 CoreOS 和 Red Hat Atomic Host 操作系统的一些最佳特性和功能。RHCOS 是专门为从 OpenShift Dedicated 运行容器化应用程序而设计的,并与新工具一起提供快速安装、基于 Operator 的管理以及简化的升级。

RHCOS 包括:

  • Ignition,OpenShift Dedicated 将用作首次启动系统配置来启动和配置机器。
  • CRI-O,Kubernetes 的原生容器运行时实现,可与操作系统紧密集成来提供高效和优化的 Kubernetes 体验。CRI-O,提供用于运行、停止和重启容器的工具。
  • Kubelet,Kubernetes 的主要节点代理,负责启动和监视容器。

1.1.2. 其他主要功能

Operator 既是 OpenShift Dedicated 代码库的基本单元,又是部署供应用程序使用的应用程序和软件组件的便捷方式。在 OpenShift Dedicated 中,Operator 充当平台基础,不再需要手动升级操作系统和 control plane 应用程序。OpenShift Dedicated Operator(如 Cluster Version Operator 和 Machine Config Operator)允许对这些关键组件进行简化的、集群范围的管理。

Operator Lifecycle Manager (OLM) 和 OperatorHub 提供了相应的工具,可用于存储 Operator 并将其分发给开发和部署应用程序的人员。

Red Hat Quay Container Registry 是一个 Quay.io 容器 registry,它为 OpenShift Dedicated 集群提供大多数容器镜像和 Operator。Quay.io 是 Red Hat Quay 的一个公共 registry 版本,可存储数百万镜像和标签。

OpenShift Dedicated 中的 Kubernetes 的其他增强功能包括软件定义的网络(SDN)、身份验证、日志聚合、监控和路由改进。OpenShift Dedicated 还提供全面的 Web 控制台和自定义 OpenShift CLI(oc)界面。

1.1.3. OpenShift Dedicated 的互联网和 Telemetry 访问

在 OpenShift Dedicated 中,您需要访问互联网来安装和升级集群。

通过 Telemetry 服务,信息从 OpenShift Dedicated 集群发送到红帽,以启用订阅管理自动化、监控集群健康状况、协助支持并改进客户体验。

Telemetry 服务自动运行,集群会注册到 Red Hat OpenShift Cluster Manager。在 OpenShift Dedicated 中,远程健康报告总是被启用,您无法选择禁用。Red Hat Site Reliability engineering(SRE)团队需要信息为您的 OpenShift Dedicated 集群提供有效支持。

其他资源

第 2 章 架构概念

了解 OpenShift Dedicated 架构中使用的 OpenShift 和基本容器概念。

2.1. 关于 Kubernetes

Kubernetes 是一个开源容器编配引擎,用于自动化容器化应用程序的部署、扩展和管理。Kubernetes 的一般概念比较简单:

  • 从一个或多个 worker 节点开始,以运行容器工作负载。
  • 从一个或多个控制节点管理这些工作负载的部署。
  • 将容器嵌套到名为 pod 的部署单元中。使用 pod 可以为容器提供额外的元数据,并可在单个部署实体中对多个容器进行分组。
  • 创建特殊种类的资产。例如,服务由一组 pod 和定义了访问方式的策略来表示。此策略可使容器连接到所需的服务,即便容器没有用于服务的特定 IP 地址。复制控制器(replication controller)是另一种特殊资产,用于指示一次需要运行多少个 pod 副本。您可以使用此功能来自动扩展应用程序,以适应其当前的需求。

如需了解更多有关 Kubernetes 的信息,请参阅 Kubernetes 文档

2.2. 容器化应用程序的好处

应用程序一旦预期安装到包含应用程序所有依赖项的操作系统上。但是,容器提供了一种标准方法,可将应用程序代码、配置和依赖项打包成单一单元,这些单元可作为计算服务器上的资源隔离进程运行。要在 OpenShift Dedicated 上运行应用程序,您必须首先通过创建存储在容器 registry 中的容器镜像来容器化应用程序。

2.2.1. 操作系统的好处

容器使用不含内核的小型专用 Linux 操作系统。文件系统、网络、cgroups、进程表和命名空间与主机 Linux 系统分开,但容器可以在必要时与主机无缝集成。容器以 Linux 为基础,因此可以利用快速创新的开源开发模型带来的所有优势。

因为每个容器都使用专用的操作系统,所以您能够在同一主机上部署需要冲突软件依赖项的不同应用程序。每个容器都带有各自的依赖软件,并且管理自己的接口,如网络和文件系统,因此应用程序无需争用这些资产。

2.2.2. 部署的好处

如果您在应用程序的主要版本之间进行滚动升级,则可以持续改进应用程序,既不会造成停机,又能仍然保持与当前版本的兼容性。

您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时,还部署应用程序的新版本。容器通过测试后,只要部署更多新容器并删除旧容器便可。 

由于应用程序的所有软件依赖项都在容器本身内解决,因此数据中心的每台主机上都能使用通用操作系统。您无需逐一为应用主机配置特定的操作系统。当数据中心需要更多容量时,您可以部署另一个通用主机系统。

2.3. 了解 OpenShift Dedicated 如何与 OpenShift Container Platform 有所不同

OpenShift Dedicated 使用与 OpenShift Container Platform 相同的代码库,但安装在为性能、可伸缩性和安全性方面进行优化的方法。OpenShift Dedicated 是一个完全管理的服务,因此默认为您设置在 OpenShift Container Platform 中手动设置的许多 OpenShift Dedicated 组件和设置。

查看 OpenShift Dedicated 和您自己的基础架构上 OpenShift Container Platform 标准安装之间的以下区别:

OpenShift Container PlatformOpenShift Dedicated

客户安装并配置 OpenShift Container Platform。

OpenShift Dedicated 通过用户友好的网页和标准化的方式安装,以针对性能、可伸缩性和安全性进行了优化。

客户可以选择他们的计算资源。

OpenShift Dedicated 托管在公共云(Amazon Web Services 或 Google Cloud Platform)中,由红帽所有或由客户提供。

客户对基础架构具有顶级管理访问权限。

客户具有内置管理员组,但当客户提供云帐户时,会提供顶级管理访问权限。

客户可以使用 OpenShift Container Platform 中的所有支持的功能和配置设置。

OpenShift Container Platform 的一些功能和配置设置可能不可用或可更改在 OpenShift Dedicated 中。

您在获取 control 角色的机器上设置 control plane 组件,如 API 服务器和 etcd。您可以修改 control plane 组件,但请记住您负责备份、恢复和使 control plane 数据具有高可用性。

红帽设置 control plane 并管理 control plane 组件。control plane 高度可用。

您需要更新 control plane 和 worker 节点的底层基础架构。您可以使用 OpenShift Web 控制台更新 OpenShift Container Platform 版本。

当有更新可用时,红帽会自动通知客户。您可以在 Red Hat OpenShift Cluster Manager 中手动或自动调度升级。

支持取决于您的红帽订阅或云供应商条款。

红帽在设计、操作和支持时具有 99.95% 的正常运行时间 SLA 和 24x7 覆盖范围。

第 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 加密。

3.2. 责任分配列表

了解红帽、云供应商和 OpenShift Dedicated 管理服务的客户职责。

3.2.1. OpenShift Dedicated 的职责概述

虽然红帽管理 OpenShift Dedicated 服务,但客户会负责某些方面。OpenShift Dedicated 服务被远程访问,它托管在公共云资源上,在红帽或客户拥有的云服务提供商帐户中创建的,具有由红帽拥有的底层平台和数据安全性。

重要

如果集群中启用了 cluster-admin 角色,请参阅 Red Hat Enterprise Agreement 附录 4(Online Subscription Services) 中的责任和排除注释。

资源事件和操作管理更改管理身份和访问管理安全性和监管合规性灾难恢复

客户数据

customer

customer

customer

customer

customer

客户应用程序

customer

customer

customer

customer

customer

开发人员服务

customer

customer

customer

customer

customer

平台监控

Red Hat

Red Hat

Red Hat

Red Hat

Red Hat

日志记录

Red Hat

共享

共享

共享

Red Hat

应用程序网络

共享

共享

共享

Red Hat

Red Hat

集群网络

Red Hat

共享

共享

Red Hat

Red Hat

虚拟网络

共享

共享

共享

共享

共享

control plane 和基础架构节点

Red Hat

Red Hat

Red Hat

Red Hat

Red Hat

Worker 节点

Red Hat

Red Hat

Red Hat

Red Hat

Red Hat

集群版本

Red Hat

共享

Red Hat

Red Hat

Red Hat

容量管理

Red Hat

共享

Red Hat

Red Hat

Red Hat

虚拟存储

红帽和云供应商

红帽和云供应商

红帽和云供应商

红帽和云供应商

红帽和云供应商

物理基础架构和安全性

云供应商

云供应商

云供应商

云供应商

云供应商

3.2.2. 共享责任列表

客户和红帽负责 OpenShift Dedicated 集群的监控和维护。本文档演示了根据领域和任务划分的职责。

3.2.2.1. 事件和操作管理

客户负责客户应用程序数据的事件和操作管理,以及客户可能针对集群网络或虚拟网络配置的任何自定义网络。

资源红帽职责客户职责

应用程序网络

监控云负载平衡器和原生 OpenShift 路由器服务,并响应警报。

  • 监控服务负载均衡器端点的健康状态
  • 监控应用程序路由的健康状况,以及它们后面的端点。
  • 报告对红帽的中断。

虚拟网络

监控默认平台网络所需的云负载均衡器、子网和公共云组件,并响应警报。

监控通过 VPC 配置至 VPC 连接、VPN 连接或直接连接的网络流量,以了解潜在的问题或安全威胁。

3.2.2.2. 更改管理

红帽负责启用对客户要控制的集群基础架构和服务的更改,以及维护 control plane 节点、基础架构节点和服务的版本,以及 worker 节点。客户负责启动基础架构,更改请求并维护集群上可选服务和网络配置,以及客户数据和客户应用程序的所有更改。

资源红帽职责客户职责

日志记录

  • 集中聚合和监控平台审计日志。
  • 提供和维护日志记录操作器,以便客户为默认应用程序日志记录部署日志记录堆栈。
  • 根据客户要求提供审计日志。
  • 在集群上安装可选的默认应用程序日志记录 Operator。
  • 安装、配置和维护任何可选的应用程序日志记录解决方案,如日志记录 sidecar 容器或第三方日志记录应用程序。
  • 调整客户应用程序生成的应用程序日志的大小和频率(如果它们影响日志记录堆栈或集群的稳定性)。
  • 通过支持问题单请求平台审计日志,以收集特定事件。

应用程序网络

  • 设置公共云负载均衡器。在需要时,提供设置私有负载均衡器以及一个额外的负载均衡器的功能。
  • 设置原生 OpenShift 路由器服务。提供将路由器设置为私有的功能,并最多添加到一个额外的路由器分片。
  • 为默认的内部 pod 流量安装、配置和维护 OpenShift SDN 组件。
  • 为客户提供管理 NetworkPolicyEgressNetworkPolicy (防火墙)对象的能力。
  • 使用 NetworkPolicy 对象为项目和 pod 网络、pod 入口和 pod 出口配置非默认 pod 网络权限。
  • 使用 Red Hat OpenShift Cluster Manager 为默认应用程序路由请求私有负载均衡器。
  • 使用 OpenShift Cluster Manager 配置为最多配置一个额外的公共或私有路由器分片,以及对应的负载均衡器。
  • 为特定服务请求并配置任何其他服务负载均衡器。
  • 配置任何必要 DNS 转发规则。

集群网络

  • 设置集群管理组件,如公共或私有服务端点,以及与虚拟网络组件进行必要的集成。
  • 设置 worker、基础架构和 control plane 节点之间的内部集群通信所需的内部网络组件。
  • 如果集群置备时,通过 OpenShift Cluster Manager 的要求,为机器 CIDR、服务 CIDR 和 pod CIDR 提供可选的非默认 IP 地址范围。
  • 请求在集群创建时或通过 OpenShift Cluster Manager 创建后公开或私有 API 服务端点。

虚拟网络

  • 设置并配置置备集群所需的虚拟网络组件,包括虚拟私有云、子网、负载均衡器、互联网网关、NAT 网关等。
  • 为客户提供管理与内部资源( VPC 到 VPC)的 VPN 连接的功能,以及 OpenShift Cluster Manager 所需的直接连接。
  • 使客户能够创建和部署公共云负载均衡器,以用于服务负载均衡器。
  • 设置和维护可选的公共云网络组件,如 VPC 到 VPC 连接、VPN 连接或直接连接。
  • 为特定服务请求并配置任何其他服务负载均衡器。

集群版本

  • 启用升级调度过程。
  • 监控升级进度并更正遇到的问题。
  • 发布针对次要和维护升级的更改日志和发行注记。
  • 可立即计划维护版本升级、未来升级或进行自动升级。
  • 确认并计划次要版本升级。
  • 确保集群版本保持在受支持的次版本中。
  • 在次版本和维护版本中测试客户应用程序以确保兼容性。

容量管理

  • 监控 control plane(control plane 节点和基础架构节点)的使用情况。
  • 缩放或重新定义 control plane 节点大小,以保持服务质量。
  • 监控客户资源的利用率,包括网络、存储和计算容量。如果没有启用自动扩展功能,则客户会处理集群资源所需的任何更改(例如,新的计算节点以扩展、额外的存储等)。
  • 根据需要,使用提供的 OpenShift Cluster Manager 控制添加或删除额外的 worker 节点。
  • 响应有关集群资源要求的红帽通知。

3.2.2.3. 身份和访问管理

Identity and Access Management 列表包括管理授权访问集群、应用程序和基础架构资源的职责。这包括提供访问控制机制、身份验证、授权和管理对资源的访问等任务。

资源红帽职责客户职责

日志记录

  • 遵循行业标准的内部访问流程,以进行平台审计日志。
  • 提供原生的 OpenShift RBAC 功能。
  • 配置 OpenShift RBAC 以控制项目的访问,并通过扩展项目的应用日志来控制对项目的访问。
  • 对于第三方或自定义应用程序日志解决方案,客户负责访问管理。

应用程序网络

提供原生的 OpenShift RBAC 和 dedicated-admin 功能。

  • 配置 OpenShift dedicated-admins 和 RBAC,以根据需要控制对路由配置的访问。
  • 管理组织组织组织管理员以授予 OpenShift Cluster Manager 访问权限。OpenShift Cluster Manager 用于配置路由器选项并提供服务负载均衡器配额。

集群网络

  • 通过 OpenShift Cluster Manager 提供客户访问控制。
  • 提供原生的 OpenShift RBAC 和 dedicated-admin 功能。
  • 管理红帽帐户的组织成员资格。
  • 管理组织组织组织管理员以授予 OpenShift Cluster Manager 访问权限。
  • 配置 OpenShift dedicated-admins 和 RBAC,以根据需要控制对路由配置的访问。

虚拟网络

通过 OpenShift Cluster Manager 提供客户访问控制。

通过 OpenShift Cluster Manager 管理到公共云组件的可选用户访问。

3.2.2.4. 安全性和监管合规性

以下是与合规性相关的职责和控制:

资源红帽职责客户职责

日志记录

将集群审计日志发送到红帽 SIEM 以分析安全事件。在定义的时间段内保留审计日志,以支持敏感分析。

分析安全事件的应用日志。如果默认日志记录堆栈需要更长的保留,请通过日志记录 sidecar 容器或第三方日志记录应用程序向外部端点发送日志。

虚拟网络

  • 监控虚拟网络组件,以了解潜在的问题和安全威胁。
  • 利用其他公共云提供商工具进行额外的监控和保护。
  • 监控可选配置的虚拟网络组件的潜在问题和安全威胁。
  • 根据需要配置任何必要防火墙规则或数据中心保护。

3.2.2.5. 灾难恢复

灾难恢复包括数据和配置备份,复制数据和配置到灾难恢复环境,以及对灾难事件进行故障转移。

资源红帽职责客户职责

虚拟网络

恢复或重新创建平台正常工作所需的受影响的虚拟网络组件。

  • 使用多个隧道配置虚拟网络连接,以防因为公共云提供商建议防止停机。
  • 如果使用带有多个集群的全局负载均衡器,则维护故障转移 DNS 和负载均衡。

3.2.3. 客户对数据和应用程序的职责

客户负责部署到 OpenShift Dedicated 的应用程序、工作负载和数据。但是,红帽提供了各种工具来帮助客户在平台上管理数据和应用程序。

资源红帽职责客户职责

客户数据

  • 维护数据加密的平台级标准。
  • 提供 OpenShift 组件以帮助管理应用数据,如机密。
  • 启用与第三方数据服务(如 AWS RDS 或 Google Cloud SQL)集成,以存储和管理集群和/或云供应商以外的数据。

维持在平台上存储的所有客户数据的责任,以及客户应用程序如何消耗和公开这些数据。

客户应用程序

  • 使用安装的 OpenShift 组件置备集群,以便客户可以访问 OpenShift 和 Kubernetes API 来部署和管理容器化应用。
  • 使用镜像 pull secret 创建集群,以便客户部署可以从 Red Hat Container Catalog registry 中拉取镜像。
  • 提供对 OpenShift API 的访问,供客户用来设置 Operator,以将社区、第三方和红帽服务添加到集群中。
  • 提供存储类和插件以支持持久性卷以用于客户应用程序。
  • 提供容器镜像 registry,以便客户可以在集群上安全地存储应用程序容器镜像,以部署和管理应用程序。
  • 维持对客户和第三方应用程序、数据及其完整生命周期的职责。
  • 如果客户通过使用 Operator 或外部镜像向集群添加红帽、社区、第三方、第三方或其他服务,则客户负责处理这些服务并处理适当的供应商(包括红帽)来排除任何问题。
  • 使用提供的工具和功能来配置和部署;保持最新状态;设置资源请求和限值;调整集群具有足够的资源来运行应用;设置权限;与其他服务集成;管理客户部署的任何镜像流或模板;在外部提供服务;保存、备份和恢复数据;否则,管理其具有高可用性和弹性的工作负载。
  • 维护对 OpenShift Dedicated 运行应用程序的责任,包括安装和操作软件来收集指标并创建警报。

3.3. 了解 OpenShift Dedicated 的流程和安全性

3.3.1. 事件和操作管理

本文档详细介绍了 OpenShift Dedicated 管理服务的红帽责任。

3.3.1.1. 平台监控

红帽网站可靠性工程师(SRE)保留所有 OpenShift Dedicated 集群组件、SRE 服务和底层云供应商帐户的集中监控和警报系统。平台审计日志安全转发到集中式 SIEM(安全信息和事件监控)系统,在这里它们可能会触发配置的警报到 SRE 团队,并可能手动审阅。审计日志在 SIEM 中保留一年。在集群被删除时,给定集群的审计日志不会被删除。

3.3.1.2. 事件管理

事件是一种事件,导致一个或多个红帽服务出现性能下降或中断。客户或客户体验与参与(CEE)成员可通过问题单、直接由集中监控和警报系统或直接由 SRE 团队的成员引发事件。

根据服务和客户的影响,事件按照 严重性 分类。

由红帽管理新事件的一般工作流:

  1. SRE 首先向新事件发出警报,并开始调查初始调查。
  2. 在进行初始调查后,会为该事件分配事件,负责协调恢复工作。
  3. 事件领导管理所有与恢复相关的沟通和协调,包括任何相关的通知或支持问题单更新。
  4. 这个事件已被恢复。
  5. 其事件被记录,一个根本原因分析是在事件 5 个工作日内执行的。
  6. 根本原因分析(RCA)草案文件在事件的 7 个工作日内与客户共享。

3.3.1.3. 通知

平台通知配置使用电子邮件。任何客户通知都将发送到相应的红帽帐户团队,如果适用,红帽大客户经理。

以下活动可触发通知:

  • 平台事件
  • 性能下降
  • 集群容量警告
  • 关键漏洞和解决方案
  • 升级调度

3.3.1.4. 备份和恢复

所有 OpenShift Dedicated 集群都使用云供应商快照备份。值得注意的是,这不包括存储在持久性卷上的客户数据。所有快照都使用适当的云供应商快照 API 进行,并上传到与集群相同的帐户中的安全对象存储存储桶(AWS 中的 S3 和 Google Cloud 中的 GCS)。

组件快照频率保留备注

完整对象存储备份,所有集群持久性卷(PV)

daily

7 天

这是所有 Kubernetes 对象(如 etcd)以及集群中的所有 PV 的完整备份。

每周

30 天

完整对象存储备份

hourly

24 小时

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

节点根卷

Never

N/A

节点被视为短期。没有任何关键信息都不应存储在节点的 root 卷中。

  • 红帽不会提交至任何恢复点目标(RPO)或恢复时间目标(RTO)。
  • 客户负责定期备份其数据
  • 客户应该使用遵循 Kubernetes 最佳实践的工作负载部署多AZ 集群,以确保区域内的高可用性。
  • 如果整个云区域不可用,客户必须在不同的地区中安装新的集群,并使用其备份数据恢复其应用程序。

3.3.1.5. 集群容量

评估和管理集群容量是红帽和客户之间的责任。Red Hat SRE 负责集群中所有 control plane 和基础架构节点的容量。

红帽 SRE 还在升级过程中评估集群容量,并响应集群警报。集群升级对容量的影响被评估为升级测试过程的一部分,以确保对集群新增加的增加不会产生负面影响。在集群升级过程中,增加了额外的 worker 节点,以确保在升级过程中维护集群的总容量。

SRE 人员进行容量评估还会响应来自集群的警报,在一定时间段内超过一次使用阈值。这样的警报也可以向客户发出通知。

3.3.2. 更改管理

本节介绍了如何管理集群和配置更改、补丁和发行的策略。

3.3.2.1. 客户发起的更改

您可以使用自助功能(如集群部署、worker 节点扩展或集群删除)启动更改。

OpenShift Cluster Manager Overview 选项卡中的 Cluster History 部分中捕获了更改历史记录,可供您查看。更改历史记录包括但不仅限于以下更改:

  • 添加或删除身份提供程序
  • dedicated-admins 组添加或删除用户
  • 扩展集群计算节点
  • 扩展集群负载均衡器
  • 扩展集群持久性存储
  • 升级集群

您可以通过避免以下组件的 OpenShift Cluster Manager 中的更改来实施维护线索:

  • 删除集群
  • 添加、修改或删除身份提供程序
  • 从提升的组中添加、修改或删除用户
  • 安装或删除附加组件
  • 修改集群网络配置
  • 添加、修改或删除机器池
  • 启用或禁用用户工作负载监控
  • 开始升级
重要

要执行维护排除,请确保已禁用机器池自动扩展或自动升级策略。在存在维护排除后,根据需要继续启用机器池自动扩展或自动升级策略。

3.3.2.2. 红帽发起的更改

红帽站点可靠性工程(SRE)使用 GitOps 工作流和完全自动化 CI/CD 管道管理 OpenShift Dedicated 的基础架构、代码和配置。此过程可确保红帽可以持续地推出服务改进功能,而无需对客户造成负面影响。

每个建议的更改都会在检查时立即产生一系列自动验证。然后,将更改部署到暂存环境,在其中进行自动集成测试。最后,更改会部署到生产环境中。每个步骤都是完全自动化的。

授权的 SRE 审查程序必须为每个步骤批准升级。审查器不能与提议更改的个人相同。所有更改和批准都可以作为 GitOps 工作流的一部分完整审核。

有些更改会逐步发布到生产环境,使用功能标志来控制对指定集群或客户的新功能的可用性。

3.3.2.3. 补丁管理

OpenShift Container Platform 软件和底层不可变的 Red Hat Enterprise Linux CoreOS(RHCOS)操作系统镜像会根据常规 z-stream 升级的错误和漏洞进行补丁。在 OpenShift Container Platform 文档中了解更多有关 RHCOS 架构 的信息。

3.3.2.4. 发行版本管理

红帽不会自动升级集群。您可以计划定期升级集群(周期性升级)或使用 OpenShift Cluster Manager Web 控制台进行一次(非逐步升级)。只有在集群受严重影响 CVE 影响时,红帽才可以强制将集群升级到新的 z-stream 版本。您可以在 OpenShift Cluster Manager Web 控制台中查看所有集群升级事件的历史记录。有关发行版本的更多信息,请参阅 生命周期策略

3.3.3. 身份和访问管理

红帽站点可靠性工程(SRE)团队大多数访问是通过进行自动化配置管理的集群 Operator 完成。

3.3.3.1. 子处理器

有关可用子处理器列表,请查看红帽客户门户网站中的红帽子处理器 列表。

3.3.3.2. SRE 访问所有 OpenShift Dedicated 集群

SRE 通过代理访问 OpenShift Dedicated 集群。代理会在 OpenShift Dedicated 集群中为 SRE 登录时使用服务帐户进行。因为没有为 OpenShift Dedicated 集群配置身份提供程序,SREs 通过运行本地 Web 控制台容器来访问代理。SRE 不直接访问集群 Web 控制台。SRE 必须作为个人用户进行身份验证,以确保可审计性。所有验证尝试都会记录到安全信息和事件管理(SIEM)系统。

3.3.3.3. OpenShift Dedicated 中的特权访问控制

Red Hat SRE 遵循访问 OpenShift Dedicated 和公共云供应商组件时最低特权的原则。手动 SRE 访问也有四种基本类别:

  • SRE 管理通过红帽客户门户访问,具有正常双因素的身份验证,无特权性问题。
  • SRE admin 通过带有常规双因素身份验证的 Red Hat Enterprise SSO 进行访问,且不具有特权特权。
  • OpenShift elevation 是使用红帽 SSO 进行的手动评估。它被完全审核,并且每个操作 SRE 均需要管理批准。
  • 云供应商访问或提升,这是云供应商控制台或 CLI 访问的手册。访问仅限于 60 分钟,并被完全审计。

每个访问类型都有不同级别的组件访问:

组件典型的 SRE 管理员访问权限(红帽客户门户网站)典型的 SRE 管理员访问权限(Red Hat SSO)OpenShift elevation云供应商访问权限

OpenShift Cluster Manager

R/W

无权限

无权限

无权限

OpenShift Web 控制台

无权限

R/W

R/W

无权限

节点操作系统

无权限

包含升级的操作系统和网络权限的特定列表。

包含升级的操作系统和网络权限的特定列表。

无权限

AWS 控制台

无权限

没有访问权限,但这是用于请求云提供商访问的帐户。

无权限

使用 SRE 身份的所有云供应商权限。

3.3.3.4. SRE 访问云基础架构帐户

红帽员工无法访问常规 OpenShift Dedicated 操作的云基础架构帐户。为了进行紧急故障排除,红帽 SRE 具有精心定义的、可审计的流程来访问云基础架构帐户。

在 AWS 中,SREs 使用 AWS Security Token Service(STS)为 BYOCAdminAccess 用户生成简短的 AWS 访问令牌。对 STS 令牌的访问会被审计日志记录,可追溯回各个用户。BYOCAdminAccess 附加了 AdministratorAccess IAM 策略。

在 Google Cloud 中,SREs 在针对 Red Hat SAML 身份提供程序(IDP)进行身份验证后访问资源。IDP 授权有时间过期的令牌。令牌的影响可以由公司 Red Hat IT 审核,并重新链接到单独的用户。

3.3.3.5. 红帽支持访问

Red Hat CEE 团队的成员通常具有对集群的部分的只读访问。具体来说,CEE 对核心和产品命名空间具有有限的访问权限,而且无法访问客户命名空间。

角色核心命名空间层次的产品命名空间客户命名空间云基础架构帐户*

OpenShift SRE

read: All

write: Very

有限 [1]

read: All

write: None

读取:无[2]

write: None

read: All [3]

写入: All [3]

CEE

read: All

write: None

read: All

write: None

读取:无[2]

write: None

read: None

write: None

客户管理员

read: None

write: None

read: None

write: None

read: All

write: All

read: Limited[4]

write: Limited[4]

客户用户

read: None

write: None

read: None

write: None

read: Limited[5]

write: Limited[5]

read: None

write: None

其余人

read: None

write: None

read: None

write: None

read: None

write: None

read: None

write: None

Cloud Infrastructure Account 引用底层 AWS 或 Google Cloud 帐户

  1. 仅限于解决常见用例,如部署故障、升级集群并替换错误的 worker 节点。
  2. 默认情况下,红帽员工无法访问客户数据。
  3. SRE 对云基础架构帐户的访问是一项"break-glas"流程,用于在记录的事件期间进行特殊故障排除。
  4. 客户管理员通过 Cloud Infrastructure Access 限制对云基础架构帐户控制台的访问。
  5. 受客户管理员以及用户创建的命名空间的限制。

3.3.3.6. 用户访问

客户访问权限仅限于由客户管理员角色授予的客户和权限创建的命名空间。在没有 cluster-admin 访问的情况下,通常不允许访问底层基础架构或产品命名空间。有关客户访问权限和身份验证的更多信息,请参阅文档的"了解身份验证"部分。

3.3.3.7. 访问批准并查看

新的 SRE 用户访问需要管理批准。SRE 帐户作为授权用户通过自动过程删除。另外,SRE 执行定期访问审核,包括授权用户列表的管理符号。

3.3.4. 安全性和监管合规性

安全与监管合规性包括任务,如安全控制和合规性认证。

3.3.4.1. 数据分类

红帽定义并遵循数据分类标准,以确定数据敏感性和完整性的固有风险,同时收集、使用、传输和处理。客户拥有的数据按照最高程度的敏感性和处理要求分类。

3.3.4.2. 数据管理

OpenShift Dedicated 使用云供应商服务,如 AWS Key Management Service(KMS)和 Google Cloud KMS,以帮助安全地管理持久性数据的加密密钥。这些密钥用于加密所有 control plane、基础架构和 worker 节点根卷。用户可以在安装时指定自己的 KMS 密钥来加密 root 卷。持久性卷(PV)也使用 KMS 进行密钥管理。通过引用 KMS 密钥 Amazon 资源名称(ARN)或 ID 的新 StorageClass,用户可以指定自己的 KMS 密钥来加密 PV。

当客户删除其 OpenShift Dedicated 集群时,所有集群数据都会永久删除,包括 control plane 数据卷和客户应用程序数据卷,如持久性卷(PV)。

3.3.4.3. 漏洞管理

红帽使用行业标准工具对 OpenShift Dedicated 执行定期漏洞扫描。根据严重性而定,将跟踪已识别的漏洞。漏洞扫描和修复活动已记录,供第三方评估机构在合规认证审计中进行验证。

3.3.4.4. 网络安全

3.3.4.4.1. 防火墙和 DDoS 保护

每个 OpenShift Dedicated 集群都使用防火墙规则(AWS 安全组或 Google Cloud Compute Engine 防火墙规则)在云基础架构级别的安全网络配置进行保护。AWS 上的 OpenShift Dedicated 还可防止 AWS Shield Standard 的 DDoS 攻击。

3.3.4.4.2. 私有集群和网络连接

客户可以选择配置其 OpenShift Dedicated 集群端点(Web 控制台、API 和应用程序路由器),以便无法从互联网访问集群 control plane 或应用程序。

对于 AWS,用户可通过 AWS VPC 对等、AWS VPN 或 AWS Direct Connect 配置到其 OpenShift Dedicated 集群的私有网络连接。

注意

目前,在 Google Cloud 上的 OpenShift Dedicated 集群不支持私有集群。

3.3.4.4.3. 集群网络访问控制

使用 NetworkPolicy 对象和 OpenShift SDN,可以为每个项目配置精细网络访问控制规则。

3.3.4.5. 渗透测试

红帽针对 OpenShift Dedicated 执行定期渗透测试。测试由独立内部团队使用行业标准工具和最佳实践来执行。

发现的所有问题都会根据严重性进行优先级排序。属于开源项目的任何问题与社区共享,供社区解决。

3.3.4.6. 合规性

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

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

认证AWS 上的 OpenShift DedicatedGCP 上的 OpenShift Dedicated

ISO 27001

PCI DSS

SOC 2 类型 2

其他资源

3.3.5. 灾难恢复

OpenShift Dedicated 为在 pod、worker 节点、基础架构节点、control plane 节点和可用区级别的故障提供灾难恢复功能。

所有灾难恢复要求客户使用最佳实践来部署高可用性应用程序、存储和集群架构(例如,单区部署与多区部署)考虑所需的可用性级别。

当一个可用区或区域中断时,一个区集群不会提供灾难性或恢复。具有客户维护功能的多个单区集群可以考虑在区域或区域级别停机。

如果一个多区集群在全区域中断时不会提供灾难性或恢复。多个具有客户维护的故障转移的多区集群可以考虑在区域级别停机。

3.4. 了解 OpenShift Dedicated 的可用性

可用性和灾难性是任何应用平台的重要方面。OpenShift Dedicated 在多个级别提供了很多对故障的保护,但必须适当地配置客户部署的应用程序才能实现高可用性。另外,为了考虑到可能发生的云供应商中断,还有其它选项可用,例如在多个可用区间部署集群,或维护带有故障转移机制的多个集群。

3.4.1. 潜在的故障点

OpenShift Container Platform 提供了很多功能和选项来保护您的工作负载停机,但必须适当地设计应用程序才能利用这些功能。

OpenShift Dedicated 可通过添加红帽站点可靠性工程师(SRE)支持和选项来部署多区集群来进一步防止您排除许多常见的 Kubernetes 问题,但有多种方法仍可失败。通过了解潜在的故障点,您可以理解风险并适当地将应用程序和集群架构成每个特定级别的弹性。

注意

在多个不同级别的基础架构和集群组件中可能会发生中断。

3.4.1.1. 容器或 pod 失败

按照设计,pod 会在短时间内存在。正确扩展服务,以便应用 pod 的多个实例会运行,以防止出现任何单个 pod 或容器的问题。节点调度程序还可确保这些工作负载分布到不同的 worker 节点上,以进一步提高弹性。

在考虑可能的 pod 失败时,务必要了解如何在您的应用程序中附加存储。附加到单个 pod 的单个持久性卷无法利用 Pod 扩展的完整优势,而复制的数据库、数据库服务或共享存储可以:

为了避免在计划维护期间中断应用程序,比如升级,需要定义 pod 中断预算。这些是 Kubernetes API 的一部分,可以像其他对象类型一样通过 OpenShift CLI(oc)进行管理。它们允许在操作过程中指定 pod 的安全约束,比如为维护而清空节点。

3.4.1.2. Worker 节点失败

Worker 节点是包含应用程序 pod 的虚拟机。默认情况下,OpenShift Dedicated 集群至少有四个 worker 节点,用于单个 availability-zone 集群。如果 worker 节点出现故障,pod 会被重新定位到可正常工作的 worker 节点(只要有足够的容量),直到现有节点出现任何问题,或节点已被替换。更多 worker 节点意味着防止单一节点中断,并在节点失败时为重新调度 pod 保障适当的集群容量。

注意

在考虑可能的节点故障时,务必要了解存储受到影响。

3.4.1.3. 集群故障

OpenShift Dedicated 集群至少有三个 control plane 节点,以及三个已预配置高可用性的基础架构节点,可在单个区中,或多个区(根据您选择的集群类型)。这意味着,control plane 和基础架构节点具有相同的 worker 节点的弹性,增加了红帽的完全管理的好处。

如果完整的 control plane 节点中断,OpenShift API 将无法工作,现有的 worker 节点 pod 不受影响。但是,如果同时存在 pod 或节点中断,则 control plane 节点必须在添加新 pod 或节点前进行恢复。

红帽将运行在基础架构节点上运行的所有服务都配置为具有高可用性,并在基础架构节点之间分布。如果完全中断基础架构,在这些节点恢复之前,这些服务将不可用。

3.4.1.4. 区域失败

来自公共云供应商的区故障会影响所有虚拟组件,如 worker 节点、块或共享存储等,以及特定于单个可用区的负载均衡器。为了防止区失败,OpenShift Dedicated 提供了在三个可用区间分布的集群的选项,称为多可用区集群。只要有足够的容量,现有无状态工作负载会被重新分发到未受到影响的区域。

3.4.1.5. 存储故障

如果您部署了有状态应用程序,则存储是一个关键组件,在考虑高可用性时必须考虑它。单个块存储 PV 无法处于停机状态,即使在 pod 级别上也是如此。维护存储可用性的最佳方法是使用复制存储解决方案、受中断影响的共享存储或独立于集群的数据库服务。

3.5. OpenShift Dedicated 更新生命周期

3.5.1. 概述

红帽为 OpenShift Dedicated 公布了它的产品生命周期,以便客户和合作伙伴有效规划、部署及支持其在平台上运行的应用程序。红帽发布这个生命周期的目的是尽可能提供透明性,并在出现冲突时对这些政策进行例外处理。

OpenShift Dedicated 是 Red Hat OpenShift 的受管实例,并维护一个独立版本计划。有关受管产品的更多详细信息,请参阅 OpenShift Dedicated 服务定义。特定版本的安全公告和程序错误修复公告的可用性取决于 Red Hat OpenShift Container Platform 生命周期政策,并遵循 OpenShift Dedicated 的维护阶段。

3.5.2. 定义

表 3.3. 版本参考

版本格式主要PatchMajor.minor.patch
 

x

y

z

x.y.z

示例

4

5

21

4.5.21

主发行版本或 X-releases

只使用 主版本或 X-releases (X.y.z)。

例子

  • "major release 5" → 5.y.z
  • "major release 4" → 4.y.z
  • "major release 3" → 3.y.z
次发行版本或 Y-releases

只使用 次发行版本或 Y-releases (x.Y.z)。

例子

  • "minor release 4" → 4.4.z
  • "minor release 5" → 4.5.z
  • "minor release 6" → 4.6.z
补丁版本或 Z-releases

只使用 补丁版本或 Z-releases (x.y.Z)。

例子

  • "patch release 14 of minor release 5" → 4.5.14
  • "patch release 25 of minor release 5" → 4.5.25
  • "patch release 26 of minor release 6" → 4.6.26

3.5.3. 主要版本(X.y.z)

OpenShift Dedicated 的主要版本(如版本 4)根据后续主版本或产品停用的一年支持。

示例

  • 如果在 OpenShift Dedicated 1 月 1 日发布版本 5,则可以在 12 个月后继续在受管集群中运行版本 4,直到 12 月 31 日为止。在此时间后,集群需要升级或迁移到第 5 版。

3.5.4. 次版本(x.Y.z)

从 4.8 OpenShift Container Platform 次版本开始,红帽会在指定次版本的正式发布后的 14 个月时间内支持所有次版本的次版本。补丁版本不受 14 个月的支持周期的影响。

在 14 个月结束前,客户会收到 60、30 和 15 天通知。集群必须在 14 个月结束前升级到受支持的次版本,否则集群将进入 "Limited Support" 状态。

示例

  1. 客户的集群目前在 4.8.14 上运行。4.8 次要版本在 2021 年 7 月 27 日正式发布。
  2. 在 2022 年 7 月 29 日,如果集群还没有升级到受支持的次版本,则客户会在 2022 年 9 月 27 日输入"自我支持"状态。
  3. 集群必须在 2022 年 9 月 27 日升级到 4.9 或更高版本。
  4. 如果没有执行升级,集群将被标记为 "Limited Support" 状态。

3.5.5. 补丁版本(x.y.Z)

在支持次版本的期间,红帽会支持所有 OpenShift Container Platform 补丁版本,除非另有指定。

出于平台安全性和稳定性的原因,一个补丁版本可能被弃用,这可以防止安装该版本,并触发该版本的强制升级。

示例

  1. 找到包含关键 CVE 的 4.7.6。
  2. 任何受 CVE 影响的版本都将从支持的补丁发行列表中删除。另外,任何运行 4.7.6 的集群都会被调度在 48 小时内自动升级。

3.5.6. 有限的支持状态

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

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

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

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

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

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

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

3.5.7. 支持的版本例外策略

红帽保留添加或删除新版本或现有版本的权利,或延迟即将推出的次版本,这些版本已被识别为具有一个或多个重要生产影响漏洞或安全问题的权利,而无需提前通知。

3.5.8. 安装策略

虽然红帽推荐安装最新的支持版本,但 OpenShift Dedicated 支持按照上述政策涵盖任何受支持的发行版本。

3.5.9. 强制升级

如果一个严重(Critical)或重要(Important)的 CVE 或其他错误,红帽会严重影响集群的安全或稳定性,客户必须在两个 工作日内 升级到下一个支持的补丁发行版本。

在极端情况下,如果升级到下一个支持的补丁版本没有在通知两个 工作日内 执行,集群将自动更新至最新的补丁发行版本,以缓解潜在的安全漏洞或不稳定。

3.5.10. 生命周期日期

版本公开发行(GA)生命周期结束

4.11

2022 年 8 月 10 日

2023 年 10 月 10 日

4.10

2022 年 3 月 10 日

2023 年 5 月 10 日

4.9

2021 年 10 月 18 日

2022 年 12 月 18 日

4.8

2021 年 7 月 27 日

2022 年 9 月 27 日

第 4 章 获取支持

获得 OpenShift Dedicated 的支持。

4.1. 获取支持

如果您在执行本文档所述的某个流程或 OpenShift Dedicated 时遇到问题,请访问红帽客户门户网站。通过红帽客户门户网站:

  • 搜索或者浏览红帽知识库,了解与红帽产品相关的文章和解决方案。
  • 提交问题单给红帽支持。
  • 访问其他产品文档。

要识别集群中的问题,您可以在 OpenShift Cluster Manager Hybrid Cloud Console 中使用 Insights。Insights 提供了问题的详细信息,并在有可用的情况下,提供了如何解决问题的信息。

如果您对本文档有任何改进建议,或发现了任何错误,请为相关文档组件提交 JIRA 问题。请提供具体信息,如章节名称和 OpenShift Dedicated 版本。

4.2. 关于红帽知识库

红帽知识库提供丰富的内容以帮助您最大程度地利用红帽的产品和技术。红帽知识库包括文章、产品文档和视频,概述了安装、配置和使用红帽产品的最佳实践。另外,您还可以搜索已知问题的解决方案,其提供简洁的根原因描述和补救措施。

4.3. 搜索红帽知识库

如果出现 OpenShift Dedicated 问题,可以执行初始搜索来确定红帽知识库中是否已存在解决方案。

先决条件

  • 您有红帽客户门户网站帐户。

流程

  1. 登录到 红帽客户门户网站
  2. 在主红帽客户门户网站搜索字段中,输入与问题相关的关键字和字符串,包括:

    • OpenShift Dedicated 组件(如 etcd
    • 相关步骤(比如 安装
    • 警告、错误消息和其他与输出与特定的问题相关
  3. Search
  4. 选择 OpenShift Dedicated 产品过滤器。
  5. 在内容类型过滤中选择 Knowledgebase

4.4. 提交支持问题单

先决条件

  • 您可以访问 Red Hat OpenShift Cluster Manager。
  • 您有红帽客户门户网站帐户。

流程

  1. 登录到 红帽客户门户网站 并选择 SUPPORT CASESOpen a case
  2. 为您的问题选择适当的类别(如 Defect / Bug)、产品(OpenShift Dedicated)和产品版本(如果还没有自动填充则为OpenShift Dedicated )。
  3. 查看推荐的红帽知识库解决方案列表,它们可能会与您要报告的问题相关。如果建议的文章没有解决这个问题,请点 Continue
  4. 输入一个简洁但描述性的问题概述,以及问题症状的详细信息,以及您预期的结果。
  5. 查看更新的推荐红帽知识库解决方案列表,它们可能会与您要报告的问题相关。这个列表的范围会缩小,因为您在创建问题单的过程中提供了更多信息。如果建议的文章没有解决这个问题,请点 Continue
  6. 请确保提供的帐户信息是正确的,如果需要,请相应调整。
  7. 检查自动填充的 OpenShift Dedicated 集群 ID 是否正确。如果不正确,请手动提供集群 ID。

    • 使用 OpenShift Cluster Manager 混合云控制台 手动获取集群 ID:

      1. 进入 Clusters
      2. 点击您需要打开支持问题单的集群名称。
      3. Overview 选项卡的 Details 部分的 Cluster ID 字段中查找值。
  8. 完成以下提示的问题,点 Continue:

    • 您在哪里遇到了这个问题?什么环境?
    • 这个行为在什么时候发生?发生频率?重复发生?是否只在特定时间发生?
    • 请提供这个问题对您的业务的影响及与时间相关的信息?
  9. 上传相关的诊断数据文件并点击 Continue
  10. 输入相关问题单管理详情,点 Continue
  11. 预览问题单详情,点 Submit

4.5. 其他资源