快速上手Rook，入门云原生存储编排

快速上手 Rook，入门云原生存储编排

作者：为少 2021-08-04 13:19:28

存储

存储软件

云原生 Rook 是一个开源 cloud-native storage orchestrator(云原生存储编排器)，为各种存储解决方案提供平台、框架和支持，以与云原生环境进行原生集成。

按需网站开发可以根据自己的需求进行定制，成都网站设计、网站建设构思过程中功能建设理应排到主要部位公司成都网站设计、网站建设的运用实际效果公司网站制作网站建立与制做的实际意义

本文转载自微信公众号「黑客下午茶」，作者为少。转载本文请联系黑客下午茶公众号。

Rook 是一个开源 cloud-native storage orchestrator(云原生存储编排器)，为各种存储解决方案提供平台、框架和支持，以与云原生环境进行原生集成。

Rook 将存储软件转变为自我管理(self-managing)、自我扩展(self-scaling)和自我修复(self-healing)的存储服务。它通过自动化部署(automating deployment)、引导(bootstrapping)、配置(configuration)、供应(provisioning)、扩展(scaling)、升级(upgrading)、迁移(migration)、灾难恢复(disaster recovery)、监控(monitoring)和资源管理(resource management)来实现这一点。 Rook 使用底层云原生容器管理、调度和编排平台提供的设施来执行其职责。

Rook 利用扩展点深度集成到云原生环境中，并为调度、生命周期管理、资源管理、安全、监控和用户体验提供无缝体验。

Cassandra 快速入门

Cassandra 是一个高可用、容错、对等的 NoSQL 数据库，具有闪电般的性能和可调的一致性。它提供了无单点故障的大规模可扩展性。

Scylla 是在 C++ 中对 Cassandra 的接近硬件重写。它采用无共享架构，可实现真正的线性扩展和主要硬件优化，从而实现超低延迟和极高吞吐量。它是 Cassandra 的直接替代品，并使用相同的接口，因此 Rook 也支持它。

前提条件

运行 Rook Cassandra operator 需要 Kubernetes 集群。为了确保你有一个为 Rook 准备好的 Kubernetes 集群(Cassandra 不需要 flexvolume 插件)

部署 Cassandra Operator

首先使用以下命令部署 Rook Cassandra Operator：

  
 
 
   
  
  $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git
   
  
  cd rook/cluster/examples/kubernetes/cassandra
   
  
  kubectl apply -f operator.yaml

这将在命名空间 rook-cassandra-system 中安装 operator。您可以检查 operator 是否已启动并运行：

  
 
 
   
  
  kubectl -n rook-cassandra-system get pod

创建和初始化 Cassandra/Scylla 集群

现在 operator 正在运行，我们可以通过创建 clusters.cassandra.rook.io 资源的实例来创建 Cassandra/Scylla 集群的实例。该资源的某些值是可配置的，因此请随意浏览 cluster.yaml 并根据自己的喜好调整设置。

当你准备创建一个 Cassandra 集群时，只需运行:

  
 
 
   
  
  kubectl create -f cluster.yaml

我们可以使用以下命令验证是否已创建代表我们新 Cassandra 集群的 Kubernetes 对象。这很重要，因为它表明 Rook 已成功扩展 Kubernetes，使 Cassandra 集群成为 Kubernetes 云原生环境中的一等公民。

  
 
 
   
  
  kubectl -n rook-cassandra get clusters.cassandra.rook.io

要检查是否所有所需的成员都在运行，您应该从以下命令中看到与 cluster.yaml 中指定的成员数量相同的条目数：

  
 
 
   
  
  kubectl -n rook-cassandra get pod -l app=rook-cassandra

您还可以从其状态跟踪 Cassandra 集群的状态。要检查集群的当前状态，请运行：

  
 
 
   
  
  kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra

访问数据库

从 kubectl：

要在新集群中获取 cqlsh shell：

  
 
 
   
  
  kubectl exec -n rook-cassandra -it rook-cassandra-east-1-east-1a-0 -- cqlsh
   
  
  > DESCRIBE KEYSPACES;

从 Pod 内部：

当你创建一个新的集群时，Rook 会自动为客户端创建一个服务来访问集群。服务的名称遵循约定 -client。您可以通过运行以下命令在集群中查看此服务：

  
 
 
   
  
  kubectl -n rook-cassandra describe service rook-cassandra-client

在 Kubernetes 集群中运行的 Pod 可以使用此服务连接到 Cassandra。这是使用 Python Driver 的示例：

  
 
 
   
  
  from cassandra.cluster import Cluster
   
  
  
   
  
  cluster = Cluster(['rook-cassandra-client.rook-cassandra.svc.cluster.local'])
   
  
  session = cluster.connect()

