kubernetes集群系列资料13--存储机制介绍

一、K8S存储机制介绍  

　　k8s的stateful控制组件是为有状态服务而设计的，有状态服务需要对数据进行存储；k8s有4种存储机制，主要为：

　　1)configMap：为K8S存储配置文件而设计的，configMap可以用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象。
　　2)secret：为了解决密码、token、密钥等敏感数据的配置加密而设计，而不需要将这些敏感数据暴露到镜像或pod.spec中，可以volume或环境变量的方式使用。
　　3)volume：为容器提供共享存储卷，避免发生容器崩溃重启后容器中文件丢失的问题。当pod不存在时，volume也不复存在；k8s支持多种类型的卷，pod可使用任意数量的卷。
　　4)persistentVolume/persistentVolumeClai：

二、configMap介绍

　　许多应用程序从配置文件、命令行参数或环境变量中读取配置信息，而configMap API给我们提供了向容器注入配置信息的机制。
　　传统生成环境中，配置文件注册中心负责向n个集群n个节点应用程序的提供配置信息，该中心需要自行构建，没有较好的开源方案。应用程序向配置文件注册中心提供本节点的信息（如：IP、hostname），配置文件注册中心根据规则为该节点应用程序更新配置，应用程序按照新配置进行重载后运行。
　　k8s集群中，configMap充当了配置文件注册中心的作用。pod向configMap申请配置，configMap为各pod下发不同的配置。
　　configMap创建配置有3中方式：使用目录创建、使用文件创建、使用字面值创建。

1、使用目录创建configMap

mkdir configMapFile;cd configMapFile
cat > game.properties <<eof
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
enemies.code.passphrase=UUDDLRLRBABAS
enemies.code.allowed=true
enemies.code.lives=30
eof

cat >ui.properties<<eof
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
eof

kubectl create configmap game-config --from-file=../configMapFile #创建configMap；
kubectl get configmap               #查看configMap；
kubectl get cm game-config -o yaml  #以yaml格式输出game-config配置；
kubectl get cm game-config -o json    #以yaml格式输出game-config配置；

 2、使用文件创建configMap

kubectl create configmap game-config2 --from-file=../configMapFile/game.properties #使用文件创建configMap；
kubectl get cm game-config2 -o yaml

  多次使用文件创建，与在该目录下一次性批量创建效果相同。

3、使用字面量创建configMap

kubectl create configmap game-config3 --from-literal=special.how=very --from-literal=special.type=charm #使用字面量创建configMap；
kubectl get cm game-config3 -o yaml

4、案例：使用configMap向pod注入环境变量

cat >special-config.yaml<<eof
apiVersion: v1
kind: ConfigMap
metadata:
    name: special-config
    namespace: default
data:
    special.how: very
    special.type: charm
eof
kubectl apply -f special-config.yaml #使用yaml文件创建configMap;

cat >env-config.yaml<<eof
apiVersion: v1
kind: ConfigMap
metadata:
    name: env-config
    namespace: default
data:
    log_level: INFO
eof
kubectl apply -f env-config.yaml

cat >pod_configMapTest.yaml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: dapi-test-pod
    namespace: default
spec:
    containers:
        - name: test-container
          image: hub.atguigu.com/library/nginx:latest
          command: ["/bin/sh","-c","env"]
          env:                              #设置pod环境变量；
            - name: SPECIAL_LEVEL_KEY
              valueFrom:                    #向pod环境变量注入special-config配置中某个键的值；
                configMapKeyRef:
                    name: special-config
                    key: special.how
            - name: SPECIAL_TYPE_KEY
              valueFrom:
                configMapKeyRef:
                    name: special-config
                    key: special.type
          envFrom:                          #向pod注入env.config配置中所有键值对；
            - configMapRef:
                name: env-config
    restartPolicy: Never
eof
kubectl apply -f pod_configMapTest.yaml

验证结果显示：环境变量包含导入的变量SPECIAL_LEVEL_KEY、SPECIAL_TYPE_KEY、log_level。

 5、案例：通过volume来使用configMap

cat >pod_configMapTest_1.yaml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: dapi-test-pod-1
    namespace: default
