建站
咨詢
售后
建站咨詢
新聞中心
快速上手 Rook，入門云原生存儲編排
作者： 為少 2021-08-04 13:19:28
存儲
存儲軟件
云原生 Rook 是一個開源 cloud-native storage orchestrator(云原生存儲編排器)，為各種存儲解決方案提供平臺、框架和支持，以與云原生環(huán)境進行原生集成。
按需網(wǎng)站開發(fā)可以根據(jù)自己的需求進行定制，成都網(wǎng)站設計、網(wǎng)站建設構思過程中功能建設理應排到主要部位公司成都網(wǎng)站設計、網(wǎng)站建設的運用實際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實際意義
本文轉載自微信公眾號「黑客下午茶」，作者為少。轉載本文請聯(lián)系黑客下午茶公眾號。
Rook 是一個開源 cloud-native storage orchestrator(云原生存儲編排器)，為各種存儲解決方案提供平臺、框架和支持，以與云原生環(huán)境進行原生集成。
Rook 將存儲軟件轉變?yōu)樽晕夜芾?self-managing)、自我擴展(self-scaling)和自我修復(self-healing)的存儲服務。它通過自動化部署(automating deployment)、引導(bootstrapping)、配置(configuration)、供應(provisioning)、 擴展(scaling)、升級(upgrading)、遷移(migration)、災難恢復(disaster recovery)、監(jiān)控(monitoring)和資源管理(resource management)來實現(xiàn)這一點。 Rook 使用底層云原生容器管理、調度和編排平臺提供的設施來執(zhí)行其職責。
Rook 利用擴展點深度集成到云原生環(huán)境中，并為調度、生命周期管理、資源管理、安全、監(jiān)控和用戶體驗提供無縫體驗。
Cassandra 快速入門
Cassandra 是一個高可用、容錯、對等的 NoSQL 數(shù)據(jù)庫，具有閃電般的性能和可調的一致性。它提供了無單點故障的大規(guī)?？蓴U展性。
Scylla 是在 C++ 中對 Cassandra 的接近硬件重寫。它采用無共享架構，可實現(xiàn)真正的線性擴展和主要硬件優(yōu)化，從而實現(xiàn)超低延遲和極高吞吐量。它是 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
創(chuàng)建和初始化 Cassandra/Scylla 集群
現(xiàn)在 operator 正在運行，我們可以通過創(chuàng)建 clusters.cassandra.rook.io 資源的實例來創(chuàng)建 Cassandra/Scylla 集群的實例。該資源的某些值是可配置的，因此請隨意瀏覽 cluster.yaml 并根據(jù)自己的喜好調整設置。
當你準備創(chuàng)建一個 Cassandra 集群時，只需運行:
- kubectl create -f cluster.yaml
我們可以使用以下命令驗證是否已創(chuàng)建代表我們新 Cassandra 集群的 Kubernetes 對象。這很重要，因為它表明 Rook 已成功擴展 Kubernetes，使 Cassandra 集群成為 Kubernetes 云原生環(huán)境中的一等公民。
- kubectl -n rook-cassandra get clusters.cassandra.rook.io
要檢查是否所有所需的成員都在運行，您應該從以下命令中看到與 cluster.yaml 中指定的成員數(shù)量相同的條目數(shù)：
- kubectl -n rook-cassandra get pod -l app=rook-cassandra
您還可以從其狀態(tài)跟蹤 Cassandra 集群的狀態(tài)。要檢查集群的當前狀態(tài)，請運行：
- kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra
訪問數(shù)據(jù)庫
- 從 kubectl：
要在新集群中獲取 cqlsh shell：
- kubectl exec -n rook-cassandra -it rook-cassandra-east-1-east-1a-0 -- cqlsh
- > DESCRIBE KEYSPACES;
- 從 Pod 內部：
當你創(chuàng)建一個新的集群時，Rook 會自動為客戶端創(chuàng)建一個服務來訪問集群。服務的名稱遵循約定 -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 后，請檢查集群的狀態(tài)和事件以獲取有關正發(fā)生情況的信息：
- 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 后，請檢查集群的狀態(tài)和事件以獲取有關正發(fā)生情況的信息：
- kubectl -n rook-cassandra describe clusters.cassandra.rook.io rook-cassandra
Clean Up
要清理與此演練相關的所有資源，您可以運行以下命令。
注意：這將破壞您的數(shù)據(jù)庫并刪除其所有相關數(shù)據(jù)。
- kubectl delete -f cluster.yaml
- kubectl delete -f operator.yaml
故障排除
如果集群沒有出現(xiàn)，第一步是檢查 operator 的日志：
- kubectl -n rook-cassandra-system logs -l app=rook-cassandra-operator
如果 operator 日志中一切正常，您還可以查看 Cassandra 實例之一的日志：
- kubectl -n rook-cassandra logs rook-cassandra-0
Cassandra 監(jiān)控
要為 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 的數(shù)據(jù)字段必須包含帶有 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 或更早版本，則需要創(chuàng)建不同版本的 Rook CRD。創(chuàng)建在示例清單的 pre-k8s-1.16 子文件夾中找到的 crds.yaml。
前提條件
為確保您擁有可用于 Rook 的 Kubernetes 集群。
為了配置 Ceph 存儲集群，至少需要以下本地存儲選項之一：
- 原始設備(無分區(qū)或格式化文件系統(tǒng))
- 這需要在主機上安裝 lvm2。為了避免這種依賴性，您可以在磁盤上創(chuàng)建一個完整的磁盤分區(qū)(見下文)
- 原始分區(qū)(無格式化文件系統(tǒng))
- block 模式下存儲類中可用的持久卷
您可以使用以下命令確認您的分區(qū)或設備是否已格式化文件系統(tǒng)。
- 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 字段不為空，則在相應設備的頂部有一個文件系統(tǒng)。在這種情況下，您可以將 vdb 用于 Ceph，而不能使用 vda 及其分區(qū)。
TL;DR
如果幸運的話，可以使用以下 kubectl 命令和示例 yaml 文件創(chuàng)建一個簡單的 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
集群環(huán)境
Rook 文檔側重于在生產環(huán)境中啟動 Rook。還提供了一些示例來放寬測試環(huán)境的一些設置。在本指南后面創(chuàng)建集群時，請考慮以下示例集群清單：
- cluster.yaml: 在裸機上運行的生產集群的集群設置。至少需要三個工作節(jié)點。
- cluster-on-pvc.yaml: 在動態(tài)云環(huán)境中運行的生產集群的集群設置。
- cluster-test.yaml: 測試環(huán)境的集群設置，例如 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 或更早版本，則需要在此處創(chuàng)建 CRD，在 /cluster/examples/kubernetes/ceph/pre-k8s-1.16/crd.yaml。 CustomResourceDefinition 的 apiextension v1beta1 版本在 Kubernetes v1.16 中已棄用。
- 考慮是否要啟用默認禁用的某些 Rook 功能。有關這些和其他高級設置，請參閱 operator.yaml。
- 設備發(fā)現(xiàn)：如果啟用了 ROOK_ENABLE_DISCOVERY_DAEMON 設置，Rook 將監(jiān)視要配置的新設備，常用于裸機集群。
- Flex driver：Flex driver 已被棄用，取而代之的是 CSI driver，但仍可通過 ROOK_ENABLE_FLEX_DRIVER 設置啟用。
- Node affinity and tolerations(節(jié)點關聯(lián)和容忍度)：默認情況下，CSI driver 將在集群中的任何節(jié)點上運行。要配置 CSI driver affinity，可以使用多種設置。
創(chuàng)建 Rook Ceph 集群
現(xiàn)在 Rook operator 正在運行，我們可以創(chuàng)建 Ceph 集群。為了使集群在重新啟動后繼續(xù)存在，請確保設置對主機有效的 dataDirHostPath 屬性。
創(chuàng)建集群：
- kubectl create -f cluster.yaml
使用 kubectl 列出 rook-ceph 命名空間中的 pod。一旦它們全部運行，您應該能夠看到以下 pod。 osd pod 的數(shù)量將取決于集群中的節(jié)點數(shù)量和配置的設備數(shù)量。如果沒有修改上面的 cluster.yaml，預計每個節(jié)點會創(chuàng)建一個 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
要驗證集群是否處于健康狀態(tài)，請連接到 Rook toolbox 并運行 ceph status 命令。
- 所有 mons 都應達到法定人數(shù)
- mgr 應該是活躍的
- 至少有一個 OSD 處于活動狀態(tài)
- 如果運行狀況不是 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：創(chuàng)建要由 Pod 使用的塊(block)存儲
- Object：創(chuàng)建可在 Kubernetes 集群內部或外部訪問的對象存儲
- Shared Filesystem：創(chuàng)建要在多個 pod 之間共享的文件系統(tǒng)
Ceph 儀表板
Ceph 有一個儀表板，您可以在其中查看集群的狀態(tài)。
工具
我們創(chuàng)建了一個 toolbox 容器，其中包含用于調試和排除 Rook 集群故障的全套 Ceph 客戶端。
監(jiān)控
每個 Rook 集群都有一些內置的指標收集器(collectors)/導出器(exporters)，用于使用 Prometheus 進行監(jiān)控。
銷毀
完成測試集群后，請參閱這些說明以清理集群。
網(wǎng)絡文件系統(tǒng) (NFS)
NFS 允許遠程主機通過網(wǎng)絡掛載文件系統(tǒng)并與這些文件系統(tǒng)交互，就像它們是在本地掛載一樣。這使系統(tǒng)管理員能夠將資源整合到網(wǎng)絡上的中央服務器上。
- 前提條件
- 運行 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 的所有節(jié)點上。在 CentOS 節(jié)點上安裝 nfs-utils 或在 Ubuntu 節(jié)點上安裝 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(持久化)之前驗證發(fā)送到 API server 的 NFSServer 對象。
要在 NFS 上啟用 admission webhook，例如驗證 admission webhook，您需要執(zhí)行以下操作：
首先，確保安裝了 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 狀態(tài)：
- 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 運行，您現(xiàn)在可以部署 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
創(chuàng)建 Openshift 安全上下文約束(可選)
在 OpenShift 集群上，我們需要創(chuàng)建一些額外的安全上下文約束。如果您未在 OpenShift 中運行，則可以跳過此部分并轉到下一部分。
要為 nfs-server pod 創(chuàng)建安全上下文約束，我們可以使用以下 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
您可以使用以下命令創(chuàng)建 scc：
- oc create -f scc.yaml
創(chuàng)建 Pod 安全策略(推薦)
我們建議您也創(chuàng)建 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 保存此文件并使用以下命令創(chuàng)建：
- kubectl create -f psp.yaml
創(chuàng)建和初始化 NFS 服務器
現(xiàn)在 operator 正在運行，我們可以通過創(chuàng)建 nfsservers.nfs.rook.io 資源的實例來創(chuàng)建 NFS 服務器的實例。NFS server resource 的各種字段和選項可用于配置要導出的服務器及其卷。
在我們創(chuàng)建 NFS Server 之前，我們需要創(chuàng)建 ServiceAccount 和 RBAC 規(guī)則
- ---
- 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 保存此文件并使用以下命令創(chuàng)建：
- kubectl create -f rbac.yaml
本指南有 3 個主要示例，用于演示使用 NFS 服務器導出卷(exporting volumes)：
- 默認 StorageClass 示例
- XFS StorageClass 示例
- Rook Ceph volume 示例
默認 StorageClass 示例
第一個示例將逐步創(chuàng)建一個 NFS server 實例，該實例導出由您碰巧運行的環(huán)境的默認 StorageClass 支持的存儲。在某些環(huán)境中，這可能是主機路徑(host path)，在其他環(huán)境中，它可能是云提供商虛擬磁盤(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 文件后，現(xiàn)在創(chuàng)建 NFS server，如下所示：
- kubectl create -f nfs.yaml
XFS StorageClass 示例
Rook NFS 通過 xfs_quota 支持磁盤配額。因此，如果您需要為卷指定磁盤配額，則可以按照此示例進行操作。
在這個例子中，我們將使用一個帶有 prjquota 選項的作為 xfs 掛載的底層卷。在創(chuàng)建底層卷(underlying volume)之前，您需要使用 xfs 文件系統(tǒng)和 prjquota mountOptions 創(chuàng)建 StorageClass。Kubernetes 的許多分布式存儲提供商都支持 xfs 文件系統(tǒng)。通常通過在 storageClass 參數(shù)中定義 fsType: xfs 或 fs: xfs。但實際上如何指定 storage-class 文件系統(tǒng)類型取決于它自己的存儲提供者。您可以查看 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 文件系統(tǒng)和 prjquota mountOptions 的 StorageClass，您就可以使用以下示例創(chuàng)建 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 并使用以下命令創(chuàng)建。
- kubectl create -f nfs-xfs.yaml
Rook Ceph volume 示例
在這個替代示例中，我們將使用不同的基礎卷(underlying volume)作為 NFS server 的 export。這些步驟將引導我們導出 Ceph RBD block volume，以便客戶端可以通過網(wǎng)絡訪問它。
在 Rook Ceph 集群啟動并運行后，我們可以繼續(xù)創(chuàng)建 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
創(chuàng)建您保存在 nfs-ceph.yaml 中的 NFS server 實例：
- kubectl create -f nfs-ceph.yaml
驗證 NFS Server
我們可以使用以下命令驗證是否已創(chuàng)建代表我們的新 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 狀態(tài)，那么我們已經成功創(chuàng)建了一個暴露的 NFS 共享，客戶端可以開始通過網(wǎng)絡訪問。
訪問 Export
從 Rook 版本 v1.0 開始，Rook 支持 NFS 的動態(tài)配置(dynamic provisioning)。此示例將展示如何將動態(tài)配置功能用于 nfs。
部署 NFS Operator 和 NFSServer 實例后。必須創(chuàng)建類似于以下示例的 storageclass 來動態(tài)配置卷。
- 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 然后使用以下命令創(chuàng)建 storageclass。
- kubectl create -f sc.yaml
注意：StorageClass 需要傳遞以下 3 個參數(shù)。
- exportName: 它告訴供應商(provisioner)使用哪個導出來供應卷。
- nfsServerName: 它是 NFSServer 實例的名稱。
- nfsServerNamespace: NFSServer 實例運行所在的命名空間。
創(chuàng)建上述 storageclass 后，您可以創(chuàng)建引用 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 然后使用以下命令創(chuàng)建 PV claim。
- kubectl create -f pvc.yaml
消費 Export
現(xiàn)在我們可以通過創(chuàng)建一個示例 web server app 來使用剛剛創(chuàng)建的 PV， 該應用程序使用上述 PersistentVolumeClaim 聲明導出的卷。有 2 個 pod 構成此示例：
將讀取和顯示 NFS 共享內容的 Web server pod
將隨機數(shù)據(jù)寫入 NFS 共享的 writer pod，以便網(wǎng)站不斷更新
從 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 狀態(tài)：
- kubectl get pod -l app=nfs-demo
為了能夠通過網(wǎng)絡訪問 Web server，讓我們?yōu)樗鼊?chuàng)建一個 service：
- kubectl create -f web-service.yaml
然后我們可以使用我們之前啟動的 busybox writer pod 來檢查 nginx
網(wǎng)站欄目：快速上手Rook，入門云原生存儲編排
本文路徑：http://www.fisionsoft.com.cn/article/dpggjjo.html
