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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
日志服务 SLS,月写入数据量 50GB 1个月
简介: 快速上手 Rook,入门云原生存储编排

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 会自动为客户端创建一个服务来访问集群。服务的名称遵循约定<cluster-name>-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,请将 rackSpec.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,请将 rackSpec.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=<namespace>
CLUSTER=<cluster_name>
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


前提条件


为确保您拥有可用于 RookKubernetes 集群。


为了配置 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 之前,您可能需要考虑一些设置:


  1. 如果您使用 kubernetes v1.15 或更早版本,则需要在此处创建 CRD,在 /cluster/examples/kubernetes/ceph/pre-k8s-1.16/crd.yamlCustomResourceDefinitionapiextension v1beta1 版本在 Kubernetes v1.16 中已弃用。
  2. 考虑是否要启用默认禁用的某些 Rook 功能。有关这些和其他高级设置,请参阅 operator.yaml。
  1. 设备发现:如果启用了 ROOK_ENABLE_DISCOVERY_DAEMON 设置,Rook 将监视要配置的新设备,常用于裸机集群。
  2. Flex driver:Flex driver 已被弃用,取而代之的是 CSI driver,但仍可通过 ROOK_ENABLE_FLEX_DRIVER 设置启用。
  3. Node affinity and tolerations(节点关联和容忍度):默认情况下,CSI driver 将在集群中的任何节点上运行。要配置 CSI driver affinity,可以使用多种设置。


创建 Rook Ceph 集群


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

创建集群:


kubectl create -f cluster.yaml


使用 kubectl 列出 rook-ceph 命名空间中的 pod。一旦它们全部运行,您应该能够看到以下 podosd 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 允许远程主机通过网络挂载文件系统并与这些文件系统交互,就像它们是在本地挂载一样。这使系统管理员能够将资源整合到网络上的中央服务器上。


前提条件


  1. 运行 Rook NFS operator 需要 Kubernetes 集群。
  2. 要暴露的卷,需要通过 PVC 附加到 NFS server pod。


可以被附加(attached)和导出(exported)任何类型的 PVC,例如 Host PathAWS Elastic Block StoreGCP Persistent DiskCephFSCeph 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
rook-nfs-operator-879f5bf8b-gnwht       1/1     Running   0          29m


部署 NFS Admission Webhook (可选)


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


要在 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 之前,我们需要创建 ServiceAccountRBAC 规则


---
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):


  1. 默认 StorageClass 示例
  2. XFS StorageClass 示例
  3. 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: xfsfs: 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 OperatorNFSServer 实例后。必须创建类似于以下示例的 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 个参数。


  1. exportName: 它告诉供应商(provisioner)使用哪个导出来供应卷。
  2. nfsServerName: 它是 NFSServer 实例的名称。
  3. 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 构成此示例:


  1. 将读取和显示 NFS 共享内容的 Web server pod
  2. 将随机数据写入 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 是否正确地提供数据。在下面的 1-liner 命令中,我们使用 kubectl execbusybox writer pod 中运行一个命令, 该命令使用 wget 检索 web server pod 托管的 web page。随着 busybox writer pod 继续写入新的时间戳,我们应该会看到返回的输出也每大约 10 秒更新一次。


$ 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


Thu Oct 22 19:28:55 UTC 2015
nfs-busybox-w3s4t


清理销毁


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


kubectl delete -f web-service.yaml
kubectl delete -f web-rc.yaml
kubectl delete -f busybox-rc.yaml
kubectl delete -f pvc.yaml
kubectl delete -f pv.yaml
kubectl delete -f nfs.yaml
kubectl delete -f nfs-xfs.yaml
kubectl delete -f nfs-ceph.yaml
kubectl delete -f rbac.yaml
kubectl delete -f psp.yaml
kubectl delete -f scc.yaml # if deployed
kubectl delete -f operator.yaml
kubectl delete -f webhook.yaml # if deployed
kubectl delete -f common.yaml


故障排除


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


