容器的持久化存储
容器的持久化存储是保存容器存储状态的重要手段,存储插件会在容器里挂载一个基于网络或者其他机制的远程数据卷,使得在容器里创建的文件,实际上是保存在远程存储服务器上,或者以分布式的方式保存在多个节点上,而与当前宿主机没有任何绑定关系。这样,无论你在其他哪个宿主机上启动新的容器,都可以请求挂载指定的持久化存储卷,从而访问到数据卷里保存的内容。
由于 Kubernetes 本身的松耦合设计,绝大多数存储项目,比如 Ceph、GlusterFS、NFS 等,都可以为 Kubernetes 提供持久化存储能力。
Ceph分布式存储系统
Ceph是一种高度可扩展的分布式存储解决方案,提供对象、文件和块存储。在每个存储节点上,您将找到Ceph存储对象的文件系统和Ceph OSD(对象存储守护程序)进程。在Ceph集群上,您还可以找到Ceph MON(监控)守护程序,它们确保Ceph集群保持高可用性。
Rook
Rook 是一个开源的cloud-native storage编排, 提供平台和框架;为各种存储解决方案提供平台、框架和支持,以便与云原生环境本地集成。
Rook 将存储软件转变为自我管理、自我扩展和自我修复的存储服务,它通过自动化部署、引导、配置、置备、扩展、升级、迁移、灾难恢复、监控和资源管理来实现此目的。
Rook 使用底层云本机容器管理、调度和编排平台提供的工具来实现它自身的功能。
Rook 目前支持Ceph、NFS、Minio Object Store和CockroachDB。
Rook使用Kubernetes原语使Ceph存储系统能够在Kubernetes上运行。下图说明了Ceph Rook如何与Kubernetes集成
随着Rook在Kubernetes集群中运行,Kubernetes应用程序可以挂载由Rook管理的块设备和文件系统,或者可以使用S3 / Swift API提供对象存储。Rook oprerator自动配置存储组件并监控群集,以确保存储处于可用和健康状态。
Rook oprerator是一个简单的容器,具有引导和监视存储集群所需的全部功能。oprerator将启动并监控ceph monitor pods和OSDs的守护进程,它提供基本的RADOS存储。oprerator通过初始化运行服务所需的pod和其他组件来管理池,对象存储(S3 / Swift)和文件系统的CRD。
oprerator将监视存储后台驻留程序以确保群集正常运行。Ceph mons将在必要时启动或故障转移,并在群集增长或缩小时进行其他调整。oprerator还将监视api服务请求的所需状态更改并应用更改。
Rook oprerator还创建了Rook agent。这些agent是在每个Kubernetes节点上部署的pod。每个agent都配置一个Flexvolume插件,该插件与Kubernetes的volume controller集成在一起。处理节点上所需的所有存储操作,例如附加网络存储设备,安装卷和格式化文件系统。
部署
部署环境
1 | 172.16.1.198 master |
在node节点添加一块新的磁盘 执行lsblk确保系统能够识别到新加的磁盘,rook会自动扫描系统磁盘,rook不会使用已经分区或者已经格式化的文件系统,所以确保了系统盘的安全性,搭建时也要确保新加的磁盘不要分区和格式化
下载rook
1 | git clone https://github.com/rook/rook.git |
部署common组件
1 | kubectl create -f common.yaml |
部署operator组件
1 | kubectl create -f operator.yaml |
部署cluster组件
1 | kubectl create -f cluster.yaml |
稍等片刻,查看部署进度
1 | kubectl get pod -n rook-ceph |
部署StorageClass
1 | kubectl create -f storageclass.yaml |
修改rook-ceph-block为默认stroageclass
1 | kubectl patch storageclass rook-ceph-block -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' |
创建pod使用pv
1 | vim centos.yaml |
查看pv,pvc
1 | $ [K8sSj] kubectl get pv,pvc -n zlx |
查看pod
可以看到resize-pv已经挂载到deployment
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62 $ [K8sSj] kubectl get pod -n zlx
NAME READY STATUS RESTARTS AGE
centos-5965946c94-9bc9p 1/1 Running 0 45m
$ [K8sSj] kubectl describe deployments.apps -n zlx centos
Name: centos
Namespace: zlx
CreationTimestamp: Tue, 14 May 2019 10:09:46 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision=1
Selector: app=centos
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=centos
Containers:
centos:
Image: centos
Port: <none>
Host Port: <none>
Command:
bash
-c
while true;do echo "I'm centos";sleep 30;done
Limits:
cpu: 200m
memory: 128Mi
Environment: <none>
Mounts:
/opt/ from resize-pvc (rw)
Volumes:
resize-pvc:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: resize-pvc
ReadOnly: false
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: centos-5965946c94 (1/1 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 46m deployment-controller Scaled up replica set centos-5965946c94 to 1
$ [K8sSj] kubectl exec -it -n zlx centos-5965946c94-9bc9p bash
[root@centos-5965946c94-9bc9p /]# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 189G 6.4G 174G 4% /
tmpfs 64M 0 64M 0% /dev
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/rbd0 1014M 34M 981M 4% /opt
/dev/vda1 189G 6.4G 174G 4% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 3.9G 12K 3.9G 1% /run/secrets/kubernetes.io/serviceaccount
tmpfs 3.9G 0 3.9G 0% /proc/acpi
tmpfs 3.9G 0 3.9G 0% /proc/scsi
tmpfs 3.9G 0 3.9G 0% /sys/firmware
扩容
搞扩容这块的时候在坑里很久,k8s官方文档说的是支持ceph的pv,pvc自动扩容,所以就自作聪明的认为只要,k8s和rook可以帮助我们完成一些了的扩容动作,在1.13版本中在pv中扩容,pvc,可以自动扩容,按照官方的说法重启pod后pv就应该可以识别到扩好的容量,但是这步死活操作不成功,翻看kubernetes 的issues,说是个bug,在1.14解决,故升级kubernetes集群1.14,升级后,可以解决pv正确识别容量的问题,但是进入容器,发现挂载还是没有发生改变,再次google,发现rook 的issues说rook不支持ceph块设备自动扩容,额… 心里一万个mmp,最后尝试ceph resize 扩容后resize2fs才算真正扩容成功,以下是具体操作步骤
修改storageclass
1 | 增加:allowVolumeExpansion: true |
扩容pvc
1 | $ [K8sSj] kubectl edit pvc -n zlx resize-pvc |
查看pv,pvc
可以看到pv大小已经是2G,pvc还是1G
1
2
3
4
5
6 $ [K8sSj] kubectl get pv,pvc -n zlx
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-586fd31d-75ed-11e9-a901-26def9e195d0 2Gi RWO Delete Bound zlx/resize-pvc rook-ceph-block 127m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/resize-pvc Bound pvc-586fd31d-75ed-11e9-a901-26def9e195d0 1Gi RWO rook-ceph-block 127m
重启pod
1 | $ [K8sSj] kubectl delete -n zlx pod centos-5965946c94-9bc9p |
查看pvc的大小
1 | NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE |
进入容器查看挂载大小仍然是1G
1 | kubectl exec -it -n zlx centos-5965946c94-sx948 sh |
进入rook-ceph-tools 使用rbd扩容
1 | kubectl exec -it -n rook-ceph rook-ceph-tools-b8c679f95-llvmp sh |
查看挂载pvc的pod所在节点,进入节点刷新块设备
1 | kubectl get pod -n zlx -owide |
删除集群
删除使用pvc的pod 相关pvc/pv
删除rook-ceph资源
1 | kubectl delete -f cluster.yaml |
在各个节点删除rook数据目录
1 | rm -fr /var/lib/rook/* |
在各个节点重置磁盘
1 |
|
其他
1 | # replicapool 扩容 |
总结
其实kubernetes目前如果想要使用可以自动扩容的pv、pvc rook-ceph-rbd并不是一个很好的选择,可以考虑是用heketi-glusterfs、cephfs来代替,后续这边会讲到这两种方案的搭建,届时再比较这几种方案的优缺点。
- 本文作者: ChuLinx
- 本文链接: http://yoursite.com/2020/06/18/kubernetes_rook-ceph-rbd_搭建与扩容/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!