【k8s配置与存储–持久化存储（PV、PVC、存储类）】 - 服务器托管|北京服务器租用|机房托管租用|IDC托管租用|机房机柜带宽租用-价格及费用咨询

1、PV与PVC 介绍

持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先制备，或者使用存储类（Storage Class）来动态制备。持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）。同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以挂载为 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod，请参阅访问模式）。

2、生命周期

2.1 构建

2.1.1 静态构建

集群管理员创建若干PV卷，这些卷对象带有直实存储的细节信息，并且对集群用户可用（可见）。PV卷对象存在于Kubernetes APl中，可供用户消费（使用）

2.1.2 动态构建

如果集群中已经有的PV无法满足PVC的需求，那么集群会根据PVC自动构建一个PV，该操作是通过StorageClass实现的。
想要实现这个操作，前提是PVC必须设置StorageClass,否则会无法动态构建该PV，可以通过启用DefaultStorageClass来实现PV的构建。

2.2 绑定（PV和PVC如何使用？）

当用户创建一个PVC对象后，主节点会监测新的PVC对象，并且寻找与之匹配的PV卷，找到PV卷后将二者绑定在一起。
如果找不到对应的PV，则需要看PVC是否设置StorageClass来决定是否动态创建PV，若没有配置，PVC就会一致处于未绑定状态，直到有与之匹配的PV后才会申领绑定关系。

2.4 使用（POD和PVC如何使用？）

Pod将PVC当作存储卷来使用。集群会通过PVC找到绑定的PV，并为Pod挂载该卷。
Pod一旦使用PVC绑定PV后，为了保护数据，避免数据丢失问题，PV对象会受到保护，在系统中无法披删除。

2.5 回收策略

当用户不再使用其存储卷时，他们可以从API中将PVC对象删除，从而允许该资源被回收再利用。PersistentVolume对象的回收策路告诉集群，当其被从申领中释放时如何处理该数据卷。
目前，数据卷可以被Retained(保留)、Recycled(回收)或Deleted(除)。

2.5.1 保留（Retain）

回收策路Retain使得用户可以主动回收资源。当PersistentVolumeClaim对象被删除时，PersistentVolume卷仍然存在，对应的数据卷被视为”已释放(released)”。由于卷上仍然存在这前一申领人的数据，该卷还不能用于其他申领。管理员可以通过下面的步家来手动回收该卷：
- 1.侧除PersistentVolume对象。与之相关的、位于外部基础设施中的存储资产（伤如AWS EBS、GCE PD、Azure Disk或Cinder卷)在PV删除之后仍然存在。
- 2.根据情况，手动清除所关联的存储资产上的数据。
- 3.手动删除所关联的存档资产
如果你希望重用该存储资产，可以基于存储资产的定义创建新的PersistentVolume卷对象。

2.5.2 删除（Delete）

对于支持Delete回收策路的卷插件，册除动作会将PersistentVolume对象从Kubernetes中移除，同时也会从外部础设施（如AWS EBS、GCE PD、Azure Disk或Cinder卷）中移除所关联的存储资产。动态制备的卷会继承基StorageClass中设置的回收策略，该策路默认为Delete。管理员需要根据用户的期望来配置StorageClass: 否则PV卷被创建之后必须要被偏辑或者修补。

服务器托管网

2.5.3 回收（Recycled）

