当我们宣布MinIO 在 Red Hat OpenShift 上可用时，我们没有预料到需求会如此之大，以至于我们有一天会写一系列关于这种强大组合的博文。这种组合正在被迅速采用，原因在于本地云的普遍性和大型组织希望将其数据靠近应用程序和用户的需求，同时为用户提供他们在公共云中熟知并信任的云原生功能。最终，MinIO 和 OpenShift 的组合使团队能够使用原生 API、CLI 和插件以版本控制的方式启动基础设施，从而跟踪更改。除此之外，OpenShift 还具有操作符生命周期管理 (OLM) 的概念，它可以帮助开发人员安装、更新和管理部署到 OpenShift 集群的 Kubernetes 操作符的生命周期。Operator Framework 工具包允许您以有效、自动化和可扩展的方式管理操作符。
在上一篇文章中，我们讨论了如何在笔记本电脑上使用 MinIO 和 OpenShift 入门，在这篇文章中，我们将更深入地讨论在您想要设置集群（一个实际的集群，而不仅仅是一台测试机器）以进行概念验证或任何其他目的时需要采取的步骤，以便您拥有更强大的东西来进行实验。
您需要了解 OpenShift 安全策略的细微差别，才能为实验、开发、测试或概念验证设置 OpenShift 集群。生产集群则有所不同，需要额外的要求，我们将在以后的博文中讨论。
OpenShift 集群准备工作
让我们首先检查所需的各个组件，以及在为概念验证目的设置和配置 OpenShift 集群时应如何考虑它们。再次强调，这些设置不应用于生产环境。
OpenShift 旨在使用 Kubernetes 概念公开 Docker 格式的容器镜像，开发人员可以尽可能轻松地将应用程序部署到基础设施。OpenShift Container Platform 在 Kubernetes 集群之上具有多个协同工作的系统，数据存储在 etcd 中。这些服务公开丰富的 API，开发人员可以使用这些 API 来自定义其集群和部署。OpenShift 在这方面也十分重视安全性。用户访问通过 OAuth 令牌和 X.509 证书严格控制，大多数与 API 的通信都通过 `oc` CLI 工具进行，该工具在大多数情况下使用 OAuth 载荷令牌。身份验证后，授权由 OpenShift Container Platform 策略引擎处理，该引擎将多个不同的角色分组到一个文档中。这些可能是诸如创建 StatefulSet、获取秘密列表和其他敏感操作之类的操作。以下是此架构的示意图，我们将在本文的后面部分更详细地介绍。
服务器基础设施
虽然概念验证的初始基础设施不需要非常强大，但 OpenShift 对节点数量以及每个节点为集群提供的功能类型有一些具体要求。
至少需要一个具有以下规格的主节点
- 4 个 CPU
- 16 GB RAM
- 50 GB 硬盘空间
由于这是概念验证，因此 etcd 可以与主节点位于同一物理节点上，只需确保您至少有 4 个 CPU 即可。为简单起见，使用简单的分区方案，无需过分详细 – 请记住，此概念验证的目标是以最少的开销启动并运行。
接下来，我们需要添加 2-3 个可以承载 Kubernetes 工作负载的物理节点。MinIO 非常轻量级，即使在最密集的操作（例如擦除编码、加密、解密和压缩）期间，也几乎不会占用20% 的 CPU，因此您无需投入大量 CPU 能力，但请确保有足够的驱动器空间和内存，具体取决于您在测试中使用的数据量。一般的经验法则是，随着数据量的增加，增加节点上的内存。有关更多信息，请参阅为您的 MinIO 部署选择最佳硬件。
运行工作负载的节点的规格应如下所示
- 1-2 个 CPU
- 8-16 GB MEM
- 50-500 GB 驱动器空间
与主节点类似，让我们也使这些节点中的分区保持简单。我们没有给出具体的规格，而是添加了一个范围，以便您可以决定什么最适合您的概念验证。
安全策略
现在是棘手的部分了。基础设施设置完成后，如果您立即尝试启动 MinIO，很可能会遇到一堆错误。OpenShift 为什么会这样对你？事实证明，即使这会减慢您的速度，但它也是一件好事，因为 OpenShift 会强制您进行安全控制。我们喜欢这一点 – OpenShift 的构建重点在于安全性，就像 MinIO 一样，它们共同实现了性能和可扩展性，而不会牺牲安全性。
OpenShift 管理集群安全性的方法之一是使用 RBAC：基于角色的访问控制。这只是一个花哨的术语，指的是一组规则列表，这些规则被分组到称为角色的东西中，然后附加（也称为绑定）到您的用户。这些角色说明了您作为已认证的用户可以在集群上做什么和不能做什么。例如，您可以拥有一个具有 2 个规则的角色，一个规则说明他们可以列出所有 Pod，另一个规则说明他们只能查看集群中的一个特定秘密。规则可能相当复杂，但您有诸如 `auth can-i` 之类的命令，允许您遍历角色以查看您确切地拥有哪些访问权限。角色可以授予用户对集群或其中特定命名空间（在 OpenShift 中称为项目）的访问权限。
开箱即用，OpenShift 被锁定。虽然这对生产和边缘部署非常有用，但在概念验证中，这可能会成为一个障碍，因为它阻碍了开发人员探索 OpenShift 的复杂性并测试其应用程序。
现在我们对策略有了简要的概述，让我们继续部署 MinIO 租户，看看我们能否让所有这些都能正常工作。
获取 MinIO 存储库
$ git clone https://github.com/minio/operator.git |
应用资源以安装 MinIO
$ oc apply -k operator/resources
$ oc apply -k operator/examples/kustomization/tenant-lite |
您是否能够部署 MinIO？或者您是否看到任何错误？
策略引擎
那么发生了什么事呢？当您去应用资源时，在部署 MinIO 期间遇到的第一个问题之一将是类似于以下内容的错误
Forbidden: not usable by user or serviceaccount, spec.volumes[13]: Invalid value: "csi": csi volumes are not allowed to be used
此错误通常发生在您尝试部署使用DirectPV的租户时。
要解决此问题，首先，让我们使用以下命令获取租户下所有服务帐户的列表
oc get serviceaccounts -n <project>
项目可以是 minio-operator、directpv 或 tenant-namespace。
运行该命令后，将列出几个服务帐户。请务必使用以下命令授予所有服务帐户访问权限，因为即使缺少一个，您也可能在尝试进入调试的“兔子洞”时度过糟糕的一天。
列出它们后，继续使用以下命令授予它们特权访问权限。
oc adm policy add-scc-to-user privileged -n <tenant-namespace> -z builder
oc adm policy add-scc-to-user privileged -n <tenant-namespace> -z deployer
oc adm policy add-scc-to-user privileged -n <tenant-namespace> -z default
oc adm policy add-scc-to-user privileged -n <tenant-namespace> -z pipeline
oc adm policy add-scc-to-user privileged -n <tenant-namespace> -z tenant01-sa
设置完成后，让我们继续重新应用我们的 YAML 文件
应用资源以安装 MinIO
$ oc apply -k operator/resources
$ oc apply -k operator/examples/kustomization/tenant-lite |
验证 MinIO 正在运行。您还可以获取 MinIO 控制台的端口。
$ oc -n tenant-lite get svc | grep -i console |
如您所见，一旦您正确设置了必要的策略，部署 MinIO 就轻而易举了。
在一个 OpenShift 集群中，我们遇到了类似于意外服务帐户的错误。如果没有适当的权限，它不允许 MinIO Pod 被调度。通常，`builder`、`deployer` 和 `default` 是我们需要授予权限的所有权限，但对于概念验证，这将允许它继续进行 MinIO 部署。
他们看着我滚动
现在，您拥有了开始 OpenShift 概念验证所需的所有工具，在一个尽可能接近生产环境但没有安全限制的环境中。
我们建议谨慎操作。请注意，我们上面讨论的策略严格仅供概念验证非生产用例使用。当您希望在比笔记本电脑更强大的硬件上快速启动 OpenShift 以进行更多测试时，这些设置通常是可以的。此集群不应公开暴露于互联网。如果您想了解如何在生产环境中仅使用必要的策略运行锁定状态的 MinIO 和 OpenShift，请继续关注 - 我们将在即将发布的博文中介绍此主题。
如果您有任何关于 OpenShift 策略或如何配置它们的问题，请通过 Slack 联系我们！
擦除码计算器 
参考硬件 