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

一、主要区别

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

1. 静态创建PV：手动创建

   • 静态创建PV是在集群级别手动创建PV对象，并将其与存储后端进行绑定。
   • 静态创建PV需要手动配置和管理PV资源，包括指定存储的类型、容量、访问模式等。
   • 应用程序可以通过声明式的方式使用静态创建的PV，通过将PVC（Persistent Volume Claim）与静态创建的PV进行绑定。
   • 静态创建PV适用于已知的、固定的存储资源，并且需要手动管理PV对象。

2. 动态创建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）的功能。下面是这些文件的作用及它们之间的关联：

1. ServiceClass：定义了可用的存储类别，例如标准的块存储或文件存储等。它描述了提供存储的插件和驱动程序。

2. ServiceAccount：用于为相关的Pod提供身份验证和授权。它定义了一组权限，使得Pod可以执行与存储系统交互的操作。

3. ClusterRole和ClusterRoleBinding：ClusterRole定义了一组权限，允许对整个集群范围内的资源进行操作。ClusterRoleBinding将ClusterRole与ServiceAccount关联起来，使得ServiceAccount可以使用ClusterRole中定义的权限。

4. 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，则表示创建成功。

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