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

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

[[415352]]

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

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:

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

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

  1. kubectl -n rook-cassandra-system get pod 

创建和初始化 Cassandra/Scylla 集群

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

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

  1. kubectl create -f cluster.yaml 

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

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

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

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

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

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

访问数据库

  • 从 kubectl:

要在新集群中获取 cqlsh shell:

  1. kubectl exec -n rook-cassandra -it rook-cassandra-east-1-east-1a-0 -- cqlsh 
  2. > DESCRIBE KEYSPACES; 
  • 从 Pod 内部:

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

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

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

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

Scale Up

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

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

Scale Down

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

  1. kubectl edit clusters.cassandra.rook.io rook-cassandra 
  • 要缩小一个 rack,请将 rack 的 Spec.Members 字段更改为所需值。
  • 编辑并保存 yaml 后,请检查集群的状态和事件以获取有关正发生情况的信息:
  1. kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra 

Clean Up

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

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

  1. kubectl delete -f cluster.yaml 
  2.  
  3. kubectl delete -f operator.yaml 

故障排除

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

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

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

  1. kubectl -n rook-cassandra logs rook-cassandra-0 

Cassandra 监控

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

例如:

  1. apiVersion: cassandra.rook.io/v1alpha1 
  2. kind: Cluster 
  3. metadata: 
  4.   name: my-cassandra 
  5.   namespace: rook-cassandra 
  6. spec: 
  7.   ... 
  8.   datacenter: 
  9.     name: my-datacenter 
  10.     racks: 
  11.     - name: my-rack 
  12.       members: 3 
  13.       jmxExporterConfigMapName: jmx-exporter-settings 
  14.       storage: 
  15.         volumeClaimTemplates: 
  16.         - metadata: 
  17.             name: rook-cassandra-data 
  18.           spec: 
  19.             storageClassName: my-storage-class 
  20.             resources: 
  21.               requests: 
  22.                 storage: 200Gi 

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

  1. apiVersion: v1 
  2. kind: ConfigMap 
  3. metadata: 
  4.   name: jmx-exporter-settings 
  5.   namespace: rook-cassandra 
  6. data: 
  7.   jmx_exporter_config.yaml: | 
  8.     lowercaseOutputLabelNames: true 
  9.     lowercaseOutputName: true 
  10.     whitelistObjectNames: ["org.apache.cassandra.metrics:*"

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

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

  1. NAMESPACE=<namespace> 
  2. CLUSTER=<cluster_name> 
  3. RACKS=$(kubectl get sts -n ${NAMESPACE} -l "cassandra.rook.io/cluster=${CLUSTER}"
  4. 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 模式下存储类中可用的持久卷

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

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

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

TL;DR

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

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

集群环境

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

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

部署 Rook Operator

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

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

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

  1. 如果您使用 kubernetes v1.15 或更早版本,则需要在此处创建 CRD,在 /cluster/examples/kubernetes/ceph/pre-k8s-1.16/crd.yaml。 CustomResourceDefinition 的 apiextension v1beta1 版本在 Kubernetes v1.16 中已弃用。
  2. 考虑是否要启用默认禁用的某些 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 属性。

创建集群:

  1. kubectl create -f cluster.yaml 

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

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

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

  • 所有 mons 都应达到法定人数
  • mgr 应该是活跃的
  • 至少有一个 OSD 处于活动状态
  • 如果运行状况不是 HEALTH_OK,则应调查警告或错误
  1. ceph status 
  1. cluster: 
  2.   id:     a0452c76-30d9-4c1a-a948-5d8405f19a7c 
  3.   health: HEALTH_OK 
  4.  
  5. services: 
  6.   mon: 3 daemons, quorum a,b,c (age 3m) 
  7.   mgr: a(active, since 2m) 
  8.   osd: 3 osds: 3 up (since 1m), 3 in (since 1m) 
  9. .. 

Storage

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

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

Ceph 仪表板

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

工具

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

监控

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

销毁

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

网络文件系统 (NFS)

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

  1. 前提条件
  2. 运行 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:

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

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

  1. kubectl -n rook-nfs-system get pod 

NAME READY STATUS RESTARTS AGE

  1. NAME                                    READY   STATUS    RESTARTS   AGE 
  2. 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 安装文档中的说明进行安装。或者,您可以简单地运行以下单个命令:

  1. 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 状态:

  1. kubectl get -n cert-manager pod 
  1. NAME                                      READY   STATUS    RESTARTS   AGE 
  2. cert-manager-7747db9d88-jmw2f             1/1     Running   0          2m1s 
  3. cert-manager-cainjector-87c85c6ff-dhtl8   1/1     Running   0          2m1s 
  4. cert-manager-webhook-64dc9fff44-5g565     1/1     Running   0          2m1s 

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

  1. kubectl create -f webhook.yaml 

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

  1. kubectl -n rook-nfs-system get pod 
  1. NAME                                    READY   STATUS    RESTARTS   AGE 
  2. rook-nfs-operator-78d86bf969-k7lqp      1/1     Running   0          102s 
  3. 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

  1. kind: SecurityContextConstraints 
  2. apiVersion: security.openshift.io/v1 
  3. metadata: 
  4.   name: rook-nfs 
  5. allowHostDirVolumePlugin: true 
  6. allowHostIPC: false 
  7. allowHostNetwork: false 
  8. allowHostPID: false 
  9. allowHostPorts: false 
  10. allowPrivilegedContainer: false 
  11. allowedCapabilities: 
  12. - SYS_ADMIN 
  13. - DAC_READ_SEARCH 
  14. defaultAddCapabilities: null 
  15. fsGroup: 
  16.   type: MustRunAs 
  17. priority: null 
  18. readOnlyRootFilesystem: false 
  19. requiredDropCapabilities: 
  20. - KILL 
  21. - MKNOD 
  22. - SYS_CHROOT 
  23. runAsUser: 
  24.   type: RunAsAny 
  25. seLinuxContext: 
  26.   type: MustRunAs 
  27. supplementalGroups: 
  28.   type: RunAsAny 
  29. volumes: 
  30. - configMap 
  31. - downwardAPI 
  32. - emptyDir 
  33. - persistentVolumeClaim 
  34. - secret 
  35. users: 
  36.   - system:serviceaccount:rook-nfs:rook-nfs-server 

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

  1. oc create -f scc.yaml 

创建 Pod 安全策略(推荐)

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

  1. apiVersion: policy/v1beta1 
  2. kind: PodSecurityPolicy 
  3. metadata: 
  4.   name: rook-nfs-policy 
  5. spec: 
  6.   privileged: true 
  7.   fsGroup: 
  8.     rule: RunAsAny 
  9.   allowedCapabilities: 
  10.   - DAC_READ_SEARCH 
  11.   - SYS_RESOURCE 
  12.   runAsUser: 
  13.     rule: RunAsAny 
  14.   seLinux: 
  15.     rule: RunAsAny 
  16.   supplementalGroups: 
  17.     rule: RunAsAny 
  18.   volumes: 
  19.   - configMap 
  20.   - downwardAPI 
  21.   - emptyDir 
  22.   - persistentVolumeClaim 
  23.   - secret 
  24.   - hostPath 

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

  1. kubectl create -f psp.yaml 

创建和初始化 NFS 服务器

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

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

  1. --- 
  2. apiVersion: v1 
  3. kind: Namespace 
  4. metadata: 
  5.   name:  rook-nfs 
  6. --- 
  7. apiVersion: v1 
  8. kind: ServiceAccount 
  9. metadata: 
  10.   name: rook-nfs-server 
  11.   namespace: rook-nfs 
  12. --- 
  13. kind: ClusterRole 
  14. apiVersion: rbac.authorization.k8s.io/v1 
  15. metadata: 
  16.   name: rook-nfs-provisioner-runner 
  17. rules: 
  18.   - apiGroups: [""
  19.     resources: ["persistentvolumes"
  20.     verbs: ["get""list""watch""create""delete"
  21.   - apiGroups: [""
  22.     resources: ["persistentvolumeclaims"
  23.     verbs: ["get""list""watch""update"
  24.   - apiGroups: ["storage.k8s.io"
  25.     resources: ["storageclasses"
  26.     verbs: ["get""list""watch"
  27.   - apiGroups: [""
  28.     resources: ["events"
  29.     verbs: ["create""update""patch"
  30.   - apiGroups: [""
  31.     resources: ["services""endpoints"
  32.     verbs: ["get"
  33.   - apiGroups: ["policy"
  34.     resources: ["podsecuritypolicies"
  35.     resourceNames: ["rook-nfs-policy"
  36.     verbs: ["use"
  37.   - apiGroups: [""
  38.     resources: ["endpoints"
  39.     verbs: ["get""list""watch""create""update""patch"
  40.   - apiGroups: 
  41.     - nfs.rook.io 
  42.     resources: 
  43.     - "*" 
  44.     verbs: 
  45.     - "*" 
  46. --- 
  47. kind: ClusterRoleBinding 
  48. apiVersion: rbac.authorization.k8s.io/v1 
  49. metadata: 
  50.   name: rook-nfs-provisioner-runner 
  51. subjects: 
  52.   - kind: ServiceAccount 
  53.     name: rook-nfs-server 
  54.      # replace with namespace where provisioner is deployed 
  55.     namespace: rook-nfs 
  56. roleRef: 
  57.   kind: ClusterRole 
  58.   name: rook-nfs-provisioner-runner 
  59.   apiGroup: rbac.authorization.k8s.io 

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

  1. 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 的文件中:

  1. --- 
  2. # A default storageclass must be present 
  3. apiVersion: v1 
  4. kind: PersistentVolumeClaim 
  5. metadata: 
  6.   name: nfs-default-claim 
  7.   namespace: rook-nfs 
  8. spec: 
  9.   accessModes: 
  10.   - ReadWriteMany 
  11.   resources: 
  12.     requests: 
  13.       storage: 1Gi 
  14. --- 
  15. apiVersion: nfs.rook.io/v1alpha1 
  16. kind: NFSServer 
  17. metadata: 
  18.   name: rook-nfs 
  19.   namespace: rook-nfs 
  20. spec: 
  21.   replicas: 1 
  22.   exports: 
  23.   - name: share1 
  24.     server: 
  25.       accessMode: ReadWrite 
  26.       squash: "none" 
  27.     # A Persistent Volume Claim must be created before creating NFS CRD instance. 
  28.     persistentVolumeClaim: 
  29.       claimName: nfs-default-claim 
  30.   # A key/value list of annotations 
  31.   annotations: 
  32.     rook: nfs 

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

  1. 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
  1. apiVersion: storage.k8s.io/v1 
  2. kind: StorageClass 
  3. metadata: 
  4.   name: standard-xfs 
  5. parameters: 
  6.   type: pd-standard 
  7.   fsType: xfs 
  8. mountOptions: 
  9.   - prjquota 
  10. provisioner: kubernetes.io/gce-pd 
  11. reclaimPolicy: Delete 
  12. volumeBindingMode: Immediate 
  13. allowVolumeExpansion: true 
  • AWS EBS
  1. apiVersion: storage.k8s.io/v1 
  2. kind: StorageClass 
  3. metadata: 
  4.   name: standard-xfs 
  5. provisioner: kubernetes.io/aws-ebs 
  6. parameters: 
  7.   type: io1 
  8.   iopsPerGB: "10" 
  9.   fsType: xfs 
  10. mountOptions: 
  11.   - prjquota 
  12. reclaimPolicy: Delete 
  13. volumeBindingMode: Immediate 

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

  1. --- 
  2. # A storage class with name standard-xfs must be present. 
  3. # The storage class must be has xfs filesystem type  and prjquota mountOptions. 
  4. apiVersion: v1 
  5. kind: PersistentVolumeClaim 
  6. metadata: 
  7.   name: nfs-xfs-claim 
  8.   namespace: rook-nfs 
  9. spec: 
  10.   storageClassName: "standard-xfs" 
  11.   accessModes: 
  12.   - ReadWriteOnce 
  13.   resources: 
  14.     requests: 
  15.       storage: 1Gi 
  16. --- 
  17. apiVersion: nfs.rook.io/v1alpha1 
  18. kind: NFSServer 
  19. metadata: 
  20.   name: rook-nfs 
  21.   namespace: rook-nfs 
  22. spec: 
  23.   replicas: 1 
  24.   exports: 
  25.   - name: share1 
  26.     server: 
  27.       accessMode: ReadWrite 
  28.       squash: "none" 
  29.     # A Persistent Volume Claim must be created before creating NFS CRD instance. 
  30.     persistentVolumeClaim: 
  31.       claimName: nfs-xfs-claim 
  32.   # A key/value list of annotations 
  33.   annotations: 
  34.     rook: nfs 

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

  1. 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:

  1. --- 
  2. # A rook ceph cluster must be running 
  3. Create a rook ceph cluster using examples in rook/cluster/examples/kubernetes/ceph 
  4. # Refer to https://rook.io/docs/rook/master/ceph-quickstart.html for a quick rook cluster setup 
  5. apiVersion: v1 
  6. kind: PersistentVolumeClaim 
  7. metadata: 
  8.   name: nfs-ceph-claim 
  9.   namespace: rook-nfs 
  10. spec: 
  11.   storageClassName: rook-ceph-block 
  12.   accessModes: 
  13.   - ReadWriteMany 
  14.   resources: 
  15.     requests: 
  16.       storage: 2Gi 
  17. --- 
  18. apiVersion: nfs.rook.io/v1alpha1 
  19. kind: NFSServer 
  20. metadata: 
  21.   name: rook-nfs 
  22.   namespace: rook-nfs 
  23. spec: 
  24.   replicas: 1 
  25.   exports: 
  26.   - name: share1 
  27.     server: 
  28.       accessMode: ReadWrite 
  29.       squash: "none" 
  30.     # A Persistent Volume Claim must be created before creating NFS CRD instance. 
  31.     # Create a Ceph cluster for using this example 
  32.     # Create a ceph PVC after creating the rook ceph cluster using ceph-pvc.yaml 
  33.     persistentVolumeClaim: 
  34.       claimName: nfs-ceph-claim 
  35.   # A key/value list of annotations 
  36.   annotations: 
  37.     rook: nfs 

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

  1. kubectl create -f nfs-ceph.yaml 

验证 NFS Server

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

  1. kubectl -n rook-nfs get nfsservers.nfs.rook.io 
  1. NAME       AGE   STATE 
  2. rook-nfs   32s   Running 

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

  1. kubectl -n rook-nfs get pod -l app=rook-nfs 
  1. NAME         READY     STATUS    RESTARTS   AGE 
  2. 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 来动态配置卷。

  1. apiVersion: storage.k8s.io/v1 
  2. kind: StorageClass 
  3. metadata: 
  4.   labels: 
  5.     app: rook-nfs 
  6.   name: rook-nfs-share1 
  7. parameters: 
  8.   exportName: share1 
  9.   nfsServerName: rook-nfs 
  10.   nfsServerNamespace: rook-nfs 
  11. provisioner: nfs.rook.io/rook-nfs-provisioner 
  12. reclaimPolicy: Delete 
  13. volumeBindingMode: Immediate 

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

  1. kubectl create -f sc.yaml 

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

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

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

  1. apiVersion: v1 
  2. kind: PersistentVolumeClaim 
  3. metadata: 
  4.   name: rook-nfs-pv-claim 
  5. spec: 
  6.   storageClassName: "rook-nfs-share1" 
  7.   accessModes: 
  8.     - ReadWriteMany 
  9.   resources: 
  10.     requests: 
  11.       storage: 1Mi 

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

  1. 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:

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

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

  1. kubectl get pod -l app=nfs-demo 

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

  1. kubectl create -f web-service.yaml 

然后我们可以使用我们之前启动的 busybox writer pod 来检查 nginx 是否正确地提供数据。在下面的 1-liner 命令中,我们使用 kubectl exec 在 busybox writer pod 中运行一个命令, 该命令使用 wget 检索 web server pod 托管的 web page。随着 busybox writer pod 继续写入新的时间戳,我们应该会看到返回的输出也每大约 10 秒更新一次。

  1. $ echo; kubectl exec $(kubectl get pod -l app=nfs-demo,role=busybox -o jsonpath='{.items[0].metadata.name}'-- wget -qO- http://$(kubectl get services nfs-web -o jsonpath='{.spec.clusterIP}'); echo 
  1. Thu Oct 22 19:28:55 UTC 2015 
  2. nfs-busybox-w3s4t 

清理销毁

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

  1. kubectl delete -f web-service.yaml 
  2. kubectl delete -f web-rc.yaml 
  3. kubectl delete -f busybox-rc.yaml 
  4. kubectl delete -f pvc.yaml 
  5. kubectl delete -f pv.yaml 
  6. kubectl delete -f nfs.yaml 
  7. kubectl delete -f nfs-xfs.yaml 
  8. kubectl delete -f nfs-ceph.yaml 
  9. kubectl delete -f rbac.yaml 
  10. kubectl delete -f psp.yaml 
  11. kubectl delete -f scc.yaml # if deployed 
  12. kubectl delete -f operator.yaml 
  13. kubectl delete -f webhook.yaml # if deployed 
  14. kubectl delete -f common.yaml 

故障排除

如果 NFS server pod 没有出现,第一步是检查 NFS operator 的日志:

  1. kubectl -n rook-nfs-system logs -l app=rook-nfs-operator 

 

责任编辑:武晓燕 来源: 黑客下午茶
相关推荐

2022-06-09 11:52:40

KubernetesOpenEBSLinux

2022-11-29 19:43:05

云原生工具

2022-02-23 20:38:32

云原生集群Postgres

2022-01-11 13:36:58

鹏云云原生存储

2022-09-20 07:36:43

云原生存储方案

2009-09-25 10:24:40

Androind入门教OPhone

2019-05-17 15:25:59

云原生服务架构存储

2018-04-24 09:17:15

容器原生存储

2014-06-04 10:42:34

Swift苹果iOS

2020-11-25 19:05:50

云计算SaaS公有云

2021-07-06 07:46:16

KubernetesRook存储

2021-10-19 10:52:06

Serverless阿里云

2024-03-15 08:18:05

Shelve模块Python工具

2011-07-26 13:58:17

LINQ

2022-11-06 21:31:11

云原生Sentinel集群模式

2016-09-20 09:18:29

存储

2023-03-01 07:42:12

HBase编排部署数据

2022-08-21 07:17:16

LinkerdKubernetes服务网格

2021-12-10 08:13:02

MatplotlibpythonAPI

2022-08-19 07:13:45

SQL方法编程
点赞
收藏

51CTO技术栈公众号