spec:
    containers:
    - name: test-container
      image: hub.atguigu.com/library/nginx:latest
      command: ["/bin/sh","-c","ls /etc/config/"]
      volumeMounts:                     #指定挂载卷；
        - name: config-volume           #指定挂载卷名称；
          mountPath: /etc/config        #指定挂载卷挂载点；
    volumes:
        - name: config-volume
          configMap:
            name: special-config        #将configMap导入pod的volume中，有不同的选型。基本方式为：将文件填入volume，键以文件名显示，值以内容显示；
    restartPolicy: Never
eof
kubectl apply -f pod_configMapTest_1.yaml

5、案例：configMap热更新

cat >config_update_test.yaml<<eof
apiVersion: v1
kind: ConfigMap
metadata:
    name: log-config
    namespace: default
data:
    log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: my-nginx
    namespace: default
spec:
    replicas: 1
    template:
        metadata:
            labels:
                run: my-nginx
        spec:
            containers:
            - name: my-nginx
              image: hub.atguigu.com/library/nginx:latest
              ports:
              - containerPort: 80
              volumeMounts:                     #指定挂载卷；
                - name: config-volume           #指定挂载卷名称；
                  mountPath: /etc/config        #指定挂载卷挂载点；
            volumes:
                - name: config-volume
                  configMap:
                    name: log-config        #将configMap导入pod的volume中，有不同的选型。基本方式为：将文件填入volume，键以文件名显示，值以内容显示；
            restartPolicy: Always
eof
kubectl apply -f config_update_test.yaml
kubectl exec $(kubectl get pod -l run=my-nginx -o=name |cut -d "/" -f2) -it -- cat /etc/config/log_level #查看导入pod的configMap配置，该值以volume文件存在；

验证结果：配置写入volume的log_level文件。

 

6、案例：configMap热更新

cat >config_update_test.yaml<<eof
apiVersion: v1
kind: ConfigMap
metadata:
    name: log-config
    namespace: default
data:
    log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: my-nginx
    namespace: default
spec:
    replicas: 1
    template:
        metadata:
            labels:
                run: my-nginx
        spec:
            containers:
            - name: my-nginx
              image: hub.atguigu.com/library/nginx:latest
              ports:
              - containerPort: 80
              volumeMounts:                     #指定挂载卷；
                - name: config-volume           #指定挂载卷名称；
                  mountPath: /etc/config        #指定挂载卷挂载点；
            volumes:
                - name: config-volume
                  configMap:
                    name: log-config        #将configMap导入pod的volume中，有不同的选型。基本方式为：将文件填入volume，键以文件名显示，值以内容显示；
            restartPolicy: Always
eof
kubectl apply -f config_update_test.yaml
kubectl exec $(kubectl get pod -l run=my-nginx -o=name |cut -d "/" -f2) -it -- cat /etc/config/log_level #查看导入pod的configMap配置，该值以volume文件存在；
kubectl edit configmap log-config #修改configMap配置log_level值改为DEBUG；
kubectl patch deployment my-nginx --patch '{"spec":{"template":{"metadata":{"annotations":{"version/config":"20210618 14:53:00"}}}}}' #手动指定20210618 14:53:00重新加载配置文件，以便配置文件生效；
kubectl exec $(kubectl get pod -l run=my-nginx -o=name |cut -d "/" -f2) -it -- cat /etc/config/log_level #查看log_level值是否修改；

验证结果：configMap配置已热更新。

 三、secret介绍 

service Account：用来访问K8S API，由K8S自动创建，并且会自动挂载到pod的/run/secrets/kubernetes.io/serviceaccount目录中；对于有些pod（如coreDNS、flannel）来说，需要与K8S API进行交互，K8S API不是谁都可以访问的，必须通过挂载SA后pod才能访问K8S API；

opaque：base64编码格式的secret，用来存储密码、密钥等；opaque类型的数据是一个map类型，要求value是base64编码格式；
kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息；

1、SA案例

