关于kubernetes:做一个不背锅运维理论篇让我们一起鲁克鲁克rook开源存储编排

0次阅读

共计 6000 个字符,预计需要花费 15 分钟才能阅读完成。

写在开篇

本文联合了官网文档对 rook 的知识点做了一个梳理,帮忙有须要的敌人疾速入门,本篇不讲实战操作,下篇再讲。

  • 官网文档:https://rook.io/docs/rook/v1.11/Getting-Started/intro/

什么叫面向 K8S 的开源云原生存储

面向 Kubernetes 的开源云原生存储通常是指反对 Kubernetes 本地对象存储 API 的存储解决方案,以满足容器化应用程序的存储需要。这些解决方案能够应用 Kubernetes 内置的存储资源对象,例如 PV(Persistent Volume)和 PVC(Persistent Volume Claim),这使得治理存储资源变得更加容易和标准化。

一些次要的面向 Kubernetes 的开源云原生存储解决方案包含:

  1. Rook:这是一个开源的存储编排零碎,它将 Ceph、NFS、iSCSI 等存储系统转化为 Kubernetes 上的资源,使得它们能够被动静治理和调度。
  2. OpenEBS:这是一个开源的块存储解决方案,它应用 Kubernetes 原生的 API 来提供弹性块存储。OpenEBS 反对多种存储引擎,例如 ZFS、Ceph 等。
  3. Longhorn:这是一个开源的分布式块存储系统,它应用 Kubernetes 原生的 API 来提供高可用性、可扩展性和持久性的块存储。Longhorn 应用 Raft 算法来提供高可用性,并应用快照和增量备份来提供持久性。
  4. Ceph:这是一个开源的分布式存储系统,它反对块存储、文件存储和对象存储,并能够与 Kubernetes 集成。Ceph 反对多个存储协定,例如 RADOS、RBD、CephFS 等。

这些解决方案都应用了开源技术,并在 Kubernetes 上提供牢靠的云原生存储。依据应用程序的需要,能够抉择适宜本人的存储解决方案。

Rook 是什么

Rook 是一款开源的云原生存储编排器,能够帮忙在 Kubernetes 上部署和治理 Ceph 集群,使得 Ceph 更容易地与 Kubernetes 集成。简而言之,Rook 是一种在 Kubernetes 上运行 Ceph 的工具。

当 Rook 部署在 Kubernetes 中时,它会主动部署一个 Ceph 集群。这个 Ceph 集群将会由若干个 Ceph Mon 节点和若干个 Ceph OSD 节点组成。Ceph Mon 节点次要负责元数据的治理和监控,Ceph OSD 节点次要负责数据存储和复原。

在 Kubernetes 中应用 Rook 治理存储时,咱们须要创立 Kubernetes 对象(例如 PVC 和 StorageClass),这些对象通过 Rook Operator 转换为 Ceph 对象(例如 RBD 和 CephFS),而后 Rook Operator 会主动将 Ceph 对象转换为 Ceph 集群的配置文件,最初将这些配置文件利用到 Ceph 集群中。

当咱们应用 Kubernetes 客户端来创立 PVC 时,Kubernetes 会调用 Rook 提供的 CSI 驱动程序来为 PVC 创立一个 RBD 卷。这个 RBD 卷实际上是由 Rook 创立的 Ceph RBD 卷,并被挂载到了指标 Pod 中。同时,Rook 还会主动将 Ceph RBD 卷的映射信息保留在 Kubernetes 的 PV 中,以便于后续的应用。

Rook 和 Ceph 部署到 Kubernetes 中后,Rook 会将 Kubernetes 对象转换为 Ceph 对象,并治理 Ceph 集群的创立、配置和保护。Kubernetes 利用 Rook 提供的 CSI 驱动程序,将 PVC 转换为 Ceph RBD 卷,并将这些卷与 Pod 进行绑定。

测试环境布局

