Ceph:关于Ceph 中使用红帽 Ceph 存储管理云平台(19)

对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》

写在前面

---

+

• 理解不足小伙伴帮忙指正

对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》

---

13. 使用红帽 Ceph 存储管理云平台

13.1 OpenStack存储架构介绍

13.1.1 Red Hat OpenStack平台概述

RHOSP (Red Hat OpenStack Platform)是一个交互服务的集合，控制计算、存储和网络资源。云用户通过自助服务界面使用资源部署虚拟机。云运营商与存储运营商合作，确保为每个使用或向云用户提供存储的OpenStack组件创建、配置和可用的存储空间。

下图给出了一个简单RHOSP安装的核心服务关系的高级概述。所有服务都需要与Keystone (Identity service)进行交互，对用户、服务和权限进行认证后才能进行操作。云用户可以选择使用命令行界面或图形化的Dash查询服务来访问现有资源并创建和部署虚拟机。

Orchestration服务是安装和修改RHOSP云的主要组件。介绍将Ceph集成到OpenStack基础架构中的OpenStack服务

介绍存储服务

这些核心OpenStack服务提供多种格式、多种访问方式的存储资源。云用户部署应用虚拟机，使用这些存储资源

• Compute Service (Nova)

Compute服务管理运行在hypervisor节点上的虚拟机实例。它使用存储为启动和运行实例提供系统磁盘、交换卷和其他临时磁盘。此服务与Identity服务交互以进行身份验证，即图像

服务来获取映像，以及其他存储服务来访问其他形式的持久性存储以供运行实例使用。Compute服务对hypervisor使用libvirtd、qemu和kvm

• Block Storage Service (Cinder)

块存储服务为虚拟机管理存储卷，包括Compute服务管理的实例的临时块存储和持久块存储。该服务实现了用于备份和创建新的块存储卷的快照

• Image Service (Glance)

Image服务充当映像的注册表，这些映像在启动时构建实例系统磁盘。活动实例可以保存为映像，供以后使用以构建新实例

• Shared File Systems Service (Manila)

共享文件系统服务使用网络基础设施将文件共享作为服务实现。由于云用户通常没有到文件共享服务器的连接权限，因此该服务代理到配置的后端连接。该服务通过NFS和CIFS协议访问文件共享服务器。管理员可以通过配置该服务访问多个文件共享服务器

• Object Store Service (Swift)

对象存储(Object Store)为用户以文件的形式上传和检索对象提供存储空间。对象存储体系结构分布在磁盘设备和服务器之间，以实现水平扩展和提供冗余。通常情况下，配置镜像服务使用对象存储服务作为其存储后端，以支持镜像和快照跨对象存储基础设施的复制。该服务还为其他服务提供备份解决方案，将备份结果存储为可检索对象

• Red Hat Ceph Storage (Ceph)

Red Hat Ceph Storage是一个分布式数据对象存储，用作所有其他存储服务的后端。Ceph是与OpenStack一起使用的最常见的后端。Ceph集成了OpenStack的计算、块存储、共享文件系统、镜像和对象存储等服务，提供更便捷的存储管理和云扩展性

介绍存储集成服务

这些额外的核心服务提供了实现存储集成所需的overcloud安装、服务容器部署和身份验证支持

• Identity Service (Keystone)

Identity服务对所有OpenStack服务进行身份验证和授权。该服务在域和项目中创建和管理用户和角色。该服务提供在OpenStack云中可用的服务及其关联端点的中央目录。Identity服务充当用户和服务组件的单点登录(SSO)身份验证服务。

• Deployment Service (TripleO)

部署服务通过Director节点(即OpenStack云)安装、升级和操作OpenStack云

• Orchestration Service (Heat)

通过使用Heat编制模板(HOT)文件中定义的资源，编制服务可以提供基础设施和应用程序工作负载。HOT模板和环境文件是部署overclouds的主要配置方法。在redhat OpenStack平台的后续版本中，编排模板和环境文件定义了要部署的服务、资源和体系结构，而Ansible playbook实现了软件供应。