kubectl run nginx --image nginx #创建名为nginx的depoloyment及pod；
kubectl get deployment;kubectl get pods
kubectl exec nginx-7bb7cd8db5-czg6s ls /run/secrets/kubernetes.io/serviceaccount #查看sa的默认挂载的目录；
kubectl get secret -n kube-system #查看集群自动创建的secret；

 2、opaque案例

　

echo -n 'admin' |base64 	#输出以base64加密结果为YWRtaW4=;
echo -n '1qaz@WSX' |base64 	#输出以base64加密结果为MXFhekBXU1g=;
echo -n 'YWRtaW4=' |base64 -d  #输出YWRtaW4=的解密结果为admin;
cat >secret.yml<<eof
apiVersion: v1
kind: Secret
metadata:
    name: mysecret
data:
    username: YWRtaW4=
    password: MXFhekBXU1g=
eof
kubectl apply -f secret.yml
kubectl get secret
#将secret挂载到volume中
cat >secret-pod.yml<<eof
apiVersion: v1
kind: Pod
metadata:
    labels:
        name: secret-test
    name: secret-test
spec:
    volumes:
    - name: secrets
      secret:
        secretName: mysecret
    containers:
    - image: hub.atguigu.com/library/nginx:latest
      name: db
      volumeMounts:
      - name: secrets
        mountPath: '/etc/secrets'
        readOnly: true
eof
kubectl apply -f secret-pod.yml
kubectl get pod
kubectl exec secret-test -it -- cat /etc/secrets/username #验证secret是否导入volume中；

#将secret导出到pod的环境变量中
cat >secret-pod-out.yml<<eof
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: secret-pod-out-deployment
spec:
    replicas: 2
    template:
        metadata:
            labels:
                app: secret-pod-out-deployment
        spec:
            containers:
            - image: hub.atguigu.com/library/nginx:latest
              name: pod-1
              ports:
              - containerPort: 80
              env:
              - name: TEST_USER
                valueFrom:
                    secretKeyRef:
                        name: mysecret
                        key: username
              - name: TEST_PASSWORD
                valueFrom:
                    secretKeyRef:
                        name: mysecret
                        key: password
eof
kubectl apply -f secret-pod-out.yml
kubectl get pod
kubectl exec secret-pod-out-deployment-7b8f585846-2cvj6 -it -- echo $TEST_PASSWORD #验证secret是否导入pod中；

3、kubernetes.io/dockerconfigjson案例

kubectl create secret docker-registry myregistrykey --docker-server=hub.atguigu.com --docker-username=admin --docker-password=Harbor12345 --docker-email=admin@example.com #创建docker registry认证的secret；私有仓库不进行认证就无法下载镜像，因此需要创建该secret来存储私有docker registry的认证信息
cat >myregistry-secret.yml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: foo
spec:
    containers:
        - image: hub.atguigu.com/library/nginx:latest
          name: foo
    imagePullSecrets:
        - name: myregistrykey
eof
kubectl apply -f myregistry-secret.yml
kubectl get pod

 四、volume介绍

docker中，容器崩溃后重启时数据不会丢失；但K8S中，容器崩溃时，该容器的文件会丢失，kubelet重启该容器，容器以镜像最初状态重新启动；POD中同时运行的多个容器需要共享文件。
k8s支持以下类型的卷：emptyDir；hostPath;iscsi;local;nfs;awsElasticBlockStore;azureDisk;azureFile;cephfs；csi；downwardAPI；fc；flocker；gcePersistentDisk；gitRepo；glusterfs;persistentVolumeClaim;projected;portworxVolume;quobyte;rbd;scaleIO;secret;storageos;vsphereVolume;

1、emptyDir介绍　　

当pod被分配给节点时，首先创建emptyDir卷，并且只要该pod在该节点上运行，该卷就会存在。该卷最初时空的，pod中容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同的路径上。当处于任何原因从节点中删除pod时，emptyDir中数据将被永久删除。
empty的用法有：
　　暂存空间，如：用于基于磁盘的合并排序；
　　用作长时间计算崩溃恢复时的检查点；
　　web服务器容器提供数据时，保存内容管理器容器提取的文件；