以下是在我筹备好的 k8s 环境上对 ceph osd 做的布局:

主机名 IP 角色 数据磁盘
k8s-b-master 192.168.11.7 k8s master
k8s-b-node01 192.168.11.8 k8s worker、ceph osd 5 个 1TB 硬盘
k8s-b-node02 192.168.11.9 k8s worker、ceph osd 5 个 1TB 硬盘

在一个由 1 个 master 节点和 2 个 worker 节点组成的 Kubernetes 集群上应用 Rook 作为后端存储管理器来运行 Ceph 集群,对于 OSD 节点的布局,能够有两种计划:

  • 「计划一:」 想要在每个 worker 节点上运行 osd,那么须要在每个 worker 节点上都装置有足够的磁盘用于存储 Ceph OSD。每个节点上的磁盘数量和大小取决于你的应用程序和负载,能够依据须要进行布局。

    须要留神的是,当 OSD 和 K8S 工作节点共用且是生产级别的 Ceph 集群时,至多须要 3 个 K8S 工作节点来提供足够的资源反对 Ceph OSD 容器的运行。同时,还须要在 K8S 集群中部署足够数量的 Ceph Monitor 节点来提供元数据管理和监控,以确保在单个节点呈现故障时集群不会收到影响,从而实现高可用性和容错性。总之,具体的布局计划取决于理论的需要和资源限度,我的是本地测试环境,所以目前就先给到 2 个工作节点。

  • 「计划二:」 另一种抉择是将 osd 搁置在一个独立的节点上,而不是在每个 worker 节点上运行一个 osd。这个节点能够是另一台服务器或云虚拟机,也能够是一个专门的存储节点,这样能够将 osd 从计算节点中分离出来,加重计算节点的负载。这时候就要在该服务器上安装并配置 Ceph。能够在 OSD 节点上运行 ceph-osd 命令,并将该节点的 IP 地址和端口增加到 Ceph 集群中。而后,能够在 Rook 的 cluster.yaml 中指定该 OSD 节点的名称和其余详细信息,以便 Rook 能够治理该节点。在这种状况下,须要确保在 Rook 和 Ceph 之间正确配置网络连接以便通信。

先决条件

  1. 要确保曾经有一个筹备好的 Kubernetes 集群(还没有筹备好环境的敌人,速度搞起来)
  2. Rook 反对最低版本 Kubernetes v1.19 或更高版本
  3. 要配置 Ceph 存储集群,至多须要以下一种本地存储类型:
    • 原始设施(无分区或格式化文件系统)
    • 原始分区(无格式化文件系统)
    • LVM 逻辑卷(无格式化文件系统)
    • 存储类中可用的长久化卷以块设施形式拜访(也就是说须要有一个反对以块设施形式拜访数据的存储类,并且其中须要有可用的长久化卷(Persistent Volumes)供应用程序应用。)

对于更多先决条件请参考:https://rook.io/docs/rook/v1.10/Getting-Started/Prerequisites…

部署前的思考

  1. 对于 rook 的 operator.yaml 中的 设施发现 的参数 “ROOK_ENABLE_DISCOVERY_DAEMON” 参数
  • 场景 1:如果仅打算应用 StorageClassDeviceSets 和 PVCs 来创立 OSDs,则不须要运行摸索守护过程。这是因为应用 PVCs 创立 OSDs 能够间接指定存储设备的节点和名称,而不须要依赖摸索守护过程来发现它们,所以就能够禁用发现性能,默认就是 false。
  • 场景 2:如果须要应用其余 Rook 性能,例如主动增加新节点或主动发现和增加新的 Ceph 存储服务,则须要启用摸索守护过程并设置 ROOK_ENABLE_DISCOVERY_DAEMON 参数为 true。