kubectl -n rook-nfs-system logs -l app=rook-nfs-operator
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1天前
|
Kubernetes Cloud Native 持续交付
云原生技术入门及应用实例
【9月更文挑战第34天】云原生,这个词汇在IT界已经越来越热。它代表的是一种构建和运行应用程序的方法,旨在充分利用云计算的优势。本文将从云原生的基本概念入手,深入探讨其核心技术和应用场景,最后通过一个简单的代码示例,带你走进云原生的世界。
|
5天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker与Kubernetes入门
【9月更文挑战第30天】在云计算的浪潮中,云原生技术正以前所未有的速度重塑着软件开发和运维领域。本文将通过深入浅出的方式,带你了解云原生的核心组件——Docker容器和Kubernetes集群,并探索它们如何助力现代应用的构建、部署和管理。从Docker的基本命令到Kubernetes的资源调度,我们将一起开启云原生技术的奇妙之旅。
|
1天前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes的奇妙之旅
【9月更文挑战第34天】在数字化浪潮中,云原生技术如Kubernetes已经成为IT行业的重要力量。本文旨在通过浅显易懂的方式,向初学者揭示Kubernetes的核心概念、架构设计及其在实际业务中的应用价值,帮助读者快速理解并掌握这一技术,为进一步深入学习和实践打下坚实基础。
7 1
|
15天前
|
运维 Cloud Native Docker
云原生技术入门:Docker容器化实战
【9月更文挑战第20天】本文将引导你走进云原生技术的世界,通过Docker容器化技术的实战演练,深入理解其背后的原理和应用。我们将一起探索如何在云平台上利用Docker简化部署、扩展和管理应用程序的过程,并揭示这一技术如何改变现代软件的开发和运维模式。
|
16天前
|
Kubernetes 监控 Cloud Native
云原生入门:从传统应用到容器化部署的旅程
【9月更文挑战第19天】在数字化浪潮中,企业正迅速将目光投向云原生技术,以实现更快的应用开发和更灵活的资源管理。本文将通过一个简单示例引导读者理解如何将传统应用转变为云原生应用,并部署至云端。我们将探索容器化技术的基础,以及它如何帮助企业解锁现代软件交付的速度和效率。准备好让你的应用乘上云原生的快车了吗?让我们开始这段令人兴奋的旅程吧!
|
10天前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
29 4
|
19天前
|
Kubernetes Cloud Native 开发者
云原生入门:从Docker到Kubernetes的旅程
【9月更文挑战第16天】 本文将带你进入云原生的世界,从理解Docker容器的基础开始,逐步深入到Kubernetes集群管理。我们将通过简单的代码示例和实际操作,探索这两个关键技术如何协同工作,以实现更高效、灵活的应用程序部署和管理。无论你是云原生新手还是希望深化理解,这篇文章都将为你提供清晰的指导和实用的知识。
51 11
|
13天前
|
Kubernetes Cloud Native 云计算
云原生技术入门与实践
【9月更文挑战第22天】本文将带你了解云原生技术,并探讨如何利用它来构建高效、可扩展的应用。我们将从基础概念开始,逐步深入到实际应用,最后通过一个简单的示例展示如何在Kubernetes上部署一个容器化应用。无论你是初学者还是有经验的开发者,这篇文章都将为你提供宝贵的见解和实用的技巧。
|
18天前
|
Kubernetes Cloud Native Linux
云原生入门:Kubernetes的简易部署与应用
【8月更文挑战第49天】在云原生的世界里,Kubernetes(K8s)是一颗璀璨的星。本文将带你走进K8s的世界,从安装到简单应用,轻松驾驭这个强大的容器编排工具。让我们一起探索云原生的奥秘,解锁新技能!
|
29天前
|
Kubernetes 监控 Cloud Native
云原生入门:Kubernetes 集群部署与管理
【8月更文挑战第38天】在数字化浪潮中,云原生技术如同翱翔的雄鹰,引领着企业飞向灵活高效的未来。本文将带你一探究竟,从Kubernetes的基础概念到实际操作,深入浅出地介绍如何在云端构建和管理你的容器化应用。我们将一步步搭建起一个小型的Kubernetes集群,并通过代码示例和图解,让你轻松掌握云原生世界的钥匙。让我们一起开启这趟技术之旅,探索云原生的秘密花园,找到那把打开创新之门的金钥匙。

热门文章

最新文章

下一篇
无影云桌面