使用 CRC 和 MinIO 为 Red Hat OpenShift 开发

MinIO 始终是高性能和互操作的云原生对象存储的先驱，它用途广泛且灵活。MinIO 运行在众多平台上，例如 Kubernetes、AWS、GCP、Azure、裸机 Linux 和许多其他环境。

最近，行业出现了一种趋势，即将数据“靠近”本地。结果是，组织现在希望将他们的数据保存在他们拥有的服务器上，在他们自己的数据中心或托管服务提供商处。主要原因是云计算成本失控，再加上当前的经济环境。对于大多数应用程序，只要工作负载得到很好的理解，就可以在本地实现与云计算相同的可扩展性和性能水平，而成本只是云计算的一小部分。

但这带来了一个难题 - 云计算的优势之一也是基础设施或多或少由云服务提供商管理。例如，EKS 和 GKE 等托管 Kubernetes 服务负责管理后端，包括升级、降级、添加和删除节点以及其他操作。对于本地 Kubernetes，可能是几十个或几百个集群，会给您的工程和运营团队增加大量的技术债务。您需要引导自己的 Kubernetes 基础设施，并能够承担管理、维护和其他操作的责任。这可能是一个相当大的挑战 - 如果它能在这个过程中让我们的生活更轻松，那不是很好吗？

这就是 Red Hat OpenShift 改变游戏规则的地方。它不仅使您能够管理自己的 Kubernetes 集群，还让您能够在自己的本地硬件上进行管理。您必须确保定期更新各种组件，但 OpenShift 平台及其以 DevOps 为中心，但以开发人员为中心的架构方法，使其成为本地 Kubernetes 集群的绝佳选择。

MinIO 运算符和 Kubernetes 插件已获得 OpenShift 的使用认证，使其易于将 MinIO 集成到现有工作流程中。我们的客户经常在利用本地和公共云资源的多云配置中运行 OpenShift。在 OpenShift 上运行 MinIO 使企业能够在他们选择的硬件或云实例上实现云原生弹性，平衡成本、容量和性能。

通过在 OpenShift 上运行 MinIO，您可以使用 Kubernetes 编排获得软件定义的可扩展性和自动化，MinIO 提供对象存储。随着存储成为软件定义基础设施的一部分，您可以统一 AI/ML、分析和其他现代数据工作负载的部署和管理。这些应用程序可以共享同一个本地 MinIO 部署，而不是构建多个数据孤岛并在它们之间复制数据，这有助于提高数据的安全性和弹性。最后，这种方法避免了云锁定。您希望能够将数据迁移到最适合您的工作负载和业务目标的环境中。通过在多个位置/云中将 MinIO 部署到 OpenShift 之上，您可以使用 站点到站点复制 无缝地移动数据。这确保您始终可以使用最适合工作的工具 - 无论是在公共云、私有云还是托管服务中。

话虽如此，当您想开发并让开发人员将组件部署到 OpenShift 时，设置它可能会非常耗费资源。您需要一个 8 到 10 个节点的集群才能让整个基础设施启动并运行，这可能不利于开发。与其完全部署 OpenShift，如果开发人员可以在将应用程序投入生产之前在自己的笔记本电脑上本地测试应用程序，那不是很好吗？

为了在这个教程中实现这一点，我们将利用 Red Hat CodeReady Containers (CRC)，它使开发人员能够使用本地计算机在 OpenShift 上进行测试和开发。虽然需要一些专业知识才能让 OpenShift 启动并运行，但此博文将引导您将 MinIO 部署到 OpenShift，而无需像在生产环境中那样依赖完整版本的 OpenShift 安装程序安装。

好的，我们开始吧！

使用 CRC OpenShift 集群

使用 CRC 时，您可以选择运行时来部署资源，在这种情况下，我们使用 OpenShift Container Platform。请确保满足您正在开发的机器上的以下最低要求。

• 4 核 CPU
• 10 GB 内存
• 50 GB 可用存储空间

在以下步骤中，我们将使用 CentOS 操作系统

从 Red Hat 下载 CRC。

转到下载位置并解压缩它

$ cd ~/Downloads
$ tar xvf crc-linux-amd64.tar.xz

创建一个 ~/bin 目录，并将 crc 可执行文件复制到该目录

$ mkdir -p ~/bin
$ cp ~/Downloads/crc-linux-*-amd64/crc ~/bin

当然，不要忘记将 ~/bin 添加到您的 PATH 中

$ export PATH=$PATH:$HOME/bin
$ echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

运行设置以设置基本配置

$ crc setup

最后，启动 CRC 实例，确保记下输出的凭据

$ crc start

配置 OpenShift 组件

为了与集群通信，我们将使用 oc CLI 而不是使用 kubectl。

手动方法

从 下载页面 下载适合您操作系统的二进制文件。

选择与您在 CRC 中运行的 OpenShift 版本匹配的版本。

点击立即下载。下载完成后，解压缩存档。

$ tar xvzf <file>