cat >volume-emptyDir.yml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: volume-test-pod
spec:
    containers:
    - image: hub.atguigu.com/library/nginx:latest
      name: volume-test-container
      volumeMounts:
      - mountPath: /cache
        name: cache-volume
    - image: hub.atguigu.com/library/busybox:latest
      name: liveness-exec-container
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","touch /tmp/live;sleep 6000s"]
      volumeMounts:
      - mountPath: /test
        name: cache-volume      
    volumes:
    - name: cache-volume
      emptyDir: {}
eof
kubectl apply -f volume-emptyDir.yml
kubectl get pod
kubectl exec volume-test-pod -c volume-test-container -it -- touch /cache/test.txt
kubectl exec volume-test-pod -c volume-test-container -it -- ls /cache
kubectl exec volume-test-pod -c liveness-exec-container -it -- ls /test

2、hostPath介绍　　

hostPath卷:将主机节点的文件系统中文件或目录挂载到集群中；用途如下：
　　运行需要访问docker内部的容器；使用/var/lib/docker的hostPath；
　　在容器中运行cAdvisor(K8S中一个用于监控docker的组件)；使用/dev/cgroups的hostPath；
　　允许pod指定给定的hostPath是否应该在pod运行之前存在，是否应该创建，以及它应该以什么形式存在；
hostPath卷属性有path，type；
　　type: #type默认值为空，用于向后兼容，意味着在挂载hostPath卷之前不会执行任何检查。
　　type:DirectoryOrCreate #如果在给定的路径上没有任何东西存在，则根据需要创建一个空目录，权限为0755，与kubelet具有相同的组和所有权；
　　type:Directory #给定的路径上必须存在目录；
　　type:FileOrCreate #如果在给定的路径上没有任何东西存在，则根据需要创建一个空文件，权限为0644，与kubelet具有相同的组和所有权；
　　type:File #给定的路径上必须存在文件；
　　type:Socket #给定的路径上必须存在UNIX套接字；
　　type:CharDevice #给定的路径上必须存在字符设备；
　　type:BlockDevice #给定的路径上必须存在块设备；
使用hostPath卷注意事项：
　　由于每个节点上的文件都不同，具有相同配置的pod在不同节点上的行为可能会有所不同；
　　当K8S按照计划添加资源感知调度时，将无法考虑hostPath使用的资源；
　　在底层主机上创建的文件或目录只能由root写入。您需要在特权容器中以root身份运行进程，或修改主机上文件权限以便写入hostPath卷。

cat >volume-hostPath.yml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: hostpath-volume-pod
spec:
    containers:
    - image: hub.atguigu.com/library/nginx:latest
      name: hostPath-volume--container
      volumeMounts:
      - mountPath: /cache
        name: cache-volume
    volumes:
    - name: cache-volume
      hostPath: 
        path: /data
        type: Directory
eof
kubectl apply -f volume-hostPath.yml  #确保调度节点存在/data/目录；
kubectl get pod
kubectl exec volume-test-pod -c volume-test-container -it -- touch /cache/test.txt

五、PV及PVC介绍

 PV(persistentVolume)

　　是由管理设置的存储，它是集群的一部分。就像节点是集群中的资源一样，PV也是集群中的资源。PV是volume之类的卷插件，但居于哦独立于使用PV的pod的生命周期。此API对象包含存储实现的细节，接NFS，iSCSI或特定于云供应商的存储系统。

PVC(persistentVolumeClaim)
　　是用户存储的请求。它与pod相似。pod消耗节点资源，PVC消耗PV资源。pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（如：可以读/写一次或只读多次模式挂载）；

静态PV
　　集群管理员创建一些PV。他们带有可供集群用户使用的实际存储的细节他们存在于K8S API中，可用于消费；