Scale Up

operator 支持扩展机架(rack)以及添加新机架(rack)。要进行更改，您可以使用：

  
 
 
   
  
  kubectl edit clusters.cassandra.rook.io rook-cassandra

要扩展一个 rack，请将 rack 的 Spec.Members 字段更改为所需值。
要添加新 rack，请在 racks 列表中添加一个新 rack。请记住为新 rack 选择不同的 rack 名称。
编辑并保存 yaml 后，请检查集群的状态和事件以获取有关正发生情况的信息：

  
 
 
   
  
  kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra

Scale Down

operator 支持按比例缩小 rack。要进行更改，您可以使用：

  
 
 
   
  
  kubectl edit clusters.cassandra.rook.io rook-cassandra

要缩小一个 rack，请将 rack 的 Spec.Members 字段更改为所需值。
编辑并保存 yaml 后，请检查集群的状态和事件以获取有关正发生情况的信息：

  
 
 
   
  
  kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra

Clean Up

要清理与此演练相关的所有资源，您可以运行以下命令。

注意：这将破坏您的数据库并删除其所有相关数据。

  
 
 
   
  
  kubectl delete -f cluster.yaml
   
  
  
   
  
  kubectl delete -f operator.yaml

故障排除

如果集群没有出现，第一步是检查 operator 的日志：

  
 
 
   
  
  kubectl -n rook-cassandra-system logs -l app=rook-cassandra-operator

如果 operator 日志中一切正常，您还可以查看 Cassandra 实例之一的日志：

  
 
 
   
  
  kubectl -n rook-cassandra logs rook-cassandra-0

Cassandra 监控

要为 cassandra rack 启用 jmx_exporter，您应该在 CassandraCluster CRD 中为 rack 指定 jmxExporterConfigMapName 选项。

例如：

  
 
 
   
  
  apiVersion: cassandra.rook.io/v1alpha1
   
  
  kind: Cluster
   
  
  metadata:
   
  
    name: my-cassandra
   
  
    namespace: rook-cassandra
   
  
  spec:
   
  
    ...
   
  
    datacenter:
   
  
      name: my-datacenter
   
  
      racks:
   
  
      - name: my-rack
   
  
        members: 3
   
  
        jmxExporterConfigMapName: jmx-exporter-settings
   
  
        storage:
   
  
          volumeClaimTemplates:
   
  
          - metadata:
   
  
              name: rook-cassandra-data
   
  
            spec:
   
  
              storageClassName: my-storage-class
   
  
              resources:
   
  
                requests:
   
  
                  storage: 200Gi

获取所有指标的简单 config map 示例：

  
 
 
   
  
  apiVersion: v1
   
  
  kind: ConfigMap
   
  
  metadata:
   
  
    name: jmx-exporter-settings
   
  
    namespace: rook-cassandra
   
  
  data:
   
  
    jmx_exporter_config.yaml: |
   
  
      lowercaseOutputLabelNames: true
   
  
      lowercaseOutputName: true
   
  
      whitelistObjectNames: ["org.apache.cassandra.metrics:*"]

ConfigMap 的数据字段必须包含带有 jmx exporter 设置的 jmx_exporter_config.yaml key。

当 config map 更新时，Pod 没有自动重新加载机制。 configmap 更改后，您应该手动重新启动所有 rack pods：

  
 
 
   
  
  NAMESPACE=
   
  
  CLUSTER=
   
  
  RACKS=$(kubectl get sts -n ${NAMESPACE} -l "cassandra.rook.io/cluster=${CLUSTER}")
   
  
  echo ${RACKS} | xargs -n1 kubectl rollout restart -n ${NAMESPACE}

Ceph Storage 快速入门

本指南将引导您完成 Ceph 集群的基本设置，并使您能够使用集群中运行的其他 pod 中的块、对象和文件存储。

最低版本

Rook 支持 Kubernetes v1.11 或更高版本。

Important 如果您使用的是 K8s 1.15 或更早版本，则需要创建不同版本的 Rook CRD。创建在示例清单的 pre-k8s-1.16 子文件夹中找到的 crds.yaml。

前提条件

为确保您拥有可用于 Rook 的 Kubernetes 集群。

为了配置 Ceph 存储集群，至少需要以下本地存储选项之一：

原始设备(无分区或格式化文件系统)
- 这需要在主机上安装 lvm2。为了避免这种依赖性，您可以在磁盘上创建一个完整的磁盘分区(见下文)
原始分区(无格式化文件系统)
block 模式下存储类中可用的持久卷

