第 1 章 OpenStack 采用

有关配置服务的 Director 和 Operator 部署之间有一个基本的区别。

在 Director 部署中，许多服务配置由 Director 特定的配置选项抽象化。单个 Director 选项可能会触发多个服务的更改，并支持驱动程序（如 Cinder）需要对 Director 代码库的补丁。

在 Operator 部署中，此方法已更改：减少特定于安装程序的知识，并尽可能利用 OpenShift 和 OpenStack 服务特定知识。

为此，OpenStack 服务对 OpenShift 部署具有明显的默认值，人类运算符将提供配置片段以提供必要的配置，如 cinder 后端配置或覆盖默认值。

这可减少服务特定配置文件（如 cinder.conf）和清单中提供的 Operator 之间的距离。

这些配置片断会传递给清单中可用的不同 customServiceConfig 部分中的 Operator，然后在以下级别的服务中分层。为了说明这一点，如果您要在顶级 Cinder 级别(spec: cinder: template:)上设置配置，那么它将应用到所有 Cinder 服务；例如，要在您要执行的所有 cinder 服务中启用 debug：

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      customServiceConfig: |
        [DEFAULT]
        debug = True
< . . . >

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      customServiceConfig: |
        [DEFAULT]
        debug = True
< . . . >

如果您只想为其中一个 cinder 服务设置它，如调度程序，那么您可以使用 cinderScheduler 部分：

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderScheduler:
        customServiceConfig: |
          [DEFAULT]
          debug = True
< . . . >

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderScheduler:
        customServiceConfig: |
          [DEFAULT]
          debug = True
< . . . >

在 OpenShift 中，不建议将凭据（如凭证）存储在 CR 中的 cinder 存储阵列中，因此大多数 OpenStack 操作器都提供了一种机制，可以将 OpenShift 的 Secret 用于服务敏感配置参数，然后在 customServiceConfigSecrets 部分中引用（类似于 customServiceConfig Secrets 部分）。

customServiceConfigSecrets 中传递的 Secret 引用的内容与 customServiceConfig 的格式相同：一个带有 section/s 和 configuration 选项的代码片段。

当服务配置中存在敏感信息时，它成为个人首选项，无论是将所有配置存储在 Secret 中还是仅存储敏感部分。但是，如果您在 Secret 和 customServiceConfig 之间分割配置，您仍需要同时存在部分标头（例如： [DEFAULT]）。

应对每个服务的采用过程付费，因为它们可能对其配置有一些特别关注。

在 Director 部署中，对于节点有 4 个不同的标准角色： Controller、Compute、Ceph Storage、Swift Storage，但在容器集化 OpenStack 中，您根据运行位置、OpenShift 或外部的 OpenStack 做出区分。

采用 Director OpenStack 时，您的 Compute 节点将直接变为外部节点，因此不应进行额外的规划。

在许多采用 Controller 节点的部署中，需要一些考虑，因为有许多可以运行控制器服务的 OpenShift 节点，并且您必须决定要使用的节点、使用它们的方式，并确保这些节点已准备好运行服务。

在大多数 master 节点上运行 OpenStack 服务的部署中，对 OpenShift 集群有严重影响，因此建议您将 OpenStack 服务放在非 master 节点上。

默认情况下，OpenStack Operator 在任何 worker 节点上部署 OpenStack 服务，但不一定适用于所有部署，甚至可能甚至没有部署这样的服务。

在规划部署时，最好记住，不是 OpenStack 部署上的所有服务都与它们有截然不同的要求相同。

查看 Cinder 组件，您可以明确看到其服务的不同要求：cinder-scheduler 是一个非常轻量的服务，它具有低内存、磁盘、网络和 CPU 使用量；由于资源列表请求，cinder-api 服务具有更高的网络使用量；cinder-volume 服务将具有高磁盘和网络使用量，因为许多操作都位于数据路径中（离线卷迁移，因此其操作将具有更高的网络使用量；cinder-volume 服务将具有高磁盘和网络使用量，因为其操作位于数据路径中（离线卷迁移，因此。 从镜像创建卷，然后您有 cinder-backup 服务，该服务具有高内存、网络和 CPU （压缩数据）要求。

Glance 和 Swift 组件位于数据路径中，以及 RabbitMQ 和 Galera 服务。

鉴于这些要求，最好不要让这些服务在 OpenShift 工作程序节点上都更有可能影响其他工作负载，或者您可能不考虑使用轻量级服务，但您想将大量服务固定到一组基础架构节点。

还需要考虑硬件限制，因为如果您使用一个光纤通道(FC) Cinder 后端，则需要 cinder-volume、cinder-backup，甚至可能是 glance （如果使用 Cinder 作为后端）服务在具有 HBA 的 OpenShift 主机上运行。

OpenStack Operator 可以在何处运行 OpenStack 服务方面具有很大的灵活性，因为您可以使用节点标签来定义哪些 OpenShift 节点有资格运行不同的 OpenStack 服务。请参阅 About 节点选择器，以了解有关使用标签定义 OpenStack 服务的放置的更多信息。

在 OpenStack 部署中查看存储时，您可以区分两种不同的类型，服务本身的存储要求以及用于服务将管理的 OpenStack 用户的存储。

这些要求可能会驱动您的 OpenShift 节点选择，如上所述，您可能需要在 OpenShift 节点上进行一些准备，然后才能部署服务。