将 oc 二进制文件移动到 ~/bin

$ mv oc ~/bin

缓存方法

除了上述方法之外，还有一种缓存方法，它在某些方面比手动方法更简单。此方法将所需的认证凭据与 oc 二进制文件一起缓存，以便与 CRC 集群通信，而无需手动下载任何内容。

您可以使用以下命令将缓存的 oc 添加到您的 PATH

$ crc oc-env

选择一种方法安装 oc cli 后，运行以下 oc 命令以访问控制台。

crc start 命令应该已经输出了一些凭据，在这里使用它们。如果您没有保存它们，请运行以下命令检索它们

$ crc console --credentials

现在您可以以 developer 用户身份登录

$ oc login -u developer https://api.crc.testing:6443

从现在起，我们可以使用 oc CLI 命令与 CRC 进行交互。让我们运行一些命令来验证一切按预期工作。

将 oc 上下文更改为 crc-admin

$ oc config use-context crc-admin

验证您是 kubeadmin

$ oc whoami
kubeadmin

也运行 get containers 命令

$ oc get co

好的，现在我们已经设置了所有基础，让我们继续安装 MinIO。

安装 MinIO

我们将与其他资源相同的 CRC OpenShift 集群中安装 MinIO。您只需要 3 个组件即可开始使用此简单安装。

• 有状态集
• 服务
• 路由

首先，让我们继续创建有状态集，将以下文件保存为 statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: minio
  name: minio
  namespace: default
spec:
  podManagementPolicy: OrderedReady
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: minio
  serviceName: minio
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: minio
    spec:
      containers:
      - args:
        - server
        - /data
        env:
        - name: MINIO_KMS_SECRET_KEY
          value: my-minio-key:oyArl7zlPECEduNbB1KXgdzDn2Bdpvvw0l8VO51HQnY=
        image: minio/minio:RELEASE.2023-05-27T05-56-19Z
        imagePullPolicy: IfNotPresent
        name: minio
        ports:
        - containerPort: 9000
          hostPort: 9000
          protocol: TCP
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /data
          name: data
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      terminationGracePeriodSeconds: 30
  updateStrategy:
    rollingUpdate:
      partition: 0
    type: RollingUpdate
  volumeClaimTemplates:
  - apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      creationTimestamp: null
      name: data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: crc-csi-hostpath-provisioner
      volumeMode: Filesystem
    status:
      phase: Pending

保存后，使用 oc 命令应用它

oc apply -f statefulset.yaml

接下来，让我们创建 service.yaml，以便我们可以访问通过有状态集部署的 MinIO。

apiVersion: v1
kind: Service
metadata:
  name: minio
  labels:
    app: minio
spec:
  type: NodePort
  ports:
    - port: 9000
      name: minio
      nodePort: 30080
  selector:
    app: minio

保存后，使用 oc 命令应用它

oc apply -f service.yaml

最后但并非最不重要的一点，创建 route.yaml，以便我们可以使用 mc 客户端从外部访问 MinIO 服务。

apiVersion: v1
kind: Service
metadata:
  name: minio
  labels:
    app: minio
spec:
  type: NodePort
  ports:
    - port: 9000
      name: minio
      nodePort: 30080
  selector:
    app: minio

使用以下命令通过 mc cli 访问

$ mc alias set myminio http://my-route-default.apps-crc.testing minioadmin minioadmin --insecure
Added myminio successfully.

升级 CRC

与任何软件一样，您需要确保始终使用最新版本，这包括 CRC。升级 CRC 非常简单。

从 Red Hat 下载最新版本的 CRC。

删除现有的 CRC 实例，这将导致存储在该实例上的数据丢失 - 所以要小心

$ crc delete

使用安装过程中的步骤解压缩下载的 CRC tar。获得新的 crc 二进制文件后，将其替换 ~/bin 中的现有二进制文件。使用以下命令进行验证

$ crc version

设置并启动新的 CRC 实例

$ crc setup

$ crc start

在 Red Hat OpenShift 上进行开发和部署的灵活性

虽然 Red Hat CRC 非常酷，并且附带了一套瑞士军刀功能，可以帮助您快速开始在本地环境中进行开发，但它确实有一些值得一提的注意事项。

不用说，CRC 集群本质上是短暂的。不要在生产环境中部署它，也不要在上面存储任何生产数据，除非是为了测试目的。您应该在经过适当计划的生产硬件上完成 OpenShift 集群的完整端到端生产安装，以获得最佳性能。

目前不支持升级到 OpenShift Container Platform 的更新版本，升级它可能会导致难以重现的不可预见的影响。此外，OpenShift Container Platform 在内部作为实例运行，因此，如果您需要访问实例外部的网络资源，您可能需要进行一些额外的配置才能使其正常工作。
尽管如此，我们仍然建议使用 CRC，这样您可以快速开始使用 OpenShift 和 MinIO。不要相信我们的话，自己动手试试，您可以加入我们的 Slack 频道这里，以便我们在您操作过程中提供帮助。