• Container Deployment Service (Kolla)

在以后的RHOSP版本中，OpenStack服务是被容器化的。Container Deployment服务为OpenStack服务的运行提供生产状态的容器和配置管理

• Bare Metal Service (Ironic)

裸金属发放服务准备和发放物理硬件和KVM虚拟机。该服务与标准和特定于供应商的驱动程序(如PXE和IPMI)一起工作，以与各种硬件通信。

13.1.2 选择Ceph集成体系结构

与基础架构师和网络工程师密切合作的存储操作员，选择支持组织的应用程序用例和规模预测所需的Ceph集成体系结构和服务器节点角色。Ceph可以通过使用两种实现设计中的任意一种集成到OpenStack基础设施中。两个Ceph设计都是由Triple0实现的，它使用Ansible playbook进行大量的软件部署和配置

RHOSP 16.1和16.2只支持RHCS 5作为外部集群。RHOSP 17支持与cephadm一起部署专门的RHCS 5，以取代ceph-ansible

• Dedicated

没有现有的独立Ceph集群的组织在RHOSP超云安装过程中安装专门的Ceph集群，该集群由Ceph服务和存储节点组成。只有部署在OpenStack云上的服务和工作负载可以使用专用于openstack的Ceph实现。外部应用程序不能访问或使用openstack专用的Ceph集群存储

• External

组织在创建新的OpenStack overcloud时，可以使用现有的独立Ceph集群作为存储。Triple0部署被配置为访问该外部集群在overcloud安装期间创建必要的池、帐户和其他资源。该部署不会创建内部Ceph服务，而是配置OpenStack overcloud作为Ceph客户端访问现有的Ceph集群

一个专用的Ceph集群在RHOSP控制器上运行Ceph控制平面服务时，最多支持750个osd。根据硬件配置的不同，外部Ceph集群可以显著扩大规模。在外部集群上更新和一般维护更容易，因为它们可以独立于RHOSP操作发生。

要维护Red Hat支持，必须用TripleO业务流程服务构建和配置RHOSP安装。对于专用的存储配置，RHOSP 16 TripleO使用相同的RHCS 4 ceph -ansible剧本，这些剧本用于安装独立的ceph集群。但是，由于TripleO动态地组织剧本和环境文件以包括在部署中，所以不支持直接使用Ansible而不支持TripleO

专门的节点实现Ceph角色

一个专用的Ceph实现是Tripleo的默认实现，对于大多数小型、中型和中等规模的OpenStack安装已经足够了。通过使用可组合的节点角色，存储运营商在跨跨云节点的服务分布方面有很多选择。除非另有说明，否则在以后的RHOSP版本中默认包含这些节点角色。下图展示了一个overcloud节点示例，在一个简单的overcloud中实现不同的服务角色

以下节点角色决定了在处理数据平面流量的存储节点和物理存储设备上的服务。默认为cepstorage角色，且控制节点需要安装控制平面业务。

cepstorage—最常见的专用Ceph存储节点配置。只包含osd，不包含控制平面服务。

CephAII—独立的全存储节点，包含osd和所有控制平面业务。此配置可以与ControllerNoCeph节点角色一起使用

cepfile—扩展文件共享的节点。包含osd和MDS服务。

CephObject -扩展对象网关访问的节点。包含osd和RGW服务

当存储管理流量增加时，会导致控制节点过载。以下节点角色支持跨多个节点的Ceph控制平面服务的各种配置和分布。协调控制节点角色与存储节点角色选择，确保需要部署的控制平面业务全部部署。控制器—最常见的控制器节点配置。包含所有正常的控制平面服务，包括Ceph MGR、MDS、MON、RBD、RGW服务。ControllerStorageDashboard——一个正常的控制器节点加上一个Grafana仪表板服务。该节点角色添加了一个进一步的网络，将存储监控流量与存储后端隔离开来。