您可以使用以下命令确认您的分区或设备是否已格式化文件系统。

  
 
 
   
  
  lsblk -f

  
 
 
   
  
  NAME                  FSTYPE      LABEL UUID                                   MOUNTPOINT
   
  
  vda
   
  
  └─vda1                LVM2_member       >eSO50t-GkUV-YKTH-WsGq-hNJY-eKNf-3i07IB
   
  
   ├─ubuntu--vg-root   ext4              c2366f76-6e21-4f10-a8f3-6776212e2fe4   /
   
  
   └─ubuntu--vg-swap_1 swap              9492a3dc-ad75-47cd-9596-678e8cf17ff9   [SWAP]
   
  
  vdb

如果 FSTYPE 字段不为空，则在相应设备的顶部有一个文件系统。在这种情况下，您可以将 vdb 用于 Ceph，而不能使用 vda 及其分区。

TL;DR

如果幸运的话，可以使用以下 kubectl 命令和示例 yaml 文件创建一个简单的 Rook 集群。

  
 
 
   
  
  $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git
   
  
  cd rook/cluster/examples/kubernetes/ceph
   
  
  kubectl create -f crds.yaml -f common.yaml -f operator.yaml
   
  
  kubectl create -f cluster.yaml

集群环境

Rook 文档侧重于在生产环境中启动 Rook。还提供了一些示例来放宽测试环境的一些设置。在本指南后面创建集群时，请考虑以下示例集群清单：

cluster.yaml: 在裸机上运行的生产集群的集群设置。至少需要三个工作节点。
cluster-on-pvc.yaml: 在动态云环境中运行的生产集群的集群设置。
cluster-test.yaml: 测试环境的集群设置，例如 minikube。

部署 Rook Operator

第一步是部署 Rook operator。检查您是否正在使用与您的 Rook 版本相对应的示例 yaml 文件。

  
 
 
   
  
  cd cluster/examples/kubernetes/ceph
   
  
  kubectl create -f crds.yaml -f common.yaml -f operator.yaml
   
  
  
   
  
  # verify the rook-ceph-operator is in the `Running` state before proceeding
   
  
  kubectl -n rook-ceph get pod

在生产中启动 Operator 之前，您可能需要考虑一些设置：

如果您使用 kubernetes v1.15 或更早版本，则需要在此处创建 CRD，在 /cluster/examples/kubernetes/ceph/pre-k8s-1.16/crd.yaml。 CustomResourceDefinition 的 apiextension v1beta1 版本在 Kubernetes v1.16 中已弃用。
考虑是否要启用默认禁用的某些 Rook 功能。有关这些和其他高级设置，请参阅 operator.yaml。

设备发现：如果启用了 ROOK_ENABLE_DISCOVERY_DAEMON 设置，Rook 将监视要配置的新设备，常用于裸机集群。
Flex driver：Flex driver 已被弃用，取而代之的是 CSI driver，但仍可通过 ROOK_ENABLE_FLEX_DRIVER 设置启用。
Node affinity and tolerations(节点关联和容忍度)：默认情况下，CSI driver 将在集群中的任何节点上运行。要配置 CSI driver affinity，可以使用多种设置。

创建 Rook Ceph 集群

现在 Rook operator 正在运行，我们可以创建 Ceph 集群。为了使集群在重新启动后继续存在，请确保设置对主机有效的 dataDirHostPath 属性。

创建集群：

  
 
 
   
  
  kubectl create -f cluster.yaml

