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，請將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 附加到
NFSserver pod。
可以被附加(attached)和導出(exported)任何類型的PVC，例如Host Path、AWS Elastic Block Store、GCP Persistent Disk、CephFS、Ceph RBD等。
這些卷的限制(limitations)在它們由NFS共享時也適用。您可以在 Kubernetes docs 中進一步了解這些卷的詳細信息和限制。 - 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 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