ControllerStorageNFS—一个正常的控制节点加上一个gananesa服务作为cepfs到NFS的网关。

ControllerNoCeph—一个正常的控制器，但没有Ceph控制平面服务。当Ceph控制平面服务移动到独立节点以提高性能和可伸缩性时，将选择此节点角色。

下列节点角色默认情况下不包括在RHOSP发行版中，但在Red Hat在线文档中有描述。通过将主要Ceph服务移动到独立的、专用的节点，使用这些角色来减轻控制节点的过载。这些角色通常出现在存储流量要求较高的大型OpenStack安装中。

cepmon—自定义创建的节点角色，只将MON服务从控制器移动到单独的节点。

CephMDS—自定义创建的节点角色，只将MDS服务从控制器移动到单独的节点。

**HCI (Hyperconverged Infrastructure)**节点是指计算、存储服务和设备都在同一节点上的配置。这种配置可以提高存储吞吐量大的应用程序的性能。默认是ComputeHCI角色，它只向计算节点添加osd，有效地扩大您的专用Ceph集群。Ceph控制平面服务保留在控制节点上。其他节点角色为超融合节点添加了各种控制平面业务的选择。

ComputeHCI -计算节点+ osd。这些节点没有Ceph控制平面服务。

HciCephAII—计算节点+ osd和所有Ceph控制平面服务。

HciCephFile—计算节点+ osd和MDS服务。用于向外扩展文件共享存储容量。

HciCephMon—计算节点+ osd, MON和MGR服务。用于向外扩展块存储容量。

HciCephObject -计算节点+ osd + RGW服务。用于向外扩展对象网关访问。

分布式计算节点(DCN)是超融合节点的另一种形式，设计用于属于同一个OpenStack overcloud的远程数据中心或分支机构。为DCN，overcloud部署创建一个专用的Ceph集群，除了主站点上的专用Ceph集群外，每个远程站点至少有三个节点。这种体系结构不是扩展集群配置。后续的DCN版本支持将Glance安装在远程位置，以便更快地访问本地图像。

DistributedComputeHCI -一个包含Ceph、Cinder和Glance的DCN节点。

distributedcomputeciscaleout -一个DCN节点，包含Ceph, Cinder和针对Glance的HAProxy

实现一个外部的Red Hat Ceph存储集群

RHOSP上云安装有一个undercloud节点，在本文第一个图中称为Director节点。Triple0从Director节点安装overcloud。默认的Triple0业务流程模板在“/usr /share/openstack-Tripleo-heat-templates”目录下。当部署集成了Ceph的OpenStack时，undercloud节点成为Ansible控制器和集群管理主机

下面的叙述提供了Triple0云部署资源的有限视图。您的组织的部署将需要进一步的设计工作，因为每个生产overcloud都有独特的存储需求

由于默认的业务流程文件正在不断增强，所以您一定不能在它们的原始位置修改默认模板文件。相反，应该创建一个目录来存储自定义环境文件和参数覆盖。以下ceph-ansib le-external.yaml环境文件指示Trip le0使用ceph -ansib le客户端角色访问预先存在的外部ceph集群。若要覆盖此文件中的默认设置，请使用自定义参数文件

[stack@director ceph-ansible]$ cat ceph-ansible-external.yaml 
resource_registry: 
 OS: :TripleO: : Services: : CephExternal: .. / .. /deployment/ceph-ansible/ceph-external.yaml 
parameter_defaults: 
# NOTE: These example parameters are required when using CephExternal 
#CephClusterFSID: ' 4b5c8c0a-ff60-454b-alb4-9747aa737d19 ' 
#CephClientKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ== ' 
#CephExternalMonHost : ' 172.16.1.7, 172.16.1.8' 
# the following parameters enable Ceph backends for Cinder, Glance, Gnocchi and 
Nova 
 NovaEnableRbdBackend: true 
 CinderEnableRbdBackend: true 
 CinderBackupBackend: ceph 
 GlanceBackend: rbd 