使用 kubectl 列出 rook-ceph 命名空间中的 pod。一旦它们全部运行，您应该能够看到以下 pod。 osd pod 的数量将取决于集群中的节点数量和配置的设备数量。如果没有修改上面的 cluster.yaml，预计每个节点会创建一个 OSD。CSI、rook-ceph-agent(flex driver)和 rook-discover pod 也是可选的，具体取决于您的设置。

  
 
 
   
  
  kubectl -n rook-ceph get pod

  
 
 
   
  
  NAME                                                 READY   STATUS      RESTARTS   AGE
   
  
  csi-cephfsplugin-provisioner-d77bb49c6-n5tgs         5/5     Running     0          140s
   
  
  csi-cephfsplugin-provisioner-d77bb49c6-v9rvn         5/5     Running     0          140s
   
  
  csi-cephfsplugin-rthrp                               3/3     Running     0          140s
   
  
  csi-rbdplugin-hbsm7                                  3/3     Running     0          140s
   
  
  csi-rbdplugin-provisioner-5b5cd64fd-nvk6c            6/6     Running     0          140s
   
  
  csi-rbdplugin-provisioner-5b5cd64fd-q7bxl            6/6     Running     0          140s
   
  
  rook-ceph-crashcollector-minikube-5b57b7c5d4-hfldl   1/1     Running     0          105s
   
  
  rook-ceph-mgr-a-64cd7cdf54-j8b5p                     1/1     Running     0          77s
   
  
  rook-ceph-mon-a-694bb7987d-fp9w7                     1/1     Running     0          105s
   
  
  rook-ceph-mon-b-856fdd5cb9-5h2qk                     1/1     Running     0          94s
   
  
  rook-ceph-mon-c-57545897fc-j576h                     1/1     Running     0          85s
   
  
  rook-ceph-operator-85f5b946bd-s8grz                  1/1     Running     0          92m
   
  
  rook-ceph-osd-0-6bb747b6c5-lnvb6                     1/1     Running     0          23s
   
  
  rook-ceph-osd-1-7f67f9646d-44p7v                     1/1     Running     0          24s
   
  
  rook-ceph-osd-2-6cd4b776ff-v4d68                     1/1     Running     0          25s
   
  
  rook-ceph-osd-prepare-node1-vx2rz                    0/2     Completed   0          60s
   
  
  rook-ceph-osd-prepare-node2-ab3fd                    0/2     Completed   0          60s
   
  
  rook-ceph-osd-prepare-node3-w4xyz                    0/2     Completed   0          60s

要验证集群是否处于健康状态，请连接到 Rook toolbox 并运行 ceph status 命令。

所有 mons 都应达到法定人数
mgr 应该是活跃的
至少有一个 OSD 处于活动状态
如果运行状况不是 HEALTH_OK，则应调查警告或错误

  
 
 
   
  
  ceph status

  
 
 
   
  
  cluster:
   
  
    id:     a0452c76-30d9-4c1a-a948-5d8405f19a7c
   
  
    health: HEALTH_OK
   
  
  
   
  
  services:
   
  
    mon: 3 daemons, quorum a,b,c (age 3m)
   
  
    mgr: a(active, since 2m)
   
  
    osd: 3 osds: 3 up (since 1m), 3 in (since 1m)
   
  
  ..

Storage

有关 Rook 公开的三种存储类型的演练，请参阅以下指南：

Block：创建要由 Pod 使用的块(block)存储
Object：创建可在 Kubernetes 集群内部或外部访问的对象存储
Shared Filesystem：创建要在多个 pod 之间共享的文件系统

Ceph 仪表板

Ceph 有一个仪表板，您可以在其中查看集群的状态。

工具

我们创建了一个 toolbox 容器，其中包含用于调试和排除 Rook 集群故障的全套 Ceph 客户端。

监控

每个 Rook 集群都有一些内置的指标收集器(collectors)/导出器(exporters)，用于使用 Prometheus 进行监控。

销毁

完成测试集群后，请参阅这些说明以清理集群。

网络文件系统 (NFS)

NFS 允许远程主机通过网络挂载文件系统并与这些文件系统交互，就像它们是在本地挂载一样。这使系统管理员能够将资源整合到网络上的中央服务器上。

前提条件
运行 Rook NFS operator 需要 Kubernetes 集群。

要暴露的卷，需要通过 PVC 附加到 NFS server pod。

可以被附加(attached)和导出(exported)任何类型的 PVC，例如 Host Path、AWS Elastic Block Store、GCP Persistent Disk、CephFS、Ceph RBD 等。这些卷的限制(limitations)在它们由 NFS 共享时也适用。您可以在 Kubernetes docs 中进一步了解这些卷的详细信息和限制。3. NFS client packages 必须安装在 Kubernetes 可能运行挂载 NFS 的 pod 的所有节点上。在 CentOS 节点上安装 nfs-utils 或在 Ubuntu 节点上安装 nfs-common。

部署 NFS Operator

首先使用以下命令部署 Rook NFS operator：

  
 
 
   
  
  $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git
   
  
  cd rook/cluster/examples/kubernetes/nfs
   
  
  kubectl create -f common.yaml
   
  
  kubectl create -f operator.yaml

您可以检查 operator 是否已启动并运行：

  
 
 
   
  
  kubectl -n rook-nfs-system get pod

NAME READY STATUS RESTARTS AGE

  
 
 
   
  
  NAME                                    READY   STATUS    RESTARTS   AGE
   
  
  rook-nfs-operator-879f5bf8b-gnwht       1/1     Running   0          29m

部署 NFS Admission Webhook (可选)

Admission webhooks 是 HTTP 回调，用于接收对 API 服务器的准入请求。两种类型的 admission webhooks 是验证 admission webhook 和 mutating admission webhook。 NFS Operator 支持验证 admission webhook，它在存储到 etcd(持久化)之前验证发送到 API server 的 NFSServer 对象。