StorageClassDeviceSets 是 Kubernetes 存储资源模型的扩大,它容许管理员将节点上的物理存储设备映射为 Kubernetes 中的长久卷。这使得 Kubernetes 集群中的应用程序能够通过 PVC 拜访节点上的物理存储设备,从而实现本地长久化存储。StorageClassDeviceSets 是通过应用 Rook 存储运营商(operator)实现的,它容许管理员将存储设备定义为 StorageClassDeviceSets 资源,并将其绑定到 Kubernetes 集群中的节点。在这种状况下,每个 StorageClassDeviceSets 对象示意一组存储设备,这些设施能够用于创立 PV,并绑定到 PVC 上。在应用 StorageClassDeviceSets 创立 PV 时,管理员能够指定存储设备的数量和类型。Rook operator 将会主动在集群中的节点上查找符合要求的存储设备,并创立相应的 PV。当 PVC 与 PV 绑定时,应用程序能够应用相应的 PV 来长久化数据。应用 StorageClassDeviceSets 能够简化 Kubernetes 存储的治理和部署,特地是对于须要应用本地长久化存储的应用程序来说。Rook 官网文档提供了更具体的应用阐明和示例。

  1. 如果要启用或禁用某些 Rook 的性能,还能够持续在 operator.yaml 中设置,每一项设置都有阐明,如没有非凡需要放弃默认即可。
  2. 对于 Rook 中的 CSI 驱动程序 在 Kubernetes 中应用 Rook 作为存储管理器时,Rook 曾经提供了 CSI 驱动程序,因而不须要独自装置 CSI 驱动程序。然而,须要将 CSI 驱动程序的相干信息配置到 Kubernetes 集群中。这波及到定义存储类(StorageClass),该存储类与 Rook 的 CSI 驱动程序关联,并指定相干的参数,如存储后端类型、拜访模式等。这样,Kubernetes 就能够通过 CSI 驱动程序与 Rook 集群建立联系,并动静地为应用程序提供所需的存储资源。
  3. 如果想将 Rook 部署到其它命名空间,能够通过批改 Rook 部署清单中的命名空间字段来实现,比方 crds.yaml、common.yaml、operator.yaml、cluster.yaml、psp.yaml 中的 namespace 字段,在这些文件中,只须要将所有的命名空间名称都改为想要的名称就能够了。

清单文件

Rook 是一个开源的云原生存储编排器,它能够在 Kubernetes 集群中自动化地部署、治理和扩大存储系统。Rook 应用一个名为 ” 清单文件 ” 的 Kubernetes YAML 文件,用于定义和配置 Rook 存储集群。清单文件是一种申明式的形式来形容 Kubernetes 对象的配置和状态,能够用于创立、更新或删除 Kubernetes 对象。

在 Rook 中,清单文件蕴含了用于创立和治理存储集群的各种资源和配置,例如存储池、存储类、卷申明和守护过程等。应用清单文件能够不便地治理和自动化存储集群的创立和配置,同时也可能确保存储集群的一致性和可重复性。

通过清单文件,Rook 能够将存储系统的部署和治理与 Kubernetes 的 API 对象进行集成,使得存储集群能够像其余 Kubernetes 对象一样进行部署和治理,从而简化了存储系统的操作和保护。

上面列出了罕用的清单文件:

  1. crds.yaml:该文件蕴含 Rook 所需的所有自定义资源定义(CRDs),用于定义 Rook 集群中的各种资源对象,例如 Pool、Volume、Object Store 等。这些 CRDs 容许用户通过 Kubernetes API 创立、删除、更新和查看这些资源对象。
  2. common.yaml:该文件蕴含了 Rook 的公共配置,包含用于创立命名空间、服务账户、RBAC 规定等的配置。
  3. operator.yaml:该文件蕴含了 Rook 操作员的清单,它是一个 Kubernetes 控制器,用于监控 Rook 集群的各种资源对象,例如 CRDs,而后依据须要创立、更新和删除它们。
  4. cluster.yaml:该文件蕴含了 Rook 存储集群的清单,用于定义存储集群的各种属性,例如存储池、存储节点、正本数等。
  5. psp.yaml:该文件蕴含了 Rook 应用的安全策略(Pod Security Policy),用于限度 Pod 能够应用的平安特权和拜访权限,从而进步零碎的安全性。