# Uncomment below if enabling legacy telemetry 
# GnocchiBackend: rbd 
# If the Ceph pools which host VMs, Volumes and Images do not match these 
# names OR the client keyring to use is not called ' openstack', edit the 
# following as needed. 
 NovaRbdPoolName: vms 
 CinderRbdPoolName: volumes 
 CinderBackupRbdPoolName: backups 
GlanceRbdPoolName: images 
# Uncomment below if enabling legacy telemetry 
# GnocchiRbdPoolName: metrics 
 CephClientUserName: openstack 
# finally we disable the Cinder LVM backend 
 CinderEnableiscsiBackend: false 

TripleO 部署使用openstack overcloud deploy命令指定所有要部署的overcloud服务的环境文件列表。在部署之前，使用openstack tripleo container image prepare命令来确定配置中引用的所有服务，并准备一份校正器容器列表，以便下载并提供给超云部署。在安装过程中，使用Kolla在节点角色定义的正确节点上配置和启动每个服务容器。

对于这个外部Ceph集群示例，TripleO需要一个参数文件来指定真正的集群参数，以覆盖Ceph-ansible-external中的默认参数。yaml文件。这个示例参数-overrides。Yaml文件放置在自定义部署中

文件目录。您可以从适当的ceph认证添加客户端的结果中获得密钥。打开堆栈命令。

parameter_defaults: 
# The cluster FSID 
  CephClusterFSID: '4b5c8c0a-ff60-454b-alb4-9747aa737d19' 
# The cephX user auth key 
  CephClientKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ==' 
# The list of Ceph monitors 
  CephExternalMonHost: '172.16.1.7, 172.16.1.8, 172.16.1.9'

Trip le0依赖于Bare Metal服务来准备节点，然后将它们安装为Ceph服务器。磁盘设备(包括物理的和虚拟的)必须清除所有分区表和其他工件。否则，Ceph在确定设备正在使用后拒绝覆盖该设备。要从磁盘中删除所有元数据，并创建GPT标签，请在/home/stack/underc文件中设置以下参数。配置文件在云下。每当节点状态设置为可用时，裸金属服务启动节点并清理磁盘

clean_nodes=true

13.2 在OpenStack组件中实现存储

13.2.1 OpenStack存储实现概述

在Ceph之前，每个存储组件都使用本地存储，如直接连接的物理磁盘或虚拟磁盘，或网络连接的存储(NAS)或存储区域网络(SAN)硬件。NAS和SAN配置的使用支持控制平面节点可以共享的更大的存储，但这需要额外的物理NI c或主机适配器，限制了控制平面容易扩展的能力。

网络文件系统(NFS)也是跨计算节点和控制节点访问共享存储的有效方法。尽管NFS已经成熟，并且在配置冗余时具有显著的性能和弹性，但它有伸缩性限制，并且不是为云应用程序需求而设计的。OpenStack需要一个可伸缩的云存储解决方案设计

回顾OSP中的Ceph能力

Ceph是一种可扩展的存储解决方案，可以跨商品存储节点复制数据。Ceph采用对象存储架构进行数据存储，并提供对象存储、块存储和文件系统的多个存储接口。

Ceph与OpenStack特性的集成:

1. 支持与Swift对象存储使用相同的API

2. 通过写时复制支持精简配置，使基于卷的配置快速

3. 支持Keystone身份认证，透明集成或替换Swift Object Store

4. 统一对象存储和块存储

5. 支持cepfs分布式文件系统接口

13.2.2 按类型实现存储

每个OpenStack服务都是一个API抽象，隐藏了后端实现。许多服务可以配置多个后端以同时使用。一个服务可以在Ceph中配置多个池，并使用分层或标记标准来透明地选择