要在 NFS 上启用 admission webhook，例如验证 admission webhook，您需要执行以下操作：

首先，确保安装了 cert-manager。如果尚未安装，您可以按照 cert-manager 安装文档中的说明进行安装。或者，您可以简单地运行以下单个命令：

  
 
 
   
  
  kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.yaml

这将轻松安装最新版本 (v0.15.1) 的 cert-manager。完成后，确保 cert-manager 组件部署正确并处于 Running 状态：

  
 
 
   
  
  kubectl get -n cert-manager pod

  
 
 
   
  
  NAME                                      READY   STATUS    RESTARTS   AGE
   
  
  cert-manager-7747db9d88-jmw2f             1/1     Running   0          2m1s
   
  
  cert-manager-cainjector-87c85c6ff-dhtl8   1/1     Running   0          2m1s
   
  
  cert-manager-webhook-64dc9fff44-5g565     1/1     Running   0          2m1s

一旦 cert-manager 运行，您现在可以部署 NFS webhook：

  
 
 
   
  
  kubectl create -f webhook.yaml

验证 webhook 已启动并正在运行：

  
 
 
   
  
  kubectl -n rook-nfs-system get pod

  
 
 
   
  
  NAME                                    READY   STATUS    RESTARTS   AGE
   
  
  rook-nfs-operator-78d86bf969-k7lqp      1/1     Running   0          102s
   
  
  rook-nfs-webhook-74749cbd46-6jw2w       1/1     Running   0          102s

创建 Openshift 安全上下文约束(可选)

在 OpenShift 集群上，我们需要创建一些额外的安全上下文约束。如果您未在 OpenShift 中运行，则可以跳过此部分并转到下一部分。

要为 nfs-server pod 创建安全上下文约束，我们可以使用以下 yaml，它也可以在 /cluster/examples/kubernetes/nfs 下的 scc.yaml 中找到。

注意：旧版本的 OpenShift 可能需要 apiVersion: v1

  
 
 
   
  
  kind: SecurityContextConstraints
   
  
  apiVersion: security.openshift.io/v1
   
  
  metadata:
   
  
    name: rook-nfs
   
  
  allowHostDirVolumePlugin: true
   
  
  allowHostIPC: false
   
  
  allowHostNetwork: false
   
  
  allowHostPID: false
   
  
  allowHostPorts: false
   
  
  allowPrivilegedContainer: false
   
  
  allowedCapabilities:
   
  
  - SYS_ADMIN
   
  
  - DAC_READ_SEARCH
   
  
  defaultAddCapabilities: null
   
  
  fsGroup:
   
  
    type: MustRunAs
   
  
  priority: null
   
  
  readOnlyRootFilesystem: false
   
  
  requiredDropCapabilities:
   
  
  - KILL
   
  
  - MKNOD
   
  
  - SYS_CHROOT
   
  
  runAsUser:
   
  
    type: RunAsAny
   
  
  seLinuxContext:
   
  
    type: MustRunAs
   
  
  supplementalGroups:
   
  
    type: RunAsAny
   
  
  volumes:
   
  
  - configMap
   
  
  - downwardAPI
   
  
  - emptyDir
   
  
  - persistentVolumeClaim
   
  
  - secret
   
  
  users:
   
  
    - system:serviceaccount:rook-nfs:rook-nfs-server

您可以使用以下命令创建 scc：

  
 
 
   
  
  oc create -f scc.yaml

创建 Pod 安全策略(推荐)

我们建议您也创建 Pod 安全策略

  
 
 
   
  
  apiVersion: policy/v1beta1
   
  
  kind: PodSecurityPolicy
   
  
  metadata:
   
  
    name: rook-nfs-policy
   
  
  spec:
   
  
    privileged: true
   
  
    fsGroup:
   
  
      rule: RunAsAny
   
  
    allowedCapabilities:
   
  
    - DAC_READ_SEARCH
   
  
    - SYS_RESOURCE
   
  
    runAsUser:
   
  
      rule: RunAsAny
   
  
    seLinux:
   
  
      rule: RunAsAny
   
  
    supplementalGroups:
   
  
      rule: RunAsAny
   
  
    volumes:
   
  
    - configMap
   
  
    - downwardAPI
   
  
    - emptyDir
   
  
    - persistentVolumeClaim
   
  
    - secret
   
  
    - hostPath

使用名称 psp.yaml 保存此文件并使用以下命令创建：

  
 
 
   
  
  kubectl create -f psp.yaml

创建和初始化 NFS 服务器

现在 operator 正在运行，我们可以通过创建 nfsservers.nfs.rook.io 资源的实例来创建 NFS 服务器的实例。NFS server resource 的各种字段和选项可用于配置要导出的服务器及其卷。

