-
作为块设备提供给操作系统 (OS)
-
适用于需要完全控制存储并在文件系统上进行低级别文件操作的应用程序
-
也称为存储区域网络 (SAN)
-
不可共享,这意味着一次只有一个客户端可以挂载此类型的端点
优化存储有助于最大限度地减少所有资源的存储使用。通过优化存储,管理员可以帮助确保现有存储资源以高效的方式工作。
了解您的持久性存储选项,以便您可以优化您的 OpenShift Container Platform 环境。
存储类型 | 描述 | 示例 |
---|---|---|
块存储 |
|
AWS EBS 和 VMware vSphere 原生支持 OpenShift Container Platform 中的动态持久卷 (PV) 置备。 |
文件存储 |
|
RHEL NFS、NetApp NFS [1] 和供应商 NFS |
对象存储 |
|
AWS S3 |
使用 Trident 插件时,NetApp NFS 支持动态 PV 置备。
下表总结了给定 OpenShift Container Platform 集群应用程序的推荐和可配置存储技术。
存储类型 | 块存储 | 文件存储 | 对象存储 |
---|---|---|---|
ROX1 |
是4 |
是4 |
是 |
RWX2 |
否 |
是 |
是 |
注册表 |
可配置 |
可配置 |
推荐 |
扩展的注册表 |
不可配置 |
可配置 |
推荐 |
指标3 |
推荐 |
可配置5 |
不可配置 |
Elasticsearch 日志 |
推荐 |
可配置6 |
不支持6 |
Loki 日志 |
不可配置 |
不可配置 |
推荐 |
应用 |
推荐 |
推荐 |
不可配置7 |
1 2 3 Prometheus 是用于指标的底层技术。 4 这不适用于物理磁盘、虚拟机物理磁盘、VMDK、基于 NFS 的环回设备、AWS EBS 和 Azure 磁盘。 5 对于指标,使用具有 6 对于日志记录,请查看“为日志存储配置持久存储”部分中的推荐存储解决方案。使用 NFS 存储作为持久卷或通过 NAS(例如 Gluster)可能会损坏数据。因此,在 OpenShift Container Platform 日志记录中,不支持将 NFS 用于 Elasticsearch 存储和 LokiStack 日志存储。每个日志存储必须使用一种持久卷类型。 7 对象存储并非通过 OpenShift Container Platform 的 PV 或 PVC 使用。应用必须与对象存储 REST API 集成。 |
扩展的注册表是一个 OpenShift 镜像注册表,其中运行两个或多个 Pod 副本。 |
测试表明,使用 Red Hat Enterprise Linux (RHEL) 上的 NFS 服务器作为核心服务的存储后端存在问题。这包括 OpenShift Container Registry 和 Quay、用于监控存储的 Prometheus 以及用于日志存储的 Elasticsearch。因此,不建议使用 RHEL NFS 支持核心服务使用的 PV。 市场上的其他 NFS 实现可能不存在这些问题。请联系各个 NFS 实现供应商,以获取有关针对这些 OpenShift Container Platform 核心组件完成的任何测试的更多信息。 |
在非扩展/高可用性 (HA) OpenShift 镜像注册表集群部署中
存储技术不必支持 RWX 访问模式。
存储技术必须确保写入后一致性。
首选的存储技术是对象存储,其次是块存储。
不建议将文件存储用于具有生产工作负载的 OpenShift 镜像注册表集群部署。
在扩展/HA OpenShift 镜像注册表集群部署中
存储技术必须支持 RWX 访问模式。
存储技术必须确保写入后一致性。
首选的存储技术是对象存储。
支持 Red Hat OpenShift Data Foundation (ODF)、Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage (GCS)、Microsoft Azure Blob Storage 和 OpenStack Swift。
对象存储应符合 S3 或 Swift 规范。
对于非云平台(例如 vSphere 和裸机安装),唯一可配置的技术是文件存储。
块存储不可配置。
支持将网络文件系统 (NFS) 存储与 OpenShift Container Platform 一起使用。但是,将 NFS 存储与扩展的注册表一起使用可能会导致已知问题。有关更多信息,请参见 Red Hat 知识库解决方案,生产环境中是否支持用于 OpenShift 集群内部组件的 NFS?。
在 OpenShift Container Platform 托管的日志记录集群部署中
Loki 运算符
首选的存储技术是与 S3 兼容的对象存储。
块存储不可配置。
OpenShift Elasticsearch 运算符
首选的存储技术是块存储。
不支持对象存储。
从日志记录版本 5.4.3 开始,OpenShift Elasticsearch 运算符已弃用,并计划在将来的版本中删除。Red Hat 将在此版本的生命周期内为此功能提供错误修复和支持,但此功能将不再接收增强功能,并将被删除。作为使用 OpenShift Elasticsearch 运算符管理默认日志存储的替代方法,您可以使用 Loki 运算符。 |
下表总结了 OpenShift Container Platform 组件写入数据的主要目录。
目录 | 备注 | 大小 | 预期增长 |
---|---|---|---|
/var/lib/etcd |
在存储数据库时用于 etcd 存储。 |
小于 20 GB。 数据库最多可增长 8 GB。 |
将随环境缓慢增长。仅存储元数据。 每增加 8 GB 内存,额外增加 20-25 GB。 |
/var/lib/containers |
这是 CRI-O 运行时的挂载点。用于活动容器运行时(包括 Pod)和本地镜像存储的存储空间。不用于注册表存储。 |
对于具有 16 GB 内存的节点,为 50 GB。请注意,此大小不应用于确定最小集群要求。 每增加 8 GB 内存,额外增加 20-25 GB。 |
增长受运行容器的容量限制。 |
/var/lib/kubelet |
Pod 的临时卷存储。这包括在运行时挂载到容器中的任何外部内容。包括环境变量、kube 密钥和未由持久卷支持的数据卷。 |
变化 |
如果需要存储的 Pod 使用持久卷,则最小。如果使用临时存储,则此存储可能快速增长。 |
/var/log |
所有组件的日志文件。 |
10 到 30 GB。 |
日志文件可能会快速增长;可以通过增加磁盘大小或使用日志轮转来管理大小。 |
OpenShift 容器平台和 Kubernetes 对磁盘性能敏感,建议使用更快的存储,特别是控制平面节点上的 etcd。
对于生产 Azure 集群和具有密集工作负载的集群,控制平面机器的虚拟机操作系统磁盘应能够维持经测试的推荐最小吞吐量:5000 IOPS / 200MBps。这可以通过至少使用 1 TiB 的 Premium SSD (P30) 来实现。在 Azure 和 Azure Stack Hub 中,磁盘性能直接取决于 SSD 磁盘大小。为了达到 `Standard_D8s_v3` 虚拟机或其他类似机器类型支持的吞吐量,并达到 5000 IOPS 的目标,至少需要一个 P30 磁盘。
为了获得低延迟和高 IOPS 和吞吐量读取数据,主机缓存必须设置为 `ReadOnly`。从缓存(存在于 VM 内存或本地 SSD 磁盘中)读取数据比从位于 Blob 存储中的磁盘读取数据快得多。