警告：回收策路Recycle已被废弃。取而代之的建议方案是使用动态制备。
如果下层的卷插件支持，回收策路Recycle会在卷上执行一些基本的擦除 ( rm-f /thevolume/* )操作，之后允许该卷用于新的PVC申领。

3、PV

3.1 配置文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-01
spec:
  capacity:
    storage: 5Gi  # PV的容量
  volumeMode: Filesystem #存储类型为文件系统
  accessModes: # 访问模式：ReadWriteOnce、ReadWriteMany、ReadonlyMany
    - ReadWriteMany # 可被单节点独写
  persistentVolumeReclaimPolicy: Retain  # 回收策略
  storageClassName: slow   #创建PV的存储类名，需要与pvc的相同
  mountOptions: # 加载配置
    - hard
    - nfsvers=4.1
  nfs: # 连接到nfs
  path: /data/nfs/rw/pv-01  # 存储路径
  server: 10.10.10.100   # nfs服务地址

3.2 创建这个pv资源

[root@k8s-master pv]# kubectl create -f pv-01.yaml
persistentvolume/pv-01 created

3.3 查看PV的状态

Availabel：空闲，未被绑定
Bound：已经被PVC绑定
Released：PVC被删除，资源已回收，但是PV未被重新使用
Failed：自动回收失败

[root@k8s-master pv]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-01   5Gi        RWX            Retain           Available           slow                    16s

4、PVC

4.1 配置文件

PVC和PV绑定的时候需要注意yaml中这几个参数都需要一一对应
spec.accessModes： # 权限需要和对应的pv相同
spec.volumeMode： # 数据卷类型需要和pv相同
spec.resources.requests.storage： # 数据卷大小只能小于等于pv的大小，大于pv的大小也是无法匹配的。
spec.storageClassName： # 设置的属性名字必须和pv相同

apiVersion: v1
kind: PersistentVolumeClaim  # 资源类w为PVC
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany # 权限需要与对应的pv相同
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi # 资源可以小于pv的，但是不能大于，如果大于就会匹配不到pv
  storageClassName: slow # 名字需要与对应的pv相同
#    selector: # 使用选择器选择对应的pw
#      matchLabels:
#        release: "stable"
#      matchExpressions:
#        - {key:environment,operator:In,values:[dev]}

4.2 创建这个pvc资源

[root@k8s-master pv]# kubectl create -f pvc-01.yaml
persistentvolumeclaim/nfs-pvc created

4.3 查看PVC的状态

这里可以看到pvc的状态是Bound，并且挂在的数据卷是pv-01，他的属性是RWX（可读可写可执行）

[root@k8s-master pv]# kubectl get pvc
NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Bound    pv-01    5Gi        RWX            slow           6s

4.4 查看pv的状态

可以看到PV的状态已经变为了Bound（已经被PVC绑定）。

[root@k8s-master pv]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
pv-01   5Gi        RWX            Retain           Bound    default/nfs-pvc   slow                    16m

4.5 pod和pvc进行绑定

4.5.1 创建pod配置文件

apiVersion: v1
kind: Pod
metadata:
  name: nfs-pvc-pod
spec:
  containers:
  - image: nginx:1.20
    name: nginx-pvc
    volumeMounts:
    - mountPath: /usr/share/nginx/html   # 挂载到容器哪个目录
      name: nfs-pvc    # 挂载的数据卷的名字
  volumes:
  - name: nfs-pvc
    persistentVolumeClaim: # 关联PVC
      claimName: nfs-pvc   # 关联到那个pvc，填写这个pvc的名字

4.5.2 创建这个pod资源

[root@k8s-master pv]# kubectl create -f nfs-pvc-pod.yaml
pod/nfs-pvc-pod created

4.5.3 查看pod资源信息

[root@k8s-master pv]# kubectl get po   -o wide
NAME                           READY   STATUS      RESTARTS       AGE     IP          NODE          NOMINATED NODE   READINESS GATES
configfile-po                  0/1     Completed   0              21h     10.2.1.69   k8s-node-02   none>           none>
dns-test                       1/1     Running     2 (31h ago)    3d15h   10.2.1.58   k8s-node-02   none>           none>
emptydir-volume-pod            2/2     Running     34 (47m ago)   17h     10.2.1.72   k8s-node-02   none>           none>
fluentd-59k8k                  1/1     Running     1 (31h ago)    2d22h   10.2.2.34   k8s-node-01   none>           none>
fluentd-hhtls                  1/1     Running     1 (31h ago)    2d22h   10.2.1.59   k8s-node-02   none>           none>
host-volume-pod                1/1     Running     0              18h     10.2.1.71   k8s-node-02   none>           none>
nfs-pvc-pod                    1/1     Running     0              16s     10.2.1.73   k8s-node-02   none>           none>
nfs-volume-pod-1               1/1     Running     0              16h     10.2.2.41   k8s-node-01   none>           none>
nfs-volume-pod-2               1/1     Running     0              16h     10.2.2.42   k8s-node-01   none>           none>
nginx-deploy-6fb8d6548-8khhv   1/1     Running     24 (41m ago)   24h     10.2.1.67   k8s-node-02   none>           none>
nginx-deploy-6fb8d6548-fd9tx   1/1     Running     24 (41m ago)   24h     10.2.2.40   k8s-node-01   none>           none>

4.5.4 访问这个pod资源

由于创建的这个pv资源目录中没有文件信息，所以访问nginx服务的时候显示403。

[root@k8s-master pv]# curl 10.2.1.73
html>
head>title>403 Forbidden/title>/head>
body>
center>h1>403 Forbidden/h1>/center>
hr>center>nginx/1.20.2/center>
/body>
/html>

4.5.5 创建一个文件在pv共享目录中

[root@k8s-master pv]# echo "这个是个pvc挂载的文件"  >> /data/nfs/rw/pv-01/index.html

4.5.6 再次访问这个pod资源，显示出信息

[root@k8s-master pv]# curl 10.2.1.73
这个是个pvc挂载的文件

5、存储类 StorageClass

StorageClass 为管理员提供了描述存储”类”的方法。不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为”配置文件”。

5.1 制备器（Provisioner）

制备器是干啥的？
- 如果我们的服务越来越多，每次都需要先创建pv，然后创建pvc，最后创建资源。每次都得这么操作的话会很麻烦，k8s给我们提供了一种方式：制备器。
- 通过制备器，k8s可以根据我们的资源动态创建pv。
每个StorageClass都有一个制备器(Provisioner)，用来决定使用哪个卷插件制备PV。

5.2 动态制备器案例

5.2.1 创建Storageclass的配置文件（nfs-storage-class.yaml）

apiversion: storage.k8s.io/v1
kind: Storageclass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs  # 外部制备器提供者，编写为提供者的名称
parameters:
  archiveOnDelete: "false"  # 是否存档，false表示不存档，会删除oldPath下面的数据，true表示存档，会重命名路径
reclaimPolicy: Retain # 回收策略，默认为Delete可以配置为Retain
volumeBindingMode: Immediate   #  默认为Immediate,表示创建PVC立即进行绑定，只有 azuredisk 和 AWSelasticblockstore 支持其他值

5.2.2 创建provisioner的配置文件（nfs-provisioner-depolyment.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
spec:
  replicas: 1
  strategy:
    type: Recreate  
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-cLient-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      contaners:
      - name: nfs-client-provisioner
        image: quay.io/external_storage/nfs-client-provisioner:Latest
        volumeMounts:
          - name: nfs-client-root
            mountPath: /persistentvolumes   # 数据卷挂在到容器内的路径
        env:
          - name: PROVISIONER_NAME 
            value: fuseim.pri/ifs  
          - name: NFS_SERVER
            value: 10.10.10.100
          - name: NFS_PATH 
            value: /data/nfs/rw
      volumes: 
        - name: nfs-client-root
          nfs:
            server: 10.10.10.100
            path: /data/nfs/rw

5.2.3 创建provisioner的rbac配置文件（nfs-provisioner-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: [""]
  resources: ["endpoints"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- 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: kube-system
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: kube-system
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

5.2.4 创建nginx应用的配置文件（ nfs-sc-demo-statefulset.yaml）

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-sc
  labels:
    app: nginx-sc
spec:
  type: NodePort
  ports:
  - name: web
    port: 80
    protocol: TCP
  selector:
    app: nginx-sc
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-sc
spec:
  replicas: 1
  serviceName: "nginx-sc"
  selector:
    matchLabels:
      app: nginx-sc
  template:
    metadata:
      labels:
        app: nginx-sc
    spec:
      containers:
      - image: nginx
        name: nginx-sc
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /usr/share/nginx/html # 挂载到容器的哪个目录
          name: nginx-sc-test-pvc # 挂载哪个 volume
  volumeClaimTemplates:
  - metadata:
      name: nginx-sc-test-pvc
    spec:
      storageClassName: managed-nfs-storage
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 1Gi

[root@k8s-master sc]# ll
总用量 16
-rw-r--r--. 1 root root 1155 2月  27 20:20 nfs-provisioner-depolyment.yaml
-rw-r--r--. 1 root root 1460 2月  27 20:18 nfs-provisioner-rbac.yaml
-rw-r--r--. 1 root root  907 2月  27 20:23 nfs-sc-demo-statefulset.yaml
-rw-r--r--. 1 root root  154 2月  27 20:22 nfs-storage-class.yaml

5.2.5 权限初始化（provisioner-rbac）

[root@k8s-master sc]# kubectl apply  -f nfs-provisioner-rbac.yaml
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created

5.2.6 创建制备器（provisioner）

[root@k8s-master sc]# kubectl apply  -f nfs-provisioner-depolyment.yaml
serviceaccount/nfs-client-provisioner created
deployment.apps/nfs-client-provisioner created

[root@k8s-master sc]# kubectl get serviceaccounts     -n kube-system    | grep nfs
nfs-client-provisioner               0         2m18s

[root@k8s-master sc]# kubectl get deployments.apps    -n kube-system
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
coredns                  2/2     2            2           7d22h
metrics-server           1/1     1            1           2d23h
nfs-client-provisioner   0/1     1            0           25s

5.2.7 创建存储类（Storageclass）

[root@k8s-master sc]# kubectl apply  -f nfs-storage-class.yaml
storageclass.storage.k8s.io/managed-nfs-storage created
[root@k8s-master sc]# kubectl get sc
NAME                  PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  6s

5.2.8 创建应用nginx资源

[root@k8s-master sc]# kubectl  create -f nfs-sc-demo-statefulset.yaml
service/nginx-sc created
statefulset.apps/nginx-sc created
[root@k8s-master sc]# kubectl get svc
NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)        AGE
csdn-svc-external-domian   ExternalName   none>         www.lan-he.com.cn   none>         2d7h
kubernetes                 ClusterIP      10.1.0.1       none>              443/TCP        7d22h
nginx-sc                   NodePort       10.1.94.155    none>              80:31819/TCP   7s
nginx-svc                  NodePort       10.1.224.211   none>              80:31231/TCP   2d22h
nginx-svc-external         ClusterIP      10.1.63.181    none>              80/TCP         2d17h
[root@k8s-master sc]# kubectl get  po
NAME                           READY   STATUS      RESTARTS       AGE
configfile-po                  0/1     Completed   0              23h
dns-test                       1/1     Running     2 (32h ago)    3d17h
emptydir-volume-pod            2/2     Running     38 (40m ago)   19h
fluentd-59k8k                  1/1     Running     1 (32h ago)    3d
fluentd-hhtls                  1/1     Running     1 (32h ago)    3d
host-volume-pod                1/1     Running     0              20h
nfs-volume-pod-1               1/1     Running     0              18h
nfs-volume-pod-2               1/1     Running     0              18h
nginx-deploy-6fb8d6548-8khhv   1/1     Running     26 (35m ago)   26h
nginx-deploy-6fb8d6548-fd9tx   1/1     Running     26 (35服务器托管网m ago)   26h
nginx-sc-0                     0/1     Pending     0              52s

5.2.9 pod和pvc的状态都是Pending，pv并没有被创建出来

# pod的状态是Pending
[root@k8s-master sc]# kubectl get po | grep -E 'NAME|nginx-sc'
NAME                           READY   STATUS      RESTARTS       AGE
nginx-sc-0                     0/1     Pending     0              6m34s

#  pvc的状态也是Pending
[root@k8s-master sc]# kubectl get pvc
NAME                           STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS          AGE
nginx-sc-test-pvc-nginx-sc-0   Pending                                      managed-nfs-storage   7m59s

#  pv是没有动态创建出来的
[root@k8s-master sc]# kubectl get pv
No resources found

5.2.10 查看下pod的日志

[root@k8s-master sc]# kubectl describe po nginx-sc-0
Name:             nginx-sc-0
Namespace:        default
Priority:         0
Service Account:  default
Node:             none>
Labels:           app=nginx-sc
                  controller-revision-hash=nginx-sc-865bd98db8
                  statefulset.kubernetes.io/pod-name=nginx-sc-0
Annotations:      none>
Status:           Pending
IP:
IPs:              none>
Controlled By:    StatefulSet/nginx-sc
Containers:
  nginx-sc:
    Image:        nginx
    Port:         none>
    Host Port:    none>
    Environment:  none>
    Mounts:
      /usr/share/nginx/html from nginx-sc-test-pvc (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-2kv55 (ro)
Conditions:
  Type           Status
  PodScheduled   False
Volumes:
  nginx-sc-test-pvc:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  nginx-sc-test-pvc-nginx-sc-0
    ReadOnly:   false
  kube-api-access-2kv55:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  8m57s  default-scheduler  0/3 nodes are available: 3 pod has unbound immediate PersistentVolumeClaims. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.
  Warning  FailedScheduling  8m56s  default-scheduler  0/3 nodes are available: 3 pod has unbound immediate PersistentVolumeClaims. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

5.2.11 为啥没有创建出pv？

这就涉及到一个版本的问题，目前使用的k8s的版本是1.25，刚才创建的制备器镜像（registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:latest ）这个版本涉及到需要使用k8s的一个功能叫SelfLink，但是从k8s v1.20以后它就把这个功能给禁用了，出于对性能、api调用请求方向的考虑。

5.2.11.1 解决方案1—-配置SelfLink

修改api-server 配置文件：/etc/kuberetes/manifests/kube-apiserver.yaml

spec:
  containers:
    - command:
      - kube-apiserver:
      - ---feature-gates=RemoveSelfLink: =false   # 新增该行

修改后重新应用改配置
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

5.2.11.2 解决方案2—-修改镜像版本

registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0

重新加载下配置

[root@k8s-master sc]# kubectl apply -f nfs-provisioner-depolyment.yaml
serviceaccount/nfs-client-provisioner unchanged
deployment.apps/nfs-client-provisioner configured

5.2.12 这次pv就自动创建好了

# 应用的状态
[root@k8s-master sc]# kubectl get po  | grep -Ei 'name|nginx-sc'
NAME                           READY   STATUS      RESTARTS       AGE
nginx-sc-0                     1/1     Running     0              27m

# pv的状态
[root@k8s-master sc]# kubectl get pvc
NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
nginx-sc-test-pvc-nginx-sc-0   Bound    pvc-070c2e12-e5ef-47fe-bbbb-c5f864e311b5   1Gi        RWX            managed-nfs-storage   27m

# pv的状态
[root@k8s-master sc]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                  STORAGECLASS          REASON   AGE
pvc-070c2e12-e5ef-47fe-bbbb-c5f864e311b5   1Gi        RWX            Delete           Bound    default/nginx-sc-test-pvc-nginx-sc-0   managed-nfs-storage            119s


# 制备器的状态
[root@k8s-master sc]# kubectl get po -n kube-system   | grep -E 'NAME|nfs'
NAME                                      READY   STATUS    RESTARTS       AGE
nfs-client-provisioner-64f976f4cd-7gdq7   1/1     Running   0              4m36s

5.3 动态创建pv测试配置

5.3.1 配置文件

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: auto-pv-test-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 300Mi
  storageClassName: managed-nfs-storage

5.3.2 动态创建PV

[root@k8s-master sc]# kubectl apply  -f auto-pv-test-pvc.yaml
persistentvolumeclaim/auto-pv-test-pvc created


[root@k8s-master sc]# kubectl get pvc
NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
auto-pv-test-pvc               Bound    pvc-61e8aa2c-9d94-4404-bca6-909f31898638   300Mi      RWO            managed-nfs-storage   6s
nginx-sc-test-pvc-nginx-sc-0   Bound    pvc-070c2e12-e5ef-47fe-bbbb-c5f864e311b5   1Gi        RWX            managed-nfs-storage   37m

[root@k8s-master sc]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                  STORAGECLASS          REASON   AGE
pvc-070c2e12-e5ef-47fe-bbbb-c5f864e311b5   1Gi        RWX            Delete           Bound    default/nginx-sc-test-pvc-nginx-sc-0   managed-nfs-storage            11m
pvc-61e8aa2c-9d94-4404-bca6-909f31898638   300Mi      RWO            Delete           Bound    default/auto-pv-test-pvc               managed-nfs-storage            10s

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: C++单例模式详解

目录 0. 前言 1. 懒汉式单例模式 1.1 最简单的单例模式 1.2 防止内存泄服务器托管网漏 1.2.1 智能指针的方法 1.2.2 静态嵌套的方法 1.3 保证线程安全 1.4 C++11版本的优雅解决方案 2. 饿汉式单例模式 0. 前言起因是在程…

1、PV与PVC 介绍

2、生命周期

2.1 构建

2.1.1 静态构建

2.1.2 动态构建

2.2 绑定（PV和PVC如何使用？）

2.4 使用（POD和PVC如何使用？）

2.5 回收策略

2.5.1 保留（Retain）

2.5.2 删除（Delete）

2.5.3 回收（Recycled）

3、PV

3.1 配置文件

3.2 创建这个pv资源

3.3 查看PV的状态

4、PVC

4.1 配置文件

4.2 创建这个pvc资源

4.3 查看PVC的状态

4.4 查看pv的状态

4.5 pod和pvc进行绑定

4.5.1 创建pod配置文件

4.5.2 创建这个pod资源

4.5.3 查看pod资源信息

4.5.4 访问这个pod资源

4.5.5 创建一个文件在pv共享目录中

4.5.6 再次访问这个pod资源，显示出信息

5、存储类 StorageClass

5.1 制备器 （Provisioner）

5.2 动态制备器案例

5.2.1 创建Storageclass的配置文件（nfs-storage-class.yaml）

5.2.2 创建provisioner的配置文件 （nfs-provisioner-depolyment.yaml）

5.2.3 创建provisioner的rbac配置文件 （nfs-provisioner-rbac.yaml）

5.2.4 创建nginx应用的配置文件（ nfs-sc-demo-statefulset.yaml）

5.2.5 权限初始化 （provisioner-rbac）

5.2.6 创建制备器 （provisioner）

5.2.7 创建存储类 （Storageclass）

5.2.8 创建应用nginx资源

5.2.9 pod和pvc的状态都是Pending，pv并没有被创建出来

5.2.10 查看下pod的日志

5.2.11 为啥没有创建出pv？

5.2.11.1 解决方案1—-配置SelfLink

5.2.11.2 解决方案2—-修改镜像版本

5.2.12 这次pv就自动创建好了

5.3 动态创建pv测试配置

5.3.1 配置文件

5.3.2 动态创建PV

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用

5.1 制备器（Provisioner）

5.2.2 创建provisioner的配置文件（nfs-provisioner-depolyment.yaml）

5.2.3 创建provisioner的rbac配置文件（nfs-provisioner-rbac.yaml）

5.2.5 权限初始化（provisioner-rbac）

5.2.6 创建制备器（provisioner）

5.2.7 创建存储类（Storageclass）