这些清单文件是 Rook 装置和配置的重要组成部分,须要依据本人的须要和环境来批改和应用这些文件。在部署 Rook 集群时,通常须要应用这些清单文件来创立自定义资源定义、服务账户、角色和权限、存储集群等各种资源对象。

除了上述提到的清单文件,Rook 还蕴含一些其余的清单文件,这些文件蕴含了一些其余的配置和资源定义,例如:

  1. toolbox.yaml:该文件蕴含了 Rook 提供的调试和保护工具的清单,能够通过这些工具来查看集群的衰弱状态、执行各种操作和工作,例如修复 OSD、清理数据等。
  2. external-cluster.yaml:该文件蕴含了 Rook 与内部 Ceph 集群集成所需的配置信息和资源定义,能够应用该文件将 Rook 连贯到已有的 Ceph 集群上,从而利用 Rook 提供的治理和监控性能。
  3. rbd-storageclass.yaml:该文件蕴含了用于创立基于 RBD 卷的 Kubernetes 存储类的清单,能够应用该存储类来创立、治理 RBD 存储卷,以及定义 RBD 卷的各种属性和参数。
  4. csi-rbdplugin.yaml:该文件蕴含了 CSI RBD 插件的清单,用于在 Kubernetes 集群中为 RBD 卷提供 CSI 驱动程序,从而反对 Kubernetes 的 CSI 存储接口。

这些清单文件能够依据须要进行批改和应用,以实现不同的配置和性能需要。在应用 Rook 时,能够依据本人的理论需要抉择适宜本人的清单文件进行应用和部署。

部署思路

上面对在 K8S 集群中应用 Rook 来创立 Ceph 集群的步骤做一个概述:

  1. 部署 Rook Operator 在 Kubernetes 集群中部署 Rook Operator,能够通过应用 Helm Chart 或 kubectl 命令来实现。Rook Operator 是一个控制器,它能够在 Kubernetes 集群中治理 Ceph 集群的创立和配置。
  2. 创立 Ceph Cluster 创立一个名为 ceph-cluster.yaml 的清单文件,其中蕴含无关 Ceph 集群的配置信息,例如 Ceph mon、Ceph OSD、Ceph MGR 和 Ceph RGW 的数量、存储池配置等等。清单文件的格局应合乎 Kubernetes YAML 格局。
  3. 创立存储类 在 Kubernetes 集群中创立一个存储类,该存储类应用 Ceph 集群提供的存储。能够通过创立一个名为 ceph-storageclass.yaml 的清单文件,其中蕴含对于存储类的配置信息,例如存储池、存储类名称等等。清单文件的格局应合乎 Kubernetes YAML 格局。
  4. 创立块存储 应用存储类创立一个块存储,以供 Pod 应用。能够通过在 Pod 的卷申明中指定存储类来创立块存储。在应用块存储之前,须要先将其格式化并挂载到 Pod 中。

通过这些步骤,能够应用 Rook 在 Kubernetes 集群中创立一个 Ceph 集群,并将其作为 Kubernetes 存储类提供给 Pod 应用。Rook 提供了许多其余的性能和配置选项,能够依据须要进行批改和扩大。

前面会实战的三种存储类型

  • 块:创立一个块存储,以供一个 Pod 应用
  • 共享文件系统:创立要在多个 Pod 之间共享的文件系统
  • 对象:创立可在 K8S 集群外部或内部拜访的对象存储
  • 本文转载于 WX 公众号:不背锅运维(喜爱的盆友关注咱们):https://mp.weixin.qq.com/s/MhR64q_LARDV31x4gfS5ow
正文完
 0