在我们创建 NFS Server 之前，我们需要创建 ServiceAccount 和 RBAC 规则

  
 
 
   
  
  ---
   
  
  apiVersion: v1
   
  
  kind: Namespace
   
  
  metadata:
   
  
    name:  rook-nfs
   
  
  ---
   
  
  apiVersion: v1
   
  
  kind: ServiceAccount
   
  
  metadata:
   
  
    name: rook-nfs-server
   
  
    namespace: rook-nfs
   
  
  ---
   
  
  kind: ClusterRole
   
  
  apiVersion: rbac.authorization.k8s.io/v1
   
  
  metadata:
   
  
    name: rook-nfs-provisioner-runner
   
  
  rules:
   
  
    - apiGroups: [""]
   
  
      resources: ["persistentvolumes"]
   
  
      verbs: ["get", "list", "watch", "create", "delete"]
   
  
    - apiGroups: [""]
   
  
      resources: ["persistentvolumeclaims"]
   
  
      verbs: ["get", "list", "watch", "update"]
   
  
    - apiGroups: ["storage.k8s.io"]
   
  
      resources: ["storageclasses"]
   
  
      verbs: ["get", "list", "watch"]
   
  
    - apiGroups: [""]
   
  
      resources: ["events"]
   
  
      verbs: ["create", "update", "patch"]
   
  
    - apiGroups: [""]
   
  
      resources: ["services", "endpoints"]
   
  
      verbs: ["get"]
   
  
    - apiGroups: ["policy"]
   
  
      resources: ["podsecuritypolicies"]
   
  
      resourceNames: ["rook-nfs-policy"]
   
  
      verbs: ["use"]
   
  
    - apiGroups: [""]
   
  
      resources: ["endpoints"]
   
  
      verbs: ["get", "list", "watch", "create", "update", "patch"]
   
  
    - apiGroups:
   
  
      - nfs.rook.io
   
  
      resources:
   
  
      - "*"
   
  
      verbs:
   
  
      - "*"
   
  
  ---
   
  
  kind: ClusterRoleBinding
   
  
  apiVersion: rbac.authorization.k8s.io/v1
   
  
  metadata:
   
  
    name: rook-nfs-provisioner-runner
   
  
  subjects:
   
  
    - kind: ServiceAccount
   
  
      name: rook-nfs-server
   
  
       # replace with namespace where provisioner is deployed
   
  
      namespace: rook-nfs
   
  
  roleRef:
   
  
    kind: ClusterRole
   
  
    name: rook-nfs-provisioner-runner
   
  
    apiGroup: rbac.authorization.k8s.io

使用名称 rbac.yaml 保存此文件并使用以下命令创建：

  
 
 
   
  
  kubectl create -f rbac.yaml

本指南有 3 个主要示例，用于演示使用 NFS 服务器导出卷(exporting volumes)：

默认 StorageClass 示例
XFS StorageClass 示例
Rook Ceph volume 示例

默认 StorageClass 示例

第一个示例将逐步创建一个 NFS server 实例，该实例导出由您碰巧运行的环境的默认 StorageClass 支持的存储。在某些环境中，这可能是主机路径(host path)，在其他环境中，它可能是云提供商虚拟磁盘(cloud provider virtual disk)。无论哪种方式，此示例都需要存在默认的 StorageClass。

首先将以下 NFS CRD 实例定义保存到名为 nfs.yaml 的文件中：

  
 
 
   
  
  ---
   
  
  # A default storageclass must be present
   
  
  apiVersion: v1
   
  
  kind: PersistentVolumeClaim
   
  
  metadata:
   
  
    name: nfs-default-claim
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    accessModes:
   
  
    - ReadWriteMany
   
  
    resources:
   
  
      requests:
   
  
        storage: 1Gi
   
  
  ---
   
  
  apiVersion: nfs.rook.io/v1alpha1
   
  
  kind: NFSServer
   
  
  metadata:
   
  
    name: rook-nfs
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    replicas: 1
   
  
    exports:
   
  
    - name: share1
   
  
      server:
   
  
        accessMode: ReadWrite
   
  
        squash: "none"
   
  
      # A Persistent Volume Claim must be created before creating NFS CRD instance.
   
  
      persistentVolumeClaim:
   
  
        claimName: nfs-default-claim
   
  
    # A key/value list of annotations
   
  
    annotations:
   
  
      rook: nfs

保存了 nfs.yaml 文件后，现在创建 NFS server，如下所示：

  
 
 
   
  
  kubectl create -f nfs.yaml

XFS StorageClass 示例

