前言：
持久化存储是容器无法绕开的一个问题，其主要原因是我们的容器或者pod有些是有状态服务，有些是无状态服务的，而容器或者pod的生命周期是短暂的，例如，一个MySQL容器或者pod，容器或者pod启动后，对该服务做了一些修改，比如修改密码，添加插件，删除无用数据等等操作后，如果容器或者pod在这些操作后被销毁了或者重启了，那么，前面做的这些改动就将消失了（容器或者pod规定的，只要重新启动将会恢复初始状态）。因此，数据的持久化对于有状态服务来说就是非常必要的了。
这里简单提一句，有状态服务和无状态服务到底是指的什么？
无状态服务
-认为所有pod都是一样的，不具备与其他实例有不同的关系。
- 没有顺序的要求。
- 不用考虑再哪个Node运行。
- 随意扩容缩容。
- Deployment控制器设计原则：管理的所有Pod一模一样，提供同一个服务，也不考虑在哪台Node运行，可随意扩容和缩容。这种应用称为“无状态”，例如Web服务
有状态服务
- 集群节点之间的关系。
- 数据不完全一致。
- 实例之间不对等的关系。
- 依靠外部存储的应用。
- 通过dns维持身份
- 在实际的场景中，并不能满足所有应用，尤其是分布式应用，会部署多个实例，这些实例之间往往有依赖关系，例如主从关系、主备关系，这种应用称为“有状态”，例如MySQL主从、Etcd集群
如何理解呢？http协议大家应该都清楚是无状态的协议服务，而电子商务内的购物车等等是有事务，有状态的，带session了嘛，比如，电子商务里的已付款商品和未付款商品，电子商务的后台对每种状态情况做了标识了，这样就算有状态了。举一个常见的例子，在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的，所以为了实现有状态服务，就需要通过一些额外的方案。比如最常见的session，将用户挑选的商品(购物车)，保存到session中，当付款的时候，再从购物车里取出商品信息 。
实验目标：
前面说了那么多，做了N多铺垫，也就是想使用一下在k8s中应用最简单的nfs网络存储来持久化存储一个MySQL5.7.23的单实例，并且该MySQL单实例能通过navicat连接上，并进行一些初步的管理工作。
实验环境：
（1）一个可正常运行的k8s环境，使用的服务器是centos7版本，三台虚拟机服务器，IP地址为：192.168.217.16/17/18 ，其中16服务器是主master服务器。17，18为node节点。
[root@master ~]# k get nodes NAME STATUS ROLES AGE VERSION c7n.cnn Ready master 32d v1.19.4 slave1 Ready <none> 32d v1.19.4 slave2 Ready <none> 32d v1.19.4
（2）nfs服务
nfs服务搭建在master节点，也就是16服务器上。配置文件内容如下：
[root@master ~]# cat /etc/exports /data/nfs-sc 10.244.0.0/16(rw,no_root_squash,no_subtree_check) 192.168.217.16(rw,no_root_squash,no_subtree_check) 192.168.217.0/24(rw,no_root_squash,no_subtree_check)
（3）
nfs-client-provisioner镜像使用的是这个：
[root@master ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE registry.cn-shanghai.aliyuncs.com/c7n/nfs-client-provisioner v3.1.0-k8s1.11 e47e31bbe424 19 months ago 49.8MB
下载链接：https://pan.baidu.com/s/1ytRwIlMnF_FDzT_V9MQj0A?pwd=k8ss
提取码：k8ss
三个服务器都导入该镜像，因为不知道pod会调度到哪个节点。
实验步骤：
一，rbac角色权限建立，文件内容如下：
[root@master ~]# cat serviceacount.yaml apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner namespace: kube-system --- 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: ["get", "list", "watch","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 namespace: kube-system 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 namespace: kube-system subjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: kube-system roleRef: kind: Role name: leader-locking-nfs-client-provisioner apiGroup: rbac.authorization.k8s.io
这里需要注意一点，都是使用的namespace kube-system ，下面的文件也需要指定到kube-system命名空间
执行该文件输出应该如下（）：
[root@master ~]# k apply -f serviceacount.yaml serviceaccount/nfs-client-provisioner created 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
执行命令：kubectl apply -f serviceacount.yaml
（二）部署pod
[root@master ~]# cat deploy-nfs.yaml apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner --- kind: Deployment apiVersion: apps/v1 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 containers: - name: nfs-client-provisioner image: registry.cn-shanghai.aliyuncs.com/c7n/nfs-client-provisioner:v3.1.0-k8s1.11 imagePullPolicy: IfNotPresent volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME value: fuseim.pri/ifs - name: NFS_SERVER value: 192.168.217.16 - name: NFS_PATH value: /data/nfs-sc volumes: - name: nfs-client-root nfs: server: 192.168.217.16 path: /data/nfs-sc
nfs-client-provisioner这个镜像的部署，其中的env 需要根据自己的实际情况填写，也就是这些：
- name: PROVISIONER_NAME value: fuseim.pri/ifs #可以自己定义一个任意的名字 - name: NFS_SERVER #这里不修改 value: 192.168.217.16 #nfs服务所在的服务器IP - name: NFS_PATH #这里不修改 value: /data/nfs-sc #nfs服务配置文件里写的路径，也就是/etc/exports文件内定义的路径 volumes: - name: nfs-client-root #这不修改 nfs: server: 192.168.217.16#nfs服务所在的服务器IP path: /data/nfs-sc #nfs服务配置文件里写的路径，也就是/etc/exports文件内定义的路径
除了需要根据实际情况修改的地方，还有一个地方需要注意， serviceAccountName: nfs-client-provisioner，这个账号由于
metadata:
name: nfs-client-provisioner
namespace: kube-system
这一段是指定的命名空间kube-system，因此，上面的账号生成文件也必须是使用namespace 为kube-system 。总的来说，也就是两者使用的命名空间要保持一致。
执行命令：kubectl apply -f deploy-nfs.yaml
这两步完成后，应该就能在命名空间kube-system 里看到一个正常运行的pod：
[root@master ~]# k get po -n kube-system|grep nfs nfs-client-provisioner-6fc484bd4f-7vrb8 1/1 Running 0 135m
（三）建立StorageClasses
vim storageclass-nfs.yaml
此sc建立的时候就设定为了default class
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-nfs-storage annotations: storageclass.beta.kubernetes.io/is-default-class: "true" provisioner: fuseim.pri/ifs reclaimPolicy: Delete allowVolumeExpansion: True #允许pvc创建后扩容
这个StorageClass是没有和命名空间namespace有依赖的，提供者provisioner: fuseim.pri/ifs这个是建立pvc时候必须指定的 哦，这个是非常重要的一个键值对，它的值由文件deploy-nfs.yaml内定义。
执行命令：kubectl apply -f storageclass-nfs.yaml
