快速上手 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 會自動為客戶端創建一個服務來訪問集群。服務的名稱遵循約定
- 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=<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。
前提條件
為確保您擁有可用于 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 是否正確地提供數據。在下面的 1-liner 命令中，我們使用 kubectl exec 在 busybox 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