动态PV（实现方式复杂，价格昂贵，不太成熟，但是是未来的趋势）
　　当管理员创建静态PV都不匹配用户的persistentVolumeClaim时，集群可能会尝试动态地为PVC创建卷。此配置基于StorageClasses:PVC必须请求[存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为“”可以有效地金庸其动态配置。
　　要启用基于存储级别的动态存储配置，集群管理员需要启用API server上的DefaultStorageClass【准入控制器】。例如，通过确保DefaultStorageClass位于API server组件的--admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作。

绑定
　　master中的控制环路监视新的PVC，寻找匹配的PV（如果可能），并将它们绑定在一起。如果为新的PVC动态调配PV，则该环路将始终将PV绑定到PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦PV和PVC绑定后，PersistentVolumeClaimbanging是排他性的，不管它们是如何绑定的。PVC跟PV绑定是一对一的映射。一般情况下，PVC规定容量一般小于PV容量，很少情况会出现近似相等。

持久化卷声明的保护
　　PVC保护的目的是确保由POD正在使用的PVC不会从系统中移除，因为如果被移除的话可能会导致数据丢失。当启用PVC保护alpha功能时，如果用户删除了一个pod正在使用的PVC,则该PVC不会被立即删除。PVC的删除将被推迟，指导PVC不再被任何pod使用。注意：当pod状态为pending并且pod已经分配给节点或pod为running状态时，PVC处于活动状态。

PV类型以插件形式实现。K8S目前支持以下插件类型：
　　awsElasticBlockStore;azureDisk;azureFile;FC（fiber channel）;
　　FlexVolume;Flocker;NFS;iSCSI;RBD(ceph block device);cephFS;
　　cinder(openstack block storage);glusterfs;vshpereVolume;quobyte volumes;
　　HostPath;VMware Photon;portworx Volumes;scaleIO volumes;storageOS;

PV访问模式：
　　persistentVolume可以资源提供者支持的任何方式挂载到主机上。供应商具有不同的功能，每个PV的访问模式都将被设置为怪卷支持的特定模式；如：NFS可支持多个读/写客户端，但特定的NFS PV可能以只读方式导出到服务器。每　　个PV都有一套自己的用来描述特定功能的访问模式。一个卷只能使用一种访问模式挂载，即使它支持很多访问模式。
　　ReadWriteOnce（RWO）---该卷可以被单个节点以读/写模式挂载；
　　ReadOnlyMany(ROX)---该卷可以被多个节点以只读模式挂载；
　　ReadWriteMany(RWX)---该卷可以被多个节点以读/写模式挂载；

回收策略：
　　retain（保留）---手动回收；PV不再被pod使用，但也不允许其他pod使用，等待管理员去手动释放数据。
　　recycle（回收）---基本擦除（rm -rf /thevolume/*）；最新版K8S不支持。
　　delete(删除)---关联的存储资产（如AWS EBS|GCE PD|AZURE DISK|OPENSTACK CINDER）将被删除；
　　当前只有NFS和hostPath支持回收策略。AWS EBS|GCE PD|AZURE DISK|OPENSTACK CINDER支持删除策略。

卷可以处于以下某种状态：
　　available(可用)---一块空闲资源还没有被任何声明绑定；
　　bound（已绑定）---卷已经被声明绑定；
　　released（已释放）---声明被删除，但是资源还未被集群重新声明。
　　failed（失败）---该卷的自动回收失败。
命令行会显示绑定到PV的PVC的名称。

创建statefuSet前必须要创建要给SVC；

##安装NFS服务器(选定K8S集群之外的主机部署，IP为192.168.66.100)
yum install -y nfs-common nfs-utils rpcbind
mkdir /nfsdata
chmod 777 /nfsdata          #慎用权限；
chown nfsnobody /nfsdata
cat >>/etc/exports<<eof  
/nfsdata *(rw,no_root_squash,no_all_squash,sync) #创建一个nfs文件系统；
eof
systemctl enable rpcbind;systemctl start rpcbind;systemctl status rpcbind
systemctl enable nfs;systemctl start nfs;systemctl status nfs
mkdir /nfs{1..3}            #在nfs服务器创建3个空目录；
chmod 777 /nfs{1..3}         
chown nfsnobody /nfs{1..3} 

cat >>/etc/exports<<eof     #在创建3个nfs文件系统；
/nfs1 *(rw,no_root_squash,no_all_squash,sync) 
/nfs2 *(rw,no_root_squash,no_all_squash,sync) 
/nfs3 *(rw,no_root_squash,no_all_squash,sync) 
eof
systemctl restart rpcbind nfs
##所有K8S集群节点安装工具
yum install -y nfs-utils rpcbind
mkdir /nfs_test/
showmount -e 192.168.66.100
mount -t nfs 192.168.66.100:/nfsdata /nfs_test/ #将nfs服务器192.168.66.100的/nfsdata挂载至本机/nfs_test目录下；
cd /nfs_test/
echo "nfs_test" >test.txt #在nfs服务器192.168.66.100的/nfsdata与本机/nfs_test目录下都可看见创建的test.txt；
umount /nfs_test/ #卸载挂载的nfs服务器192.168.66.100的/nfsdata；

##部署PV
cat >PV.yml<<eof
apiVersion: v1
kind: PersistentVolume
metadata:
    name: nfspv1
spec:
    capacity:
        storage: 10Gi                       #声明卷的容量；
    accessModes:
        - ReadWriteOnce                     #声明访问方式；
    persistentVolumeReclaimPolicy: Retain   #声明回收策略；
    storageClassName: nfs                   #指定要绑定PV的类；非常重要的一个指标；
    nfs:
        path: /nfsdata
        server: 192.168.66.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: nfspv01
spec:
    capacity:
        storage: 5Gi                       #声明卷的容量；
    accessModes:
        - ReadWriteMany                     #声明访问方式；
    persistentVolumeReclaimPolicy: Retain   #声明回收策略；
    storageClassName: slow                   #指定要绑定PV的类；非常重要的一个指标；
    nfs:
        path: /nfs1
        server: 192.168.66.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: nfspv02
spec:
    capacity:
        storage: 5Gi                       #声明卷的容量；
    accessModes:
        - ReadWriteOnce                     #声明访问方式；
    persistentVolumeReclaimPolicy: Retain   #声明回收策略；
    storageClassName: nfs                   #指定要绑定PV的类；非常重要的一个指标；
    nfs:
        path: /nfs2
        server: 192.168.66.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: nfspv03
spec:
    capacity:
        storage: 1Gi                       #声明卷的容量；
    accessModes:
        - ReadWriteOnce                     #声明访问方式；
    persistentVolumeReclaimPolicy: Retain   #声明回收策略；
    storageClassName: nfs                   #指定要绑定PV的类；非常重要的一个指标；
    nfs:
        path: /nfs3
        server: 192.168.66.100
eof
kubectl apply -f PV.yml
kubectl get pv          #此时pv可以直接挂载至pod使用了；但正常情况下，使用PVC来调用PV；
##创建服务并使用PVC
cat >PVC.yml<<eof
apiVersion: v1
kind: Service
metadata:
    name: nginx
    labels:
        app: nginx
spec:
    ports:
    - port: 80
      name: web
    clusterIP: None
    selector:
        app: nginx
---
apiVersion: apps/v1
kind: StatefulSet       #创建statefuSet前必须要创建要给SVC；
metadata:
    name: web
spec:
    selector:
        matchLabels:
            app: nginx
    serviceName: "nginx"  #必须为无头服务（即该服务必须为clusterIP: None）才行；
    replicas: 3
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
            - name: nginx
              image: hub.atguigu.com/library/nginx:latest
              ports:
              - containerPort: 80
                name: web
              volumeMounts:
              - name: www
                mountPath: /usr/share/nginx/html
    volumeClaimTemplates:                           #声明卷的请求；
    - metadata:
        name: www
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "nfs"
        resources:
            requests:
                storage: 1Gi
eof
kubectl apply -f PVC.yml
kubectl get pv
kubectl get pvc
kubectl get pod
kubectl get statefulset

###测试NFS卷的使用
##在NFS服务器操作
cd /nfs3        #根据实际pv确定目录；
echo "hello world" >index.html
chmod 777 index.html
chown nfsnobody index.html
##在K8S master操作
curl 10.244.2.157           #该IP为名为web-0的pod调度节点的IP；
kubectl delete pod web-0    
kubectl get pod -o wide
curl 10.244.2.159           #访问新pod，其pv内容不会变化。

 1、PV手动回收

 

 

 删除statefulset、pod、pvc后，需要手动释放pv时，需要至NFS服务器删除对应目录下的文件及pv下的claimRef字段内容。