Rook NFS 通过 xfs_quota 支持磁盘配额。因此，如果您需要为卷指定磁盘配额，则可以按照此示例进行操作。

在这个例子中，我们将使用一个带有 prjquota 选项的作为 xfs 挂载的底层卷。在创建底层卷(underlying volume)之前，您需要使用 xfs 文件系统和 prjquota mountOptions 创建 StorageClass。Kubernetes 的许多分布式存储提供商都支持 xfs 文件系统。通常通过在 storageClass 参数中定义 fsType: xfs 或 fs: xfs。但实际上如何指定 storage-class 文件系统类型取决于它自己的存储提供者。您可以查看 https://kubernetes.io/docs/concepts/storage/storage-classes/ 了解更多详情。

这是 GCE PD 和 AWS EBS 的示例 StorageClass

GCE PD

  
 
 
   
  
  apiVersion: storage.k8s.io/v1
   
  
  kind: StorageClass
   
  
  metadata:
   
  
    name: standard-xfs
   
  
  parameters:
   
  
    type: pd-standard
   
  
    fsType: xfs
   
  
  mountOptions:
   
  
    - prjquota
   
  
  provisioner: kubernetes.io/gce-pd
   
  
  reclaimPolicy: Delete
   
  
  volumeBindingMode: Immediate
   
  
  allowVolumeExpansion: true

AWS EBS

  
 
 
   
  
  apiVersion: storage.k8s.io/v1
   
  
  kind: StorageClass
   
  
  metadata:
   
  
    name: standard-xfs
   
  
  provisioner: kubernetes.io/aws-ebs
   
  
  parameters:
   
  
    type: io1
   
  
    iopsPerGB: "10"
   
  
    fsType: xfs
   
  
  mountOptions:
   
  
    - prjquota
   
  
  reclaimPolicy: Delete
   
  
  volumeBindingMode: Immediate

一旦您已经拥有带有 xfs 文件系统和 prjquota mountOptions 的 StorageClass，您就可以使用以下示例创建 NFS server 实例。

  
 
 
   
  
  ---
   
  
  # A storage class with name standard-xfs must be present.
   
  
  # The storage class must be has xfs filesystem type  and prjquota mountOptions.
   
  
  apiVersion: v1
   
  
  kind: PersistentVolumeClaim
   
  
  metadata:
   
  
    name: nfs-xfs-claim
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    storageClassName: "standard-xfs"
   
  
    accessModes:
   
  
    - ReadWriteOnce
   
  
    resources:
   
  
      requests:
   
  
        storage: 1Gi
   
  
  ---
   
  
  apiVersion: nfs.rook.io/v1alpha1
   
  
  kind: NFSServer
   
  
  metadata:
   
  
    name: rook-nfs
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    replicas: 1
   
  
    exports:
   
  
    - name: share1
   
  
      server:
   
  
        accessMode: ReadWrite
   
  
        squash: "none"
   
  
      # A Persistent Volume Claim must be created before creating NFS CRD instance.
   
  
      persistentVolumeClaim:
   
  
        claimName: nfs-xfs-claim
   
  
    # A key/value list of annotations
   
  
    annotations:
   
  
      rook: nfs

将此 PVC 和 NFS Server 实例保存为 nfs-xfs.yaml 并使用以下命令创建。

  
 
 
   
  
  kubectl create -f nfs-xfs.yaml

Rook Ceph volume 示例

在这个替代示例中，我们将使用不同的基础卷(underlying volume)作为 NFS server 的 export。这些步骤将引导我们导出 Ceph RBD block volume，以便客户端可以通过网络访问它。

在 Rook Ceph 集群启动并运行后，我们可以继续创建 NFS server。

将此 PVC 和 NFS 服务器实例保存为 nfs-ceph.yaml：

  
 
 
   
  
  ---
   
  
  # A rook ceph cluster must be running
   
  
  # Create a rook ceph cluster using examples in rook/cluster/examples/kubernetes/ceph
   
  
  # Refer to https://rook.io/docs/rook/master/ceph-quickstart.html for a quick rook cluster setup
   
  
  apiVersion: v1
   
  
  kind: PersistentVolumeClaim
   
  
  metadata:
   
  
    name: nfs-ceph-claim
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    storageClassName: rook-ceph-block
   
  
    accessModes:
   
  
    - ReadWriteMany
   
  
    resources:
   
  
      requests:
   
  
        storage: 2Gi
   
  
  ---
   
  
  apiVersion: nfs.rook.io/v1alpha1
   
  
  kind: NFSServer
   
  
  metadata:
   
  
    name: rook-nfs
   
  
    namespace: rook-nfs
   
  
  spec:
   
  
    replicas: 1
   
  
    exports:
   
  
    - name: share1
   
  
      server:
   
  
        accessMode: ReadWrite
   
  
        squash: "none"
   
  
      # A Persistent Volume Claim must be created before creating NFS CRD instance.
   
  
      # Create a Ceph cluster for using this example
   
  
      # Create a ceph PVC after creating the rook ceph cluster using ceph-pvc.yaml
   
  
      persistentVolumeClaim:
   
  
        claimName: nfs-ceph-claim
   
  
    # A key/value list of annotations
   
  
    annotations:
   
  
      rook: nfs

