简介：
Kubernetes - 存储部分
ConfigMap 的创建
Pod 中使用 ConfigMap
通过数据卷插件使用ConfigMap
Secret
Kubernetes-volume
hostPath：主机节点的文件系统中的文件或目录挂载到(容器)集群中
PersistentVolume (PV)
PersistentVolumeClaim (PVC)
Kubernetes - 存储部分
configMap 描述信息
ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配
置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也
可以用来保存整个配置文件或者 JSON 二进制大对象
ConfigMap 的创建
Ⅰ、使用目录创建
$ ls docs/user-guide/configmap/kubectl/ game.properties ui.properties $ cat docs/user-guide/configmap/kubectl/game.properties
enemies=aliens lives=3 enemies.cheat=true enemies.cheat.level=noGoodRotten secret.code.passphrase=UUDDLRLRBABAS secret.code.allowed=true secret.code.lives=30 $ cat docs/user-guide/configmap/kubectl/ui.properties color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice $ kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl
--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容。
查看创建信息
kubectl get cm
kubectl get cm game-config -o yaml
Ⅱ、使用文件创建
只要指定为一个文件就可以从单个文件中创建 ConfigMap
$ kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties
$ kubectl get configmaps game-config-2 -o yaml
--from-file 这个参数可以使用多次，你可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的。
Ⅲ、使用字面值创建
使用文字值创建，利用--from-literal 参数传递配置信息，该参数可以使用多次，格式如下：
$ kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
$ kubectl get configmaps special-config -o yaml
Pod 中使用 ConfigMap
Ⅰ、使用 ConfigMap 来替代环境变量
$ mkdir env $ cd env $ vim env.yaml
apiVersion: v1 kind: ConfigMap metadata: name: special-config #configmap名称 namespace: default data: #值 special.how: very #key special.type: charm #value
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
kubectl apply -f env.yaml
将上面的环境变量注入到pod中
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: hub.atguigu.com/library/myapp:v1 command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config #cm名称 key: special.how #导入的key名，将这个key的值赋给上面的SPECIAL_LEVEL_KEY - name: SPECIAL_TYPE_KEY valueFrom: configMapKeyRef: name: special-config key: special.type #导入的key名，将这个key的值赋给上面的SPECIAL_TYPE_KEY envFrom: #导入上面env-config的环境变量 - configMapRef: name: env-config restartPolicy: Never
创建pod
查看运行结果(日志)
kubectl log dapi-test-pod
可以看到3个环境变量已修改
Ⅱ、用 ConfigMap 设置命令行参数
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm
$ vim pod1.yaml
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod66 spec: containers: - name: test-container image: hub.atguigu.com/library/myapp:v1 command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE_KEY valueFrom: configMapKeyRef: name: special-config key: special.type restartPolicy: Never
$ kubectl create -f pod1.yaml
查看日志
Ⅲ、通过数据卷插件使用ConfigMap
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm
在数据卷里面使用这个 ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，键就是文
件名，键值就是文件内容。
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: hub.atguigu.com/library/myapp:v1 command: [ "/bin/sh", "-c", "cat /etc/config/special.how" ] #键就是文件名，键值就是文件内容 volumeMounts: - name: config-volume #挂载下面的vm mountPath: /etc/config #挂载路径，会将下面vm中cm的key值挂载为文件名，键值就会成为文件内容 volumes: - name: config-volume #vm名称 configMap: #cm名称 name: special-config restartPolicy: Never
ConfigMap 的热更新--数据卷的方式（演示）
$ vim 111.yaml
apiVersion: v1 kind: ConfigMap metadata: name: log-config namespace: default data: log_level: INFO --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: my-nginx spec: replicas: 1 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: hub.atguigu.com/library/myapp:v1 ports: - containerPort: 80 volumeMounts: - name: config-volume mountPath: /etc/config #把log-config挂载到这个目录中 volumes: - name: config-volume configMap: name: log-config
$ kubectl exec pod名称 -it -- cat /etc/config/log_level INFO
热更新：
修改 ConfigMap
$ kubectl edit configmap log-config
修改 log_level 的值为 DEBUG 等待大概 10 秒钟时间，再次查看环境变量的值
$ kubectl exec pod名称 -it -- cat /etc/config/log_level DEBUG
$ kubectl exec `kubectl get pods -l run=my-nginx -o=name|cut -d "/" -f2` cat /tmp/log_level DEBUG
可以看出：只要修改configmap文件，pod里面文件内容就会自动更新键值
特别注意：configMap如果以ENV的方式挂载至容器，修改configMap并不会实现热更新！！！
ConfigMap 更新后滚动更新 Pod
更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新，可以通过修改 pod annotations 的方式强制触发滚动更新
$ kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20190411" }}}}}'
这个例子里我们在 .spec.template.metadata.annotations 中添加 version/config ，每次通过修改version/config 来触发滚动更新。
！！！ 更新 ConfigMap 后：
使用该 ConfigMap 挂载的 Env 不会同步更新
使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新
Secret
Secret 存在意义
Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec中。
Secret 可以以 Volume 或者环境变量的方式使用。
Secret 有三种类型：
1.Service Account ：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目录中。
2.Opaque ：base64编码格式的Secret，用来存储密码、密钥等。
3.kubernetes.io/dockerconfifigjson ：用来存储私有 docker registry 的认证信息。
Service Account(不怎么常用)
Service Account 用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod的/run/secrets/kubernetes.io/serviceaccount 目录中。
$ kubectl run nginx --image nginx
deployment "nginx" created $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-3137573019-md1u2 1/1 Running 0 13s $ kubectl exec nginx-3137573019-md1u2 ls /run/secrets/kubernetes.io/serviceaccount ca.crt namespace token
Opaque Secret（常用）
Ⅰ、创建说明
Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式：
先加密
$ echo -n "admin" | base64 YWRtaW4= $ echo -n "1f2d1e2e67df" | base64 MWYyZDFlMmU2N2Rm
再保存到secrets.yml
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: password: MWYyZDFlMmU2N2Rm username: YWRtaW4=
$ kubectl apply -f secrets.yaml
解密特别简单
echo -n "YWRtaW4=" |base64 -d
Ⅱ、使用方式
1、将 Secret 挂载到 Volume 中(方式一)
apiVersion: v1 kind: Pod metadata: labels: name: seret-test name: seret-test spec: volumes: # 创建卷 - name: secrets #卷名 secret: secretName: mysecret #上面创建的secret名 containers: - image: hub.atguigu.com/library/myapp:v1 name: db volumeMounts: - name: secrets #挂载上面声明的secrets卷名 mountPath: "/etc/secrets" #挂载路径 readOnly: true
注意：虽然保存的时候是加密的，但是它在使用时会自动解密，上面/etc/secrets目录下的就是解密后文件
2、将 Secret 导出到环境变量中(方式二)
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: pod-deployment spec: replicas: 2 template: metadata: labels: app: pod-deployment spec: containers: - name: pod-1 image: hub.atguigu.com/library/myapp:v1 ports: - containerPort: 80 env: - name: TEST_USER valueFrom: secretKeyRef: name: mysecret key: username #会将这个username的值赋给上面的TEST_USER - name: TEST_PASSWORD valueFrom: secretKeyRef: name: mysecret key: password #会将这个password的值赋给上面的TEST_PASSWORD
kubernetes.io/dockerconfigjson（例：harbor私有仓库）
准备实验镜像，推送到私有仓库(直接推送失败，需要登录)
登录后推送镜像（成功）
好了，镜像准备完成
开始实验
退出harbor登录
没认证前--测试拉取私有仓库镜像（拉取失败）
使用 Kuberctl 创建 docker registry 认证的 secret
##创建类型：docker-registry 名称：myregistrykey
$ kubectl create secret docker-registry myregistrykey
--docker-server=DOCKER_REGISTRY_SERVER #docker私有仓库地址即harbor仓库地址
--docker-username=DOCKER_USER #用户名
--docker-password=DOCKER_PASSWORD #密码
--docker-email=DOCKER_EMAIL #邮箱
secret "myregistrykey" created.
在创建 Pod 的时候，通过 imagePullSecrets 来引用刚创建的 `myregistrykey`
$ vim pod.yaml
apiVersion: v1 kind: Pod metadata: name: foo spec: containers: - name: foo image: hub.atguigu.com/test/myapp:v2 #私有仓库镜像 imagePullSecrets: #认证 - name: myregistrykey
pod状态是Running说明pod镜像下载成功!
Kubernetes-volume
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。
首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。
其次，在Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume 抽象就很好的解决了这些问题。
背景
Kubernetes 中的卷有明确的寿命 -- 与封装它的 Pod 相同。所以，卷的生命比 Pod 中的所有容器都长，
当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，
Kubernetes支持多种类型的卷，Pod 可以同时使用任意数量的卷。
卷的类型
Kubernetes 支持以下类型的卷：
awsElasticBlockStore azureDisk azureFile cephfs csi downwardAPI emptyDir
fc flocker gcePersistentDisk gitRepo glusterfs hostPath iscsi local nfs
persistentVolumeClaim projected portworxVolume quobyte rbd scaleIO secret
storageos vsphereVolume
emptyDir
当 Pod 被分配给节点时，首先创建emptyDir卷，并且只要该 Pod 在该节点上运行，该卷就会存在。
正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入 emptyDir 卷中的相同文件，
尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。
注意：容器崩溃不会从节点移除pod，因此‘emptyDir’中的数据在容器崩溃时是安全的。
emptyDir 的用法有：
1.暂存空间，例如用于基于磁盘的合并排序
2.用作长时间计算崩溃恢复时的检查点
3.Web服务器容器提供数据时，保存内容管理器容器提取的文件
$ vim em.yaml
apiVersion: v1 kind: Pod metadata: name: test-pd1 spec: containers: - image: wangyanglinux/myapp:v2 name: test-container volumeMounts: - mountPath: /cache #挂载目录，将下面的卷挂载到本容器此目录下 name: cache-volume #挂载的卷名
- name: liveness-exec-cntainer #第二个容器 image: busybx imagePullPolicy:IfNotPresent command: ["/bin/sh","-c","sleep 6000s"] volumeMounts: - mountPath: /test #挂载目录，将下面的卷挂载到本容器此目录下 name: cache-volume #挂载的卷名 volumes: - name: cache-volume emptyDir: {} #空卷
$ kubectl create -f em.yaml
进入第一个容器挂载目录并编辑
进入第二个容器挂载目录并编辑
回到第一个容器查看
可得出结论：两个容器不同路径挂载目录也是可以共享一个卷目录的。
hostPath
hostPath卷将主机节点的文件系统中的文件或目录挂载到(容器)集群中。
hostPath的用途如下：
1.运行需要访问 Docker 内部的容器；使用 /var/lib/docker 的 hostPath
2.在容器中运行 cAdvisor；使用 /dev/cgroups 的 hostPath
3.允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在，是否应该创建，以及它应该以什么形式存在。
除了所需的path 属性之外，用户还可以为 hostPath 卷指定 type。
使用这种卷类型时请注意，因为：
1.由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不同。
2.当 Kubernetes 按照计划添加资源感知调度时，将无法考虑 hostPath 使用的资源。
3.在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入 hostPath 卷。
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd #挂载目录 name: test-volume volumes: - name: test-volume hostPath: # 主机上的目录 path: /data # this field is optional type: Directory #给定的路径下必须存在目录，否则报错
在本机创建目录 /data
进入挂载容器并编辑
在本地data目录查看并编辑
再进入容器查看
可以看到本地目录文件和容器挂载卷实现了资源共享
Kubernetes-PersistentVolume
PersistentVolume（PV）
是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。
PV 是Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。
PersistentVolumeClaim （PVC）
是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。
声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。
静态 pv
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费。
动态
当管理员创建的静态 PV 都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态地为 PVC 创建卷。
此配置基于 StorageClasses ：PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。
声明该类为 "" 可以有效地禁用其动态配置要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass [准入控制器]。
例如，通过确保 DefaultStorageClass位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。
绑定
master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。
否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后， PersistentVolumeClaim绑定是排他性的，不管它们是如何绑定的。
PVC 跟PV 绑定是一对一的映射。
持久化卷声明的保护
PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失。
当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。
PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。
持久化卷类型
PersistentVolume 类型以插件形式实现。Kubernetes 目前支持以下插件类型：
1.GCEPersistentDisk AWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
2.FlexVolume Flocker NFS iSCSI RBD (Ceph Block Device) CephFS
3.Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
4.HostPath VMware Photon Portworx Volumes ScaleIO Volumes StorageOS
持久卷演示代码：(封装一个PV的示例方案)
apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi 存储大小 volumeMode: Filesystem #文件类型 accessModes: #访问策略 - ReadWriteOnce #只能同时一个人读写 persistentVolumeReclaimPolicy: Recycle #回收策略 storageClassName: slow #存储类的名称，划分存储类的非常重要的一个指标 mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp #挂载目录 server: 172.17.0.2 #挂载服务器IP
PV 访问模式
PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个PV 的访问模式都将被设置为该卷支持的特定模式。
例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式。
ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载
在命令行中，访问模式缩写为：
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
回收策略
Retain（保留）——手动回收
Recycle（回收）——基本擦除（ rm -rf /thevolume/* ）
Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除。
当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略。
状态
卷可以处于以下的某种状态：
Available（可用）——一块空闲资源还没有被任何声明绑定
Bound（已绑定）——卷已经被声明绑定
Released（已释放）——声明被删除，但是资源还未被集群重新声明
Failed（失败）——该卷的自动回收失败
命令行会显示绑定到 PV 的 PVC 的名称
持久化演示实验 - NFS
Ⅰ、安装 NFS 服务器
yum install -y nfs-common nfs-utils rpcbind mkdir /nfs
mkdir /nfs{1..3} chmod 666 /nfs* chown nfsnobody /nfs* cat /etc/exports /nfs *(rw,no_root_squash,no_all_squash,sync) /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) systemctl start rpcbind systemctl start nfs
其他节点安装nfs客户端
yum -y install nfs-utils rpcbind mkdir /test #测试挂载服务端nfs共享目录 mount -t nfs 192.168.66.100:/nfs /test cd /test vim 111.txt #测试完后卸载 umount /test rm -rf /test
#上面操作是为了测试nfs能否正常使用
Ⅱ、部署 PV
$ vim pv.yaml （部署多个pv，可以看出pv和pvc之间的关系） apiVersion: v1 kind: PersistentVolume metadata: name: nfspv1 spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: nfs nfs: path: /nfs server: 192.168.66.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfspv2 spec: capacity: storage: 5Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: nfs nfs: path: /nfs1 server: 192.168.66.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfspv3 spec: capacity: storage: 5Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: slow nfs: path: /nfs2 server: 192.168.66.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfspv4 spec: capacity: storage: 1Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: nfs nfs: path: /nfs3 server: 192.168.66.100 $ kubectl create -f pv.yaml $ kubectl get pv
Ⅲ、创建服务并使用 PVC(正常情况下PV都是通过PVC调用使用的)
$ vim pod.yaml
apiVersion: v1 kind: Service #svc metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None #svc无头服务,不需要链接到对应的IP/端口 selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet #注意：如果要建立一个StatefulSet控制器的话，必须先建立一个无头服务，StatefulSet的svc一定是无头服务才行 metadata: name: web spec: selector: matchLabels: #匹配标签，当app=nginx时匹配 app: nginx serviceName: "nginx" #指定上面的svc无头服务名称 replicas: 3 template: metadata: labels: #标签信息 app: nginx #app=nginx （key=value） spec: containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 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 #卷大小满足条件
$ kubectl create -f pod.yaml
PVC挂载条件1.访问模式为：ReadWriteOnce 2.存储对象名为：nfs 3.卷大小>=1GB,如果前两个匹配，优先选择满足条件容量小的匹配
重新修改PV
删除旧的PV
kubectl delete pv nfspv3
kubectl delete pv nfspv4
apiVersion: v1 kind: PersistentVolume metadata: name: nfspv3 spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: nfs nfs: path: /nfs2 server: 192.168.66.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfspv4 spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain #回收策略 storageClassName: nfs nfs: path: /nfs3 server: 192.168.66.100
可以看到都完成了绑定，每个pod都有一个请求模板，会创建一个PVC，PVC会去跟PV进行匹配，匹配成功后就会与之绑定
测试一：
查看第一个PVC绑定的PV详细信息
kubectl describe pv nfspv1
进入相应的nfs服务器(192.168.66.100)
cd /nfs
vim index.html
aaaaaaaa
chmod 777 index.html
进入其他节点服务器
测试二：
查看第二个PVC绑定的PV详细信息
kubectl describe pv nfspv3
进入相应的nfs服务器(192.168.66.100)
cd /nfs2 vim index.html bbbbbbbbbbbbbbbbb chmod 777 index.html
进入其他节点服务器访问
第三个同理略 ，可以发现三个都完成了绑定关系，且数据一致了
测试删除pod后，数据的持久化
删除pod（可以看到重新生成了一个同名pod，且IP地址也变了(但是访问名称一致不会变)）
再次访问查看数据(数据一致，数据不会丢失，这就是StatefulSet的一些特性)
关于 StatefulSet
1.匹配 Pod name ( 网络标识 ) 的模式为：$(statefulset名称)-$(序号)，比如上面的示例：web-0，web-1，web-2。
2.StatefulSet 为每个 Pod 副本创建了一个 DNS 域名，这个域名的格式为： $(podname).(headless servername)，------>pod_name.svc_name
也就意味着服务间是通过Pod域名来通信而非 Pod IP，因为当Pod所在Node发生故障时， Pod 会被飘移到其它 Node 上，Pod IP 会发生变化，但是 Pod 域名不会有变化。(通过FQDN调用而非IP)
3.StatefulSet 使用 Headless 服务来控制 Pod 的域名，这个域名的 FQDN 为：$(service name).$(namespace).svc.cluster.local，其中，“cluster.local” 指的是集群的域名。
4.根据 volumeClaimTemplates，为每个 Pod 创建一个 pvc，pvc 的命名规则匹配模式：(volumeClaimTemplates.name)-(pod_name)，
比如上面的 volumeMounts.name=www， Pod name=web-[0-2]，因此创建出来的 PVC 是 www-web-0、www-web-1、www-web-2。
5.删除 Pod 不会删除其 pvc，手动删除 pvc 将自动释放 pv。
Statefulset的启停顺序：
1.有序部署：部署StatefulSet时，如果有多个Pod副本，它们会被顺序地创建（从0到N-1）并且，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。
2.有序删除：当Pod被删除时，它们被终止的顺序是从N-1到0。
3.有序扩展：当对Pod执行扩展操作时，与部署一样，它前面的Pod必须都处于Running和Ready状态。
StatefulSet使用场景：
1.稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现。
2.稳定的网络标识符，即 Pod 重新调度后其 PodName 和 HostName 不变。
3.有序部署，有序扩展，基于 init containers 来实现。
4.有序收缩。
StatefulSet、pod、pvc、pv和nfs之间的关系概述
StatefulSet控制器里面有pvc的模板，会创建相应的pvc和pod，pvc会与pod相关联，然后与pv进行匹配，使pod与pv绑定，而pv又和nfs之间进行挂载实现数据持久化。
pvc简单来说：就是pod和pv进行匹配的一些准则。
大概关系图如下：
