您好,登錄后才能下訂單哦!
基本概念解析:云原生存儲編排管理器。
基本概念詳解:rook通過一個操作器(operator)完成后續操作,只需要定義需要狀態就行了。Rook通過監視器監控狀態變化,并將配置文件分配到集群上生效。傳統意義上的集群管理員必須掌握和監控系統,而Rook存儲運行則完全自動化。rook存儲是通過第三方資源以kubernetes擴展形式運行。
rook operator: 是一個簡單的容器,具有引導和監視存儲集群的功能,供提供最基本的RADOS存儲。管理CRD,對象存儲,文件系統。
Rook agent: 這些代理是在每個Kubernetes節點上部署的pod。每個代理都配置一個Flexvolume插件,該插件與Kubernetes的卷控制器框架集成在一起。處理節點上所需的所有存儲操作,例如附加網絡存儲設備,安裝卷和格式化文件系統。
Discover: 定期節點發現新設備
1.rook operator運行,并在每臺機器上運行一個rook agent的pod
2.創建一個pvc,并指定storageclass使用rook.io/block provisionor
3.operator provisionr 的provision()函數被調用,用以在集群中創建block image。此時,Provision階段已完成,pvc/pv被考慮綁定到一起;
4.當使用pvc的pod被創建時,kubelete將調用 rook Felexxvolume的mount函數,用于使用預定存儲;
5. 隨后,agent將會按照CRD的描述創建一個volume并attach到該物理機上;
6.agent將volume map到本地機器上,并更新CRD的狀態以及設備的路徑值(例如/dev/rbd0)
7.控制權接著轉交給driver,如果mapping能夠成功執行,則driver將把指定的設備mount到指定的路徑上。若在配置文件中還指明了文件系統的類型,則driver還會對該卷進行文件系統格式化操作。
8.driver將反饋kubelet Mount()操作已成功
# 說在前面的重點,刪除重建operator,cluster時,要刪除/var/lib/rook.
cd cluster/examples/kubernetes/ceph
kubectl create -f operator.yaml
#主要是一些自定義資源對象的定義CRD有:Cluster、Filesystem、ObjectStore、Pool、Volume;還創建了rook的三種組件Operator、Agent、Discover。
kubectl create -f cluster.yaml
#cluster.yaml中主要創建了一個Cluster(ceph集群)自定義資源對象(CR)
#如果出現如下報錯,請參考如下
解決方案參考1:
配置operator.yaml,需要和kubelet的--volume-plugin-dir參數中的保持一致
vim operator.yaml
- name: FLEXVOLUME_DIR_PATH
value: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec"
解決方案參考2
exit status 2. rbd: error opening pool 'replicapool': (2) No such file or directory -- 這個報錯,我有遇到類似的問題,解決方法:在 rook-operator.yml 里添加
env:
- name: FLEXVOLUME_DIR_PATH
value: "/var/lib/kubelet/volumeplugins"
確保與kubelet 的--volume-plugin-dir一樣。重新apply.重啟kubelet.把rook-agent 和 rook-operator的pod刪除,自動重建后等10分鐘我的報錯就消失了。
--volume-plugin-dir=/var/lib/kubelet/volumeplugins
- 清理命名空間rook-system,其中包含rook Operator和rook agent
- 清理名稱空間rook,其中包含rook存儲集群(集群CRD)
- 各節點的/var/lib/rook目錄,ceph mons和osds的配置都緩存于此
kubectl delete -n rook pool replicapool
kubectl delete storageclass rook-block
kubectl delete -n kube-system secret rook-admin
kubectl delete -f kube-registry.yaml
# 刪除Cluster CRD
kubectl delete -n rook cluster rook
# 當Cluster CRD被刪除后,刪除Rook Operator和Agent
kubectl delete thirdpartyresources cluster.rook.io pool.rook.io objectstore.rook.io filesystem.rook.io volumeattachment.rook.io # ignore errors if on K8s 1.7+
kubectl delete crd clusters.rook.io pools.rook.io objectstores.rook.io filesystems.rook.io volumeattachments.rook.io # ignore errors if on K8s 1.5 and 1.6
kubectl delete -n rook-system daemonset rook-agent
kubectl delete -f rook-operator.yaml
kubectl delete clusterroles rook-agent
kubectl delete clusterrolebindings rook-agent
# 刪除名字空間
kubectl delete namespace rook
cluster.yaml
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
name: rook
namespace: rook
spec:
# 存儲后端,支持Ceph,NFS等等
backend: ceph
# 配置文件在宿主機的存放目錄
dataDirHostPath: /var/lib/rook
# 如果設置為true則使用宿主機的網絡,而非容器的SDN(軟件定義網絡)
hostNetwork: false
# 啟動mon的數量,必須奇數,1-9之間
monCount: 3
# 控制Rook的各種服務如何被K8S調度
placement:
# 總體規則,具體服務(api, mgr, mon, osd)的規則覆蓋總體規則
all:
# Rook的Pod能夠被調用到什么節點上(根據pod標簽來說)
nodeAffinity:
# 硬限制 配置變更后已經運行的Pod不被影響
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
# 節點必須具有role=storage-node
- matchExpressions:
- key: role
operator: In
values:
- storage-node
# Rook能夠調用到運行了怎樣的其它Pod的拓撲域上(根據node容忍度來說)
podAffinity:
podAntiAffinity:
# 可以容忍具有哪些taint的節點
tolerations:
- key: storage-node
operator: Exists
api:
nodeAffinity:
podAffinity:
podAntiAffinity:
tolerations:
mgr:
nodeAffinity:
podAffinity:
podAntiAffinity:
tolerations:
mon:
nodeAffinity:
tolerations:
osd:
nodeAffinity:
podAffinity:
podAntiAffinity:
tolerations:
# 配置各種服務的資源需求
resources:
api:
limits:
cpu: "500m"
memory: "1024Mi"
requests:
cpu: "500m"
memory: "1024Mi"
mgr:
mon:
osd:
# 集群級別的存儲配置,每個節點都可以覆蓋
storage:
# 是否所有節點都用于存儲。如果指定nodes配置,則必須設置為false
useAllNodes: true
# 是否在節點上發現的所有設備,都自動的被OSD消費
useAllDevices: false
# 正則式,指定哪些設備可以被OSD消費,示例:
# sdb 僅僅使用設備/dev/sdb
# ^sd. 使用所有/dev/sd*設備
# ^sd[a-d] 使用sda sdb sdc sdd
# 可以指定裸設備,Rook會自動分區但不掛載
deviceFilter: ^vd[b-c]
# 每個節點上用于存儲OSD元數據的設備。使用低讀取延遲的設備,例如SSD/NVMe存儲元數據可以提升性能
metadataDevice:
# 集群的位置信息,例如Region或數據中心,被直接傳遞給Ceph CRUSH map
location:
# OSD的存儲格式的配置信息
storeConfig:
# 可選filestore或bluestore,默認后者,它是Ceph的一個新的存儲引擎
# bluestore直接管理裸設備,拋棄了ext4/xfs等本地文件系統。在用戶態下使用Linux AIO直接對裸設備IO
storeType: bluestore
# bluestore數據庫容量 正常尺寸的磁盤可以去掉此參數,例如100GB+
databaseSizeMB: 1024
# filestore日志容量 正常尺寸的磁盤可以去掉此參數,例如20GB+
journalSizeMB: 1024
# 用于存儲的節點目錄。在一個物理設備上使用兩個目錄,會對性能有負面影響
directories:
- path: /rook/storage-dir
# 可以針對每個節點進行配置
nodes:
# 節點A的配置
- name: "172.17.4.101"
directories:
- path: "/rook/storage-dir"
resources:
limits:
cpu: "500m"
memory: "1024Mi"
requests:
cpu: "500m"
memory: "1024Mi"
# 節點B的配置
- name: "172.17.4.201"
- name: "sdb"
- name: "sdc"
storeConfig:
storeType: bluestore
- name: "172.17.4.301"
deviceFilter: "^sd."
pool.yaml
apiVersion: rook.io/v1alpha1
kind: Pool
metadata:
name: ecpool
namespace: rook
spec:
# 存儲池中的每份數據是否是復制的
replicated:
# 副本的份數
size: 3
# Ceph的Erasure-coded存儲池消耗更少的存儲空間,必須禁用replicated
erasureCoded:
# 每個對象的數據塊數量
dataChunks: 2
# 每個對象的代碼塊數量
codingChunks: 1
crushRoot: default
?
objectStore
apiVersion: rook.io/v1alpha1
kind: ObjectStore
metadata:
name: my-store
namespace: rook
spec:
# 元數據池,僅支持replication
metadataPool:
replicated:
size: 3
# 數據池,支持replication或erasure codin
dataPool:
erasureCoded:
dataChunks: 2
codingChunks: 1
# RGW守護程序設置
gateway:
# 支持S3
type: s3
# 指向K8S的secret,包含數字證書信息
sslCertificateRef:
# RGW Pod和服務監聽的端口
port: 80
securePort:
# 為此對象存儲提供負載均衡的RGW Pod數量
instances: 1
# 是否在所有節點上啟動RGW。如果為false則必須設置instances
allNodes: false
placement:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: role
operator: In
values:
- rgw-node
tolerations:
- key: rgw-node
operator: Exists
podAffinity:
podAntiAffinity:
resources:
limits:
cpu: "500m"
memory: "1024Mi"
requests:
cpu: "500m"
memory: "1024Mi"
filesystem
apiVersion: rook.io/v1alpha1
kind: Filesystem
metadata:
name: myfs
namespace: rook
spec:
# 元數據池
metadataPool:
replicated:
size: 3
# 數據池
dataPools:
- erasureCoded:
dataChunks: 2
codingChunks: 1
# MDS守護程序的設置
metadataServer:
# MDS活動實例數量
activeCount: 1
# 如果設置為true,則額外的MDS實例處于主動Standby狀態,維持文件系統元數據的熱緩存
# 如果設置為false,則額外MDS實例處于被動Standby狀態
activeStandby: true
placement:
resources:
PV訪問方式:
ReadWriteOnce – 被單個節點mount為讀寫rw模式 RWO
ReadOnlyMany – 被多個節點mount為只讀ro模式 ROX
ReadWriteMany – 被多個節點mount為讀寫rw模式 RWX
pv回收機制:
Retain – 手動重新使用
Recycle – 基本的刪除操作 (“rm -rf /thevolume/*”)
Delete – 關聯的后端存儲卷一起刪除,后端存儲例如AWS EBS, GCE PD或OpenStack Cinder
volume的狀態:
Available –閑置狀態,沒有被綁定到PVC
Bound – 綁定到PVC
Released – PVC被刪掉,資源沒有被在利用
Failed – 自動回收失敗
CLI會顯示綁定到PV的PVC名。
rook啟動后各pod作用
mon:監控組件,負責監控ceph集群的狀況。
mgr:manager組件,主要監控一些非paxos相關組件(比如pg相關統計信息),無狀態組件。
收集可供prometheus指標
啟動ceph dashboard
osd:osd組件,集群核心組件
mds: 元數據服務器。一或多個mds 協作管理文件系統的命名空間、協調到共享osd集群的訪問。當在集群中聲明要一個共享文件系統時,rook會:為cephfs創建matadata和數據池;創建文件系統;指定數量active-standby的mds實例。創建的文件系統會被集群中pod使用
rgw:為應用提供RESTful類型對象存儲接口
1.為對象創建metada和數據池
2.啟動rgw daemon
3.創建service為rgw damon提供一個負載均衡地址。
通過圖形界面管理,部署dashboard
cd /rook/cluster/examples/kubernetes/ceph
kubectl apply -f dashboard-external-http.yaml
kubectl get svc -n rook-ceph
#查看端口號
#通過瀏覽器訪問
創建塊存儲storageclass
1.查看ceph數據盤文件類型
df -Th
2.根據ceph數據盤的文件系統類型修改fstype參數
vims torageclass.yaml
fstype: xfs
3.創建storageclass
kubectl create -f storageclass.yaml
創建塊使用實例
cd /rook/cluster/examples/kubernetes
kubectl apply -f mysql.yaml
kubectl apply -f wordpress.yaml
創建共享文件系統
cd /rook/cluster/examples/kubernetes/ceph
kubectl create -f filesystem.yaml
kubectl get Filesystem -n rook-ceph
共同探討,一起思考。希望可以輔助大家理解!
參考資源:
基于rook的kubernetes方案
rook控制流
rook詳解
rook-github
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。