适当的存储池。层还可以容纳具有不同性能需求的工作负载。如果在现有集群中实现层，则CRUSH规则更改可能导致池数据的重大移动。

OpenStack服务使用唯一的服务帐号，以服务名称命名。服务帐户代表请求用户或其他服务运行服务操作。在Ceph中为每个需要存储访问的OpenStack服务创建类似的帐户。例如，Image服务被配置为Ceph访问，使用这个命令:

[admin@node -]# ceph auth get-or-create client.glance \
	mon 'profile rbd' \
	osd 'profile rbd pool=images' \
	mgr ' profile rbd pool=images' 

Image Storage

在OpenStack中，Image服务的默认后端是一个文件存储，位于控制节点上的Glance API节点上。位置是可配置的，默认为/var/lib/glance。为了提高可伸缩性，Image服务在控制节点的默认/ var/lib/glance/Image-cache/位置实现了一个图像缓存。当Compute服务加载以默认QCOW2格式存储的图像并将其转换为RAW以便在计算节点上使用时，将缓存转换后的图像。

当Red Hat Open Stack Platform安装了Swift Object Store时，Trip leO默认将图像服务后端放在Swift上。Swift服务创建了一个名为glance的容器来存储glance图像。

当Ceph存储集成到RHOSP中时，Trip leO默认将映像服务后端放在Ceph RADOS块设备(RBD)上。Glance映像存储在Ceph池中，称为images。RHOSP将图像作为不可变的blob处理，并相应地处理它们。池名可以通过g lance_pool_name属性进行配置。默认情况下，镜像池被配置为复制池，这意味着所有镜像都跨存储设备进行复制，以实现透明弹性。

映像池可以配置为擦除编码，以节省磁盘空间，同时稍微增加CPU利用率。

当使用Ceph作为存储后端时，禁用图像缓存是很重要的，因为Ceph希望Glance图像以RAW格式存储，所以不需要禁用图像缓存。当使用RAW图像时，所有的图像交互都发生在Ceph中，包括图像克隆和快照创建。

禁用图像缓存可以消除控制节点上重要的CPU和网络活动。

当使用带有分布式计算节点(DCN)的分布式体系结构时，TripleO可以使用每个远程站点上的映像池配置映像服务。您可以在中心(集线器)站点和远程站点之间复制映像。DCN Ceph集群使用RBD技术，如写时拷贝和快照分层，以快速启动实例。镜像、块存储和计算服务都必须配置为使用Ceph RBD作为后端存储

Object Storage

对象存储在OpenStack中是通过Swift (Object Store)服务实现的。对象存储服务同时实现了Swift API和Amazon S3 API。默认的存储后端是基于文件的，并在is rv /node的子目录中使用xfs格式的分区挂载在指定存储节点上。您也可以配置对象存储服务，使用现有的外部Swift集群作为后端。

当Ceph存储集成到RHOSP中时，Trip leO配置对象存储服务使用RADOS网关(RGW)作为后端。类似地，Image服务是为RGW配置的，因为Swift不能作为后端使用。

Ceph对象网关可以与Keystone身份服务集成。此集成将RGW配置为使用Identity服务作为用户权限。如果Keystone授权一个用户访问网关，那么该用户也在Ceph对象网关上创建。Keystone验证的身份令牌被Ceph对象网关认为有效。Ceph对象网关也被配置为Keystone中的对象存储端点

Block Storage

块存储在OpenStack中是通过Cinder (Block storage service)服务实现的。块存储服务提供持久卷，这些卷保持在存储中，并且在不附加到任何实例的情况下是稳定的。配置块存储服务的常用方法是多个后端。默认的存储后端为LVM (Logical Volume Manager)，配置LVM使用卷组cinder -volumes。Trip leO可以在安装期间创建卷组，也可以使用现有的cinder-volumes卷组。