创建您保存在 nfs-ceph.yaml 中的 NFS server 实例：

  
 
 
   
  
  kubectl create -f nfs-ceph.yaml

验证 NFS Server

我们可以使用以下命令验证是否已创建代表我们的新 NFS server 及其导出的 Kubernetes 对象。

  
 
 
   
  
  kubectl -n rook-nfs get nfsservers.nfs.rook.io

  
 
 
   
  
  NAME       AGE   STATE
   
  
  rook-nfs   32s   Running

验证 NFS server pod 是否已启动并正在运行：

  
 
 
   
  
  kubectl -n rook-nfs get pod -l app=rook-nfs

  
 
 
   
  
  NAME         READY     STATUS    RESTARTS   AGE
   
  
  rook-nfs-0   1/1       Running   0          2m

如果 NFS server pod 处于 Running 状态，那么我们已经成功创建了一个暴露的 NFS 共享，客户端可以开始通过网络访问。

访问 Export

从 Rook 版本 v1.0 开始，Rook 支持 NFS 的动态配置(dynamic provisioning)。此示例将展示如何将动态配置功能用于 nfs。

部署 NFS Operator 和 NFSServer 实例后。必须创建类似于以下示例的 storageclass 来动态配置卷。

  
 
 
   
  
  apiVersion: storage.k8s.io/v1
   
  
  kind: StorageClass
   
  
  metadata:
   
  
    labels:
   
  
      app: rook-nfs
   
  
    name: rook-nfs-share1
   
  
  parameters:
   
  
    exportName: share1
   
  
    nfsServerName: rook-nfs
   
  
    nfsServerNamespace: rook-nfs
   
  
  provisioner: nfs.rook.io/rook-nfs-provisioner
   
  
  reclaimPolicy: Delete
   
  
  volumeBindingMode: Immediate

您可以将其另存为文件，例如：名为 sc.yaml 然后使用以下命令创建 storageclass。

  
 
 
   
  
  kubectl create -f sc.yaml

注意：StorageClass 需要传递以下 3 个参数。

exportName: 它告诉供应商(provisioner)使用哪个导出来供应卷。
nfsServerName: 它是 NFSServer 实例的名称。
nfsServerNamespace: NFSServer 实例运行所在的命名空间。

创建上述 storageclass 后，您可以创建引用 storageclass 的 PV claim，如下面给出的示例所示。

  
 
 
   
  
  apiVersion: v1
   
  
  kind: PersistentVolumeClaim
   
  
  metadata:
   
  
    name: rook-nfs-pv-claim
   
  
  spec:
   
  
    storageClassName: "rook-nfs-share1"
   
  
    accessModes:
   
  
      - ReadWriteMany
   
  
    resources:
   
  
      requests:
   
  
        storage: 1Mi

您也可以将其保存为文件，例如：名为 pvc.yaml 然后使用以下命令创建 PV claim。

  
 
 
   
  
  kubectl create -f pvc.yaml

消费 Export

现在我们可以通过创建一个示例 web server app 来使用刚刚创建的 PV，该应用程序使用上述 PersistentVolumeClaim 声明导出的卷。有 2 个 pod 构成此示例：

将读取和显示 NFS 共享内容的 Web server pod

将随机数据写入 NFS 共享的 writer pod，以便网站不断更新

从 cluster/examples/kubernetes/nfs 文件夹启动 busybox pod(writer)和 web server：

  
 
 
   
  
  kubectl create -f busybox-rc.yaml
   
  
  kubectl create -f web-rc.yaml

让我们确认预期的 busybox writer pod 和 Web server pod 都已启动并处于 Running 状态：

  
 
 
   
  
  kubectl get pod -l app=nfs-demo

为了能够通过网络访问 Web server，让我们为它创建一个 service：

  
 
 
   
  
  kubectl create -f web-service.yaml

然后我们可以使用我们之前启动的 busybox writer pod 来检查 nginx

本文题目：快速上手Rook，入门云原生存储编排
文章起源：http://www.csdahua.cn/qtweb/news17/499667.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：快上网

成都快上网为您推荐相关内容