k8s中pv创建的两种方式：静态创建pv和动态创建pv---基于nfs创建

2301_78571402

已于 2024-05-17 17:09:01 修改

阅读量1.8k

点赞数 36

文章标签： kubernetes 容器云原生

于 2024-05-17 16:20:37 首次发布

本文链接：https://blog.csdn.net/2301_78571402/article/details/139005437

版权

一、主要区别

在Kubernetes中，静态创建PV和动态创建PV是两种不同的方式来为应用程序提供持久化存储。

静态创建PV：手动创建
- 静态创建PV是在集群级别手动创建PV对象，并将其与存储后端进行绑定。
- 静态创建PV需要手动配置和管理PV资源，包括指定存储的类型、容量、访问模式等。
- 应用程序可以通过声明式的方式使用静态创建的PV，通过将PVC（Persistent Volume Claim）与静态创建的PV进行绑定。
- 静态创建PV适用于已知的、固定的存储资源，并且需要手动管理PV对象。
动态创建PV：自动创建
- 动态创建PV是在集群级别使用StorageClass和Provisioner来自动创建PV对象。
- 动态创建PV不需要手动配置和管理PV资源，而是通过StorageClass指定存储的类型和配置，并由Provisioner自动创建和管理PV对象。
- 应用程序可以通过声明式的方式使用动态创建的PV，通过将PVC与指定的StorageClass进行绑定。
- 动态创建PV适用于可扩展的、动态分配的存储资源，使用者只需声明所需的存储要求，而无需关心具体的存储配置和管理。

总结：

静态创建PV需要手动配置和管理PV对象，适用于已知的、固定的存储资源。
动态创建PV通过StorageClass和Provisioner自动创建和管理PV对象，适用于可扩展的、动态分配的存储资源。

二、操作步骤

（一）安装nfs

所有节点执行：

yum install -y nfs-utils
systemctl start rpcbind && systemctl enable rpcbind

systemctl start nfs && systemctl enable nfs

master节点执行：（创建共享目录，并给予777权限）

mkdir /root/nfs （共享的目录的名称自定义）
chmod 777 /root/nfs

vim /etc/exports（编辑共享配置，配置一下NFS的文件）
写入内容：/root/nfs 192.168.89.0/24(rw,no_root_squash,sync)
注意：IP这块可以写具体ip（安装nfs的ip地址）也可以写ip段

配置生效：exportfs -rv

查看本机共享目录：showmount -e

（二）静态创建pv

1、创建pv.yaml

vim pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
storageClassName: nfs
nfs:
path: /root/nfs（自己创建的共享目录地址）
server: 192.168.89.66（nfs部署的IP地址）

kubectl apply -f pv.yaml
kubectl get pv 查看一下

2、编写pvc.yaml文件

vim pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteOnce（这里要与上面的accessModes保持一致）
resources:
requests:
storage: 1Gi
storageClassName: nfs（此处与上面pv的storageClassName保持一致）

kubectl apply -f pvc.yaml
kubectl ge pvc #查看一下

可以发现上面绿色部分内容都是相一致的，这样pv才可以符合pvc的要求进行，就会绑定

（三）动态创建pv

基于storageclass来动态创建

1、先创建StorageClass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-storage
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
archiveOnDelete: "false"

2、创建ServiceAccount.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default

3、创建rbac.yaml
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-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"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io

4、创建deployment.yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: nfs-client-provisioner
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/nfs-subdir-external-provisioner:v4.0.2
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: k8s-sigs.io/nfs-subdir-external-provisioner #此处和StorageClass.yaml文件中的provisioner保持一致
- name: NFS_SERVER
value: 192.168.89.66 #安装nfs的主机ip地址
- name: NFS_PATH
value: /root/nfs #共享目录的位置
volumes:
- name: nfs-client-root
nfs:
server: 192.168.89.66 #安装nfs的主机ip地址
path: /root/nfs #共享目录的位置

5、创建pvc.yaml，进行测试

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-test
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi

以上yaml文件总结完毕

创建这些文件的目的是为了在Kubernetes集群中实现动态创建Persistent Volume（PV）的功能。下面是这些文件的作用及它们之间的关联：

ServiceClass：定义了可用的存储类别，例如标准的块存储或文件存储等。它描述了提供存储的插件和驱动程序。
ServiceAccount：用于为相关的Pod提供身份验证和授权。它定义了一组权限，使得Pod可以执行与存储系统交互的操作。
ClusterRole和ClusterRoleBinding：ClusterRole定义了一组权限，允许对整个集群范围内的资源进行操作。ClusterRoleBinding将ClusterRole与ServiceAccount关联起来，使得ServiceAccount可以使用ClusterRole中定义的权限。
Role和RoleBinding：与ClusterRole和ClusterRoleBinding类似，但是作用范围是命名空间级别而不是整个集群。它们用于限制存储操作在特定命名空间中的范围。

以上这些文件的创建是为了在Kubernetes中建立一套权限和授权机制，以便Pod可以通过ServiceAccount拥有访问存储资源的权限。这样，在动态创建PV时，Pod可以通过与ServiceAccount和相应的ClusterRole或Role进行关联，获得访问存储资源的权限。

当这些文件正确创建和关联后，可以使用Kubernetes的动态存储卷插件（CSI）来创建PV。Pod通过声明所需的存储类别（ServiceClass）和访问权限（ServiceAccount）来请求动态创建PV。Kubernetes将根据Pod的请求和集群中可用的存储插件来动态创建PV，并将其与Pod绑定，以供其使用。

综上所述，这些文件的创建和关联是为了建立一套权限和授权机制，使得Pod可以在需要时动态创建PV，并访问这些PV提供的存储资源。

最后：

kubectl apply -f 各yaml文件的名称

kubectl get 资源名称 # 查看一下各资源是否创建成功

动态创建pv总结：

最后你可以从操作的过程的结果来看，如pvc声明需要1Gi的空间，便会自动创建了1Gi的pv（无需手动创建），且状态会为Bound，则表示创建成功。

文章总结：以上是操作完毕后的一个简易的回忆总结，并不是模范步骤，所以并没有截图上图片，只是为了在脑海中把过程再走一遍，印象更深刻一点，所以大家可参考且谨慎粘贴复制，再根据自己实际情况进行修改，如以上文件中有问题的地方，还请见谅指出。大致的步骤应该是这么多，只是需要细心里面需要修改的信息，修改正确，能关联上即可成功。后续如有机会再操作的时候，会不断更新更正该文章~