当Ceph存储集成到RHOSP中时，TripleO配置块存储服务使用RADOS块设备(RBD)作为后端。块存储卷存储在一个称为卷的Ceph池中。卷备份存储在名为backups的Ceph池中。Ceph通过使用libvirt将块设备映像附加到OpenStack实例，该实例将QEMU接口配置到librbd Ceph模块。Ceph条带在集群内的多个osd上块卷，与本地驱动器相比，为大卷提供了更高的性能。

OpenStack的卷、快照、克隆均以块设备的形式实现。OpenStack使用卷启动虚拟机，或将卷作为进一步的应用存储挂载到运行中的虚拟机

13.2.3 File Storage

文件存储在OpenStack中由共享文件系统服务(马尼拉)实现。共享文件系统服务支持多个后端，可以从一个或多个后端提供共享。共享服务器通过使用各种文件系统协议导出文件共享，例如NFS、CIFS、GlusterFS或HDFS。

共享文件系统服务是持久存储，可以挂载到任意数量的客户机上。您可以从一个实例分离文件共享，并将它们附加到另一个实例，而不会丢失数据。共享文件系统服务管理共享属性、访问规则、配额和速率限制。因为没有特权的用户不允许使用mount命令，Shared File Systems服务充当代理来挂载和卸载存储运营商配置的共享。

当Ceph存储集成到RHOSP中时，TripleO配置共享文件系统服务使用cepfs作为后端。cepfs在共享文件系统服务中使用NFS协议。TripleO可以使用Control lerStorageNFS服务器角色配置NFS ganesh集群作为libcephfs后端的可扩展接口

13.2.4 Compute Storage

临时存储在OpenStack中通过计算服务(Nova)实现。Compute服务使用KVM hypervisor和libvirt以虚拟机的形式启动计算工作负载。Compute服务需要两种类型的libvirt操作存储:

Base image: 映像服务中的映像的缓存和格式化副本。

实例覆盖: 将在基本映像上覆盖的分层卷，作为虚拟机的实例磁盘。

当Ceph存储集成到RHOSP中时，TripleO将计算服务配置为使用RADOS块设备(RBD)作为后端。有了RBD，实例操作系统磁盘既可以作为临时磁盘(在实例关闭时将被删除)管理，也可以作为持久卷管理。临时磁盘的行为与普通磁盘类似，可以列出、格式化、挂载并作为块设备使用。但是，磁盘及其数据不能被保存或访问超出其附加实例的范围

在早期的OpenStack版本中，虚拟机的磁盘出现在hypervisor文件系统的“/var/lib/nova/instances/uuid/”目录下。
早期的Ceph版本只能使用块存储服务boot -from-volume功能启动虚拟机

在最近的版本中，你可以直接引导Ceph中的每个VM，而不需要使用块存储服务。该特性使hypervisor能够在维护操作或硬件故障时使用动态迁移和疏散操作来恢复另一个hypervisor中的虚拟机

13.3 介绍OpenShift存储体系结构

13.3.1 Red Hat OpenShift容器平台概述

Kubernetes是一种编排服务，用于部署、管理和扩展容器化应用程序。开发人员可以使用Kubernetes迭代构建应用程序并自动化管理任务。Kubernetes将容器和其他资源包装到Pod中，并将应用程序抽象到单个部署单元中。

Red Hat OpenShift容器平台（RHOCP）是一个模块化组件和服务的集合，构建在Kubernetes容器基础设施之上。OpenShift容器平台提供远程管理、多租户、监控、审核和应用程序生命周期管理。它具有增强的安全功能和自助服务接口。它还与主要红帽产品集成，扩展了平台的功能。

OpenShift容器平台在大多数云中可用，无论是作为托管云服务在公共云中或作为数据中心中的自我管理软件。这些实现提供不同级别的平台自动化、更新策略和操作定制。这里参考了RHOCP 4.8。

OpenShift容器平台通过以下方式分配集群内每个节点的职责：

