文章目录
- 前言
- StorageClass是什么
- 一、实验目的
- 配置过程
- 二、实验环境
- 实验步骤
- 一、配置网络存储NFS：
- 1.主机基础配置
- 2.配置 NFS:
- 二、开启rbac权限:
- 三、创建nfs-deployment.yaml
- 四、创建storageclass资源
- 五、验证：
- 1．创建PVC验证
- 2.创建一个pod验证
- 3．删除pod、pvc，pv会自动删除，nfs数据未删除
前言
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-provisionernamespace: 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_PATHvalue: /nfsdata volumes: - name: nfs-client-root nfs:server: 192.168.10.17path: /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: storageclassnamespace: test
provisioner: pro-test
#reclaimPolicy: Retain
reclaimPolicy: Delete
创建并查看
kubectl apply -f storageclass.yamlkubectl get sc
五、验证：
1．创建PVC验证
vim test-pvc1.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: test-pvc1namespace: test
spec:storageClassName: storageclassaccessModes:- ReadWriteManyresources: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-pod1namespace: test
spec:containers:- name: test-pod1image: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- sleep 3000volumeMounts:- name: nfs-pvmountPath: /testvolumes:- name: nfs-pvpersistentVolumeClaim: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/
实验完成
