k8s练习--StorageClass详细解释与应用
简单理解由于在大型环境应用部署环境中,利用静态方式创建大量的pv是很麻烦的事情,所以为了方便运维人员,我们可以使用StorageClassstorageclass是一种网络存储的动态供给方式,它通过连接存储插件,根据PVC的消费需求,动态生成PV,从而实现方便管理的效果。详细解释在 Kubernetes 中,StorageClass 是一种抽象,用于定义不同存储提供者的存储配置。它提供了一种灵活的
文章目录
前言
StorageClass是什么
简单理解
由于在大型环境应用部署环境中,利用静态方式创建大量的pv是很麻烦的事情,所以为了方便运维人员,我们可以使用StorageClass
storageclass是一种网络存储的动态供给方式,它通过连接存储插件,根据PVC的消费需求,动态生成PV,从而实现方便管理的效果。
详细解释
在 Kubernetes 中,StorageClass 是一种抽象,用于定义不同存储提供者的存储配置。它提供了一种灵活的方式来管理和动态分配存储资源。StorageClass 允许集群管理员定义不同类型的存储(例如 SSD、HDD、网络存储等),以及不同的存储配置(例如不同的性能和备份策略)。
StorageClass 的核心概念
Provisioner(供应者):
Provisioner 是指具体的存储插件,用于创建实际的存储卷。例如,常见的 Provisioner 包括 kubernetes.io-ebs(AWS 的 EBS 卷)、kubernetes.io/gce-pd(Google Cloud 的 Persistent Disk)、kubernetes.io/nfs(NFS 存储)等。
Parameters(参数):
Parameters 定义了存储类的具体配置选项。这些参数因不同的 Provisioner 而异。例如,对于 AWS EBS,可能包括卷的类型(如 gp2、io1)、I/O 性能参数等。
ReclaimPolicy(回收策略):
ReclaimPolicy 定义了当持久卷(PersistentVolume)不再使用时该如何处理。常见的策略包括:
Retain:
保留卷和数据,需要手动处理。
Delete:
删除卷和数据。
Recycle:
清空卷并重新用于其他请求(注意,这种策略已经不推荐使用)。
MountOptions(挂载选项):
这些选项指定了挂载卷时使用的挂载参数。例如,可以指定文件系统的挂载选项来优化性能或可靠性。
VolumeBinding(卷绑定模式):
VolumeBinding 控制卷绑定的时机,通常有两种模式:
Immediate:
立即绑定卷,默认模式。
ForFirst:
等待第一个消费者(Pod)请求时再绑定卷,适用于需要考虑 Pod 调度位置的场景。
一、实验目的
验证k8s中StorageClass的动态生产pv
配置过程
(1) 配置网络存储—>
(2) 开启账号访问权限(创建账号、创建权限、给账号关联权限)—>
(3) 通过中间件将账号与共享存储关联—>
(4) 配置StorageClass与中间件关联—>
(5) 创建PVC关联StorageClass—>
(6) 创建pod关联pvc,动态生成pv
(7) 验证
二、实验环境
Ip | 主机名 | cpu | 内存 | 硬盘 |
---|---|---|---|---|
192.168.10.11 | master | 1cpu双核 | 2G | 40G |
192.168.10.12 | node01 | 1cpu双核 | 2G | 40G |
192.168.10.13 | node02 | 1cpu双核 | 2G | 40G |
192.168.10.17 | nfs | 1cpu1核 | 1G | 40G |
虚拟机 centos7.9
master node01 node02 已部署k8s集群
版本 1.18.0
nfs服务器部署nfs
实验步骤
一、配置网络存储NFS:
1.主机基础配置
由于nfs是新创建的虚拟机需要关闭防火墙,关闭沙盒
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux
2.配置 NFS:
所有主机都需要安装nfs
yum -y install nfs-utils rpcbind
其次在nfs主机上
mkdir /nfsdata
vim /etc/exports
输入
/nfsdata *(rw,sync,no_root_squash)
systemctl start rpcbind
systemctl start nfs-server
systemctl enable rpcbind
systemctl enable nfs-server
showmount -e
看到这个nfs就部署成功了
二、开启rbac权限:
RBAC(Role-Based Access Control):基于角色的访问控制
vim account.yaml
kind: Namespace
apiVersion: v1
metadata:
name: test #自定义了一个名称空间
---
apiVersion: v1
kind: ServiceAccount #服务类账号
metadata:
name: nfs-provisioner #创建账号 nfs-provisioner
namespace: test #指定好自定义的名称空间。
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole #集群类的角色
metadata:
name: nfs-provisioner-runner
namespace: test
rules: #规则,指定有什么样的权限
- apiGroups: [""] #“”不写代表对所有api组具有的权限
resources: ["persistentvolumes"] #对pv可以进行什么样的操作
verbs: ["get", "list", "watch", "create", "delete"] #有获得,创建,删掉等 等权限
- apiGroups: [""]
resources: ["persistentvolumeclaims"] #pvc有什么样的权限
verbs: ["get", "list", "watch", "update"] #具体权限
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["services", "endpoints"]
verbs: ["get","create","list", "watch","update"]
- apiGroups: ["extensions"]
resources: ["podsecuritypolicies"]
resourceNames: ["nfs-provisioner"]
verbs: ["use"]
---
kind: ClusterRoleBinding #cluster开头的指的都是整个k8s的权限范围,在集群内都生效
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-provisioner
subjects:
- kind: ServiceAccount
name: nfs-provisioner
namespace: test
roleRef:
kind: ClusterRole
name: nfs-provisioner-runner
apiGroup: rbac.authorization.k8s.io
简单注释
这个 YAML 文件定义了一个 Kubernetes 命名空间 test,在其中创建了一个名为 nfs-provisioner 的服务账号,并为该账号设置了一组权限规则,允许其对持久卷、持久卷声明、存储类等资源进行特定操作。最后,通过集群角色绑定将权限规则与服务账号进行了关联,使得该账号能够在指定命名空间内执行相应的操作。
执行这个yaml文件,看到三个created就是运行成功了,如果报错仔细查看,大概率是字符错误
kubectl apply -f nfs-deployment.yaml
获取命名空间 test 中的服务账号,可以看到已经存在
kubectl -n test get serviceaccounts
三、创建nfs-deployment.yaml
通过中间件将访问账号与共享存储关联
vim nfs-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
namespace: test
spec:
selector:
matchLabels:
app: nfs-client-provisioner
replicas: 1
strategy:
type: Recreate
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccount: nfs-provisioner #nfs-provisioner为已创建的服务类账号
containers:
- name: nfs-client-provisioner
image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner #中间件镜像
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: pro-test
- name: NFS_SERVER
value: 192.168.10.17
- name: NFS_PATH
value: /nfsdata
volumes:
- name: nfs-client-root
nfs:
server: 192.168.10.17
path: /nfsdata
简单注释
在 Kubernetes 集群中部署了一个 NFS 客户端 provisioner,用于动态创建持久卷,并将其挂载到容器中,以便应用程序可以访问 NFS 服务器上的数据。
创建然后查看一下,看到即可
kubectl apply -f nfs-deployment.yaml
kubectl -n test get pod
四、创建storageclass资源
vim storageclass.yaml
(配置storageclass与中间件关联)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: storageclass
namespace: test
provisioner: pro-test
#reclaimPolicy: Retain
reclaimPolicy: Delete
创建并查看
kubectl apply -f storageclass.yaml
kubectl get sc
五、验证:
1.创建PVC验证
vim test-pvc1.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-pvc1
namespace: test
spec:
storageClassName: storageclass
accessModes:
- ReadWriteMany
resources:
requests:
storage: 200Mi
创建并查看
kubectl apply -f test-pvc1.yaml
kubectl -n test get pv,pvc
nfs服务器上查看
ls /nfsdata/
查看pod容器挂载目录,目录中无文件
[root@master ~]# kubectl -n test exec -it nfs-client-provisioner-5878bf7b9c-2294l /bin/sh
/ # ls persistentvolumes/
test-test-pvc1-pvc-1738bcd6-3d9b-49f6-9005-3eee8e61eae6
/ # ls persistentvolumes/test-test-pvc1-pvc-1738bcd6-3d9b-49f6-9005-3eee
8e61eae6/
/ #exit
2.创建一个pod验证
vim test-pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod1
namespace: test
spec:
containers:
- name: test-pod1
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- sleep 3000
volumeMounts:
- name: nfs-pv
mountPath: /test
volumes:
- name: nfs-pv
persistentVolumeClaim:
claimName: test-pvc1
kubectl apply -f test-pod1.yaml
kubectl get pod -n test
向pod1中写入文件测试
kubectl exec -it -n test test-pod1 -- touch /test/test1.txt
nfs服务器上查看:
ls /nfsdata/test-test-pvc1-pvc-1738bcd6-3d9b-49f6-9005-3eee8e61eae6/
3.删除pod、pvc,pv会自动删除,nfs数据未删除
kubectl -n test get pv,pvc
查看nfs会发现目录名发生变化,但数据还在
ls /nfsdata/archived-test-test-pvc1-pvc-1738bcd6-3d9b-49f6-9005-3eee8e61eae6/
实验完成
更多推荐
所有评论(0)