不同的角色。机器配置池（MCP）是分配角色的主机集。每个MCP管理主机及其配置。控制平面和计算MCP为：由defualt创建。

计算节点负责运行控制平面的计划工作负载，计算节点包含服务，如CR-0（打开的容器运行时接口容器倡议兼容性），以运行、停止或重新启动容器，以及kubelet，它充当代理接受操作容器的请求。

控制平面节点负责运行主要OpenShift服务，例如其中：

OpenShift API服务器。它验证并配置OpenShift资源的数据，例如项目、路线和模板。

OpenShift控制器管理器。它监视etcd服务的资源和用途的变化用于强制指定状态的API。

OpenShift是OAuth API服务器。它将验证和配置数据以验证到OpenShift容器平台，如用户、组和OAuth令牌。

13.3.2 描述Operators 和自定义资源定义

Operator是调用OpenShift控制器API来管理资源的应用程序。

Operators 提供了一种可重复的方式来打包、部署和管理容器化应用程序

Operator容器映像定义了部署的要求，如依赖服务和硬件资源。因为操作员需要资源访问，所以他们通常使用自定义安全设置。Operator为资源管理和服务配置提供API，并提供自动化管理和升级策略。

OpenShift容器平台使用操作员生命周期管理器（OLM）来管理操作员。

OLM协调Operator目录中其他Operator的部署、更新、资源利用和删除。每个运营商都有一个群集服务版本（CSV），该版本描述了Operator运行所需的技术信息，如其所需的RBAC规则及其管理或依赖的资源。OLM本身就是一个运营商。

自定义资源定义（CRD）对象定义集群中的唯一对象类型。自定义资源（CR）对象是从CRD创建的。只有群集管理员才能创建CRD。

具有CRD读取权限的开发人员可以将定义的CR对象类型添加到他们的项目中。

Operator通过将CRD与任何所需的RBAC策略和其他特定于软件的逻辑打包来使用CRD。群集管理员可以独立于

Operator生命周期，可供所有用户使用。

13.3.3 介绍Red Hat OpenShift Data Foundation

红帽OpenShift Data Foundation（前身为红帽OpenShift容器存储）是云存储和数据服务的高度集成集合，充当OpenShift集装箱平台的存储控制平面。OpenShift数据基金会作为运营商在Red Hat OpenShift容器平台服务目录中提供。OpenShift数据基础4.8使用红帽Ceph存储4.2。

13.3.4 介绍OpenShift容器存储Operator

OpenShift容器存储operator 将三个operator 集成为一个operator 包，以初始化和管理OpenShift数据基础服务。这三个运营商是OpenShift容器存储（ocs operator ）、Rook Ceph和多云对象网关（NooBaa）。这个

operator 捆绑包包括一个聚合CSV和部署ocs operator 、Rook Ceph和NooBaa operator 所需的所有CRD

描述ocs operator

操作员ocs-操作员初始化OpenShift数据基础服务的任务并执行操作作为Rook Ceph和NooBaa的配置网关。运营商ocs运营商取决于：

在OCS中定义的配置上！CSV中的初始化和存储C/uster CRD捆安装操作员包后，ocs操作员启动并创建

0中国化资源（如果尚未存在）。中国化资源执行基本设置并初始化服务。它创建openshift-storage命名空间

其中其他bundle操作符将创建资源。您可以编辑此资源以调整OpenShift数据基础操作符中包含的工具。如果0中国化资源处于失败状态，进一步的启动请求将被忽略，直到资源被删除。

StorageCluster资源管理Rook、Ceph和NooBaa运营商CRD的创建和协调。这些CRD是由已知的最佳实践和政策定义的：红帽支撑。您可以使用中的安装向导创建StorageCluster资源OpenShift是一个容器平台。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知，这是一个开源项目，如果你认可它，不要吝啬星星哦 :)

---

---

© 2018-至今 liruilonger@gmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)