数据存储
一、数据存储的概念
二、基本存储
1、EmptyDir
2、HostPath
3、NFS
3.1 安装nfs服务器
3.2 每个node节点安装nfs
3.3 编写yaml，创建pod
三、高级存储
1、PV（持久化卷）
1.1 创建pv
2、PVC（持久化卷声明）
2.1 创建pvc
2.2 创建pod，使用pvc
2.3 删除pvc
3、Storage Class 存储类
3.1 nfs服务器上共享
3.2 创建service-account，为nfs-client授权
3.3 使用deployment来创建nfs provisioner
3.4 创建StorageClass
3.5 创建pvc绑定pv
3.5 创建pod挂载pvc
3.6 测试挂载
4、生命周期
四、配置存储
1、configMap（配置存储）
2、Secret（加密配置存储）
一、数据存储的概念
pod的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。
Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下。
kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命周期不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。
kubernetes的volume支持多种类型，比较常见的有下面几个
简单存储： EmptyDir、HostPath、NFS
高级存储： PV、PVC
配置存储： ConfigMap、Secret
二、基本存储
1、EmptyDir
EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录， 当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：
临时空间，例如用于某些应用程序运行时所需的临时目录，且无需永久保留
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）
接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。
在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。
创建一个volume-emptydir.yaml
apiVersion: v1 kind: Pod metadata: name: volume-emptydir namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80 volumeMounts: # 将logs-volume挂在到nginx容器中，对应的目录为 /var/log/nginx - name: logs-volume ##设置挂载的名字，名字必须统一 mountPath: /var/log/nginx - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件中内容 volumeMounts: # 将logs-volume 挂在到busybox容器中，对应的目录为 /logs - name: logs-volume mountPath: /logs volumes: # 声明volume， name为logs-volume，类型为emptyDir - name: logs-volume emptyDir: {}
kubectl create -f volume-emptydir.yaml #创建pod kubectl get pods volume-emptydir -n dev -o wide #查看pod kubectl logs -f volume-emptydir -n dev -c busybox #通过kubectl logs 命令查看指定容器的标准输出【-f:持续监控 ，-c:指定容器名称】 curl 【cluster ip】 #通过pod访问nginx
2、HostPath
EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。
创建volume-hostpath.yaml
apiVersion: v1 kind: Pod metadata: name: volume-hostpath namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80 volumeMounts: - name: logs-volume mountPath: /var/log/nginx - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts: - name: logs-volume mountPath: /logs volumes: - name: logs-volume hostPath: #定义了hostpatch， path: /root/logs #定义挂载到node节点上的目录。 type: DirectoryOrCreate # 定义目录的类型，这边是没有目录就创建
#关于type的值的一点说明： // DirectoryOrCreate 目录存在就使用，不存在就先创建后使用 // Directory 目录必须存在 // FileOrCreate 文件存在就使用，不存在就先创建后使用 // File 文件必须存在 // Socket unix套接字必须存在 // CharDevice 字符设备必须存在 // BlockDevice 块设备必须存在
# 创建Pod kubectl create -f volume-hostpath.yaml # 查看Pod kubectl get pods volume-hostpath -n dev -o wide #访问nginx curl 10.42.2.10 #时实监听日志 kubectl logs -f volume-emptydir -n dev -c busybox # 接下来就可以去host的/root/logs目录下查看存储的文件了
//然后删除pod，再次查看挂载的目录是否存在 # 同样的道理，如果在此目录下创建一个文件，到容器中也是可以看到的
3、NFS
HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。
安装nfs服务器
# 在nfs上安装nfs服务 yum install nfs-utils -y # 准备一个共享目录 mkdir /root/data/nfs -pv # 将共享目录以读写权限暴露给192.168.5.0/24网段中的所有主机 vim /etc/exports /root/data/nfs 20.0.0.0/24(rw,no_root_squash) # 启动nfs服务 systemctl restart nfs
编写yuml.创建pod
volume-nfs.yaml
apiVersion: v1 kind: Pod metadata: name: volume-nfs namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80 volumeMounts: - name: logs-volume mountPath: /var/log/nginx - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts: - name: logs-volume mountPath: /logs volumes: - name: logs-volume nfs: server: 20.0.0.58 #nfs服务器地址 path: /root/data/nfs #共享文件路径
kubctl create -f volume-nfs.yaml kubectl get pods volume-nfs -n dev #查看pod ###再去nfs服务上，查看是否生成对应的日志文件
三、高级存储
前面了解了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs，由于k8s支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用，k8s引入了PV和PVC两种资源对象。
PV （Persistent Volume） 是持久化卷的意思， 是对底层的共享存储的一种抽象，一般情况下PV由k8s管理员进行创建和配置，它与底层的共享存储技术有关，并通过插件完成共享存储的对接。
PVC （Persistent Volume Claim）是持久卷声明的意思， 是用户对于存储需求的一种声明。换句话说，PVC起始就是用户向k8s系统发出的一种资源需求申请。
使用了PV和PVC之后，工作可以得到进一步的细分
存储：存储工程师维护
PV：k8s管理员维护
PVC：k8s用户维护
1、PV（持久化卷）
PV是存储资源的抽象，下面是资源清单文件
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2 #注意:pv是存储资源的抽象，它不存命名空间的定义
spec:
nfs: #存储类型，与底层真正存储对应(有多种，比如NFS、GFS、CIFS等)
cappcity: #存储能力，也就是存储的空间大小
storage: 2Gi
accessModes: #访问模式
storageClassName: #存储类别
persistentVolumeReclaimPolicy: #回收策略
PV的关键配置参数说明
存储类型
底层实际存储的类型，k8s支持多种存储类型，每种存储类型的配置都有所差异
存储能力（capacity）
目前只支持存储空间的设置（storage=1Gi），未来可能加入IOPS、吞吐量等指标的配置
访问模式（accessModes）
用户描述用户应用对存储资源的访问权限，访问权限包括下面几种方式
ReadWriteOnce（RWO）： 读写权限，但是只能被单个节点挂载
ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
需要注意的是，底层不同的存储类型可能支持的访问模式不同
回收策略（persistentVolumeReclaimPolicy）
当PV不再被使用了之后，对其的处理方式。目前支持三种策略
Reatin（保留）： 保留数据，需要管理员手动清理数据
Recycle（回收）： 清除PV中的数据，效果相当于执行 rm -rf /thevolume/*
Delete（删除）： 与PV相连的后端存储完成 volume的删除操作，当然常见与云服务商的存储服务
需要注意的是，底层不同的存储类型可能支持的回收策略不同
存储类别
PV可以通过 storage Name 参数指定一个存储类别
具有特定类别的PV 只能与请求了该类别的PVC进行绑定
未设定类别的PV则只能与不请求任何类别的PVC进行绑定
状态（status）
一个PV的生命周期中，可能会处于4个不同的阶段
Available（可用）： 表示可用状态，还未被任何PVC绑定
Bound（已绑定）： 表示PV已经被PVC绑定
Released（已释放）： 表示PVC被删除，但是资源还未被集群重新声明
Failed（失败）： 表示该PV的自动回收失败
1.1 创建pv
使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS的3个暴露的路径
准备环境
##这些操作在NFS服务器上 mkdir -p /root/data/{pv1,pv2,pv3} #创建pv的工作目录 vim /etc/exports /root/data/pv1 20.0.0.0/24(rw,no_root_squash) /root/data/pv2 20.0.0.0/24(rw,no_root_squash) /root/data/pv3 20.0.0.0/24(rw,no_root_squash) #暴露服务 systemctl restart nfs #重启nfs服务
创建pv.yaml文件–master节点
apiVersion: v1 kind: PersistentVolume metadata: name: pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv1 server: 20.0.0.58 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv2 spec: capacity: storage: 2Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv2 server: 20.0.0.58 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv3 spec: capacity: storage: 3Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv3 server: 20.0.0.58
创建PV
kubectl creaye -f pv.yaml #创建pv kubectl get pv -o wide #查看pv的信息
2、PVC（持久化卷声明）
PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。
资源清单文件
apiVersion: v1 kind: PersistentVolumeClaim #定义pvc的资源类型 metadata: name: pvc namespace: dev #可以定义命名空间 sepc: accessModes: #访问模式 selector: #采用标签对PV选择 storageClassName: #存储类别 resources: #请求空间 requests: storage: 5Gi
PVC的关键配置参数说明
访问模式（accessModes）
用于描述用户应用对存储资源的访问权限
选择条件（selector）
通过Label Selector 的设置，可使PVC 对于系统中已存在的PV进行筛选
存储类别（storageClassName）
PVC在定义时可以设置需要的后端存储类别，只有设置了该class的PV才能被系统选出
资源请求（Resources）
描述对存储资源的请求
2.1 创建pvc
创建pvc.yaml，申请pv
apiVersion: v1 kind: PersistentVolumeClaim #资源类型 metadata: name: pvc1 namespace: dev #命名空间 spec: accessModes: #访问策略为RWX - ReadWriteMany resources: #请求大小 requests: storage: 1Gi --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc2 namespace: dev spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc3 namespace: dev spec: accessModes: - ReadWriteMany resources: requests: storage: 5Gi #这个请求大小为5Gi，它会找不到对应的pv
kubectl create -f pvc.yaml #创建pvc kubectl get pvc -n dev -o wide #查看pvc kubectl get pv -o wide #查看pv
2.2 创建pod，使用pvc
创建pods.yaml
apiVersion: v1 kind: Pod metadata: name: pod1 namespace: dev spec: containers: - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"] #执行echo命令输入到挂载的目录中 volumeMounts: #pvc挂载的目录 - name: volume #挂载的pvc名称 mountPath: /root/ #挂载的路径 volumes: #定义挂载卷 - name: volume #挂载的名称 persistentVolumeClaim: #挂载的类型为pvc claimName: pvc1 #挂载的pvc名称 readOnly: false #取消只读 --- apiVersion: v1 kind: Pod metadata: name: pod2 namespace: dev spec: containers: - name: busybox image: busybox:1.30 command: ["/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;"] volumeMounts: - name: volume mountPath: /root/ volumes: - name: volume persistentVolumeClaim: claimName: pvc2 readOnly: false
kubectl create -f pods.yaml #创建pod kubectl get pods -n dev -owide #查看pod kubectl get pvc -n dev -o wide #查看pvc kubectl get pv -n dev -o wide #查看pv ####下面在NFS服务器上进行查看文件 cat /root/data/pv1/out.txt cat /root/data/pv2/out.txt
2.3 删除pvc
kubectl delete -f pvc.yaml #删除pvc ###删除pvc后，查看pv的状态，发现状态为释放状态，也就是pvc断开了连接。但是数据还是存储的，因为回收策略为保留。 //
3、Storage Class 存储类
上面介绍的PV和PVC模式是需要运维人员先创建好PV，然后开发人员定义好PVC进行一对一的Bond，但是如果PVC请求成千上万，那么就需要创建成千上万的PV，对于运维人员来说维护成本很高，Kubernetes提供一种自动创建PV的机制，叫StorageClass，它的作用就是创建PV的模板。
具体来说，StorageClass会定义一下两部分：
PV的属性 ，比如存储的大小、类型等；
创建这种PV需要使用到的存储插件，比如Ceph等；
有了这两部分信息，Kubernetes就能够根据用户提交的PVC，找到对应的StorageClass，然后Kubernetes就会调用 StorageClass声明的存储插件，创建出需要的PV。
这里我们以NFS为例，要使用NFS，我们就需要一个nfs-client的自动装载程序，我们称之为Provisioner，这个程序会使用我们已经配置好的NFS服务器自动创建持久卷，也就是自动帮我们创建PV。
自动创建的PV会以${namespace}-${pvcName}-${pvName}的目录格式放到NFS服务器上；
如果这个PV被回收，则会以archieved-${namespace}-${pvcName}-${pvName}这样的格式存放到NFS服务器上；
3.1 nfs服务器上共享
nfs服务器上暴露共享目录
3.2 创建service-account，为nfs-client授权
创建 Service Account，用来管理 NFS Provisioner 在 k8s 集群中运行的权限，设置 nfs-client 对 PV，PVC，StorageClass 等的规则
vim nfs-clientsa.yaml
--- apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nfs-client-provisioner-clusterrole 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: ["list", "watch", "create", "update", "patch"] - apiGroups: [""] resources: ["endpoints"] verbs: ["create", "delete", "get", "list", "watch", "patch", "update"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: nfs-client-provisioner-clusterrolebinding subjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: default roleRef: kind: ClusterRole name: nfs-client-provisioner-clusterrole apiGroup: rbac.authorization.k8s.io
kubectl apply -f nfs-client-sa.yaml
#创建一些规则
3.3 使用deployment来创建nfs provisioner
NFS Provisione(即 nfs-client)，有两个功能：一个是在 NFS 共享目录下创建挂载点(volume)，另一个则是将 PV 与 NFS 的挂载点建立关联。
创建nfs-cilent
vim nfs-client.yaml
kind: Deployment apiVersion: apps/v1 metadata: name: nfs-client-provisioner spec: replicas: 1 selector: matchLabels: app: nfs-client-provisioner strategy: type: Recreate template: metadata: labels: app: nfs-client-provisioner spec: serviceAccountName: nfs-client-provisioner #指定Service Account账户 containers: - name: nfs-client-provisioner image: quay.io/external_storage/nfs-client-provisioner:latest imagePullPolicy: IfNotPresent volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME value: nfs-storage #配置provisioner的Name，确保该名称与StorageClass资源中的provisioner名称保持一致 - name: NFS_SERVER value: 20.0.0.58 #配置绑定的nfs服务器 - name: NFS_PATH value: /data/k8s/prometheus #配置绑定的nfs服务器目录 volumes: #申明nfs数据卷 - name: nfs-client-root nfs: server: 20.0.0.58 path: /data/k8s/prometheus
kubectl apply -f nfs-client.yaml kubectl get pods
3.4 创建StorageClass
创建 StorageClass，负责建立 PVC 并调用 NFS provisioner 进行预定的工作，并让 PV 与 PVC 建立关联
vim nfs-client-storageclass.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-client-storageclass provisioner: nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致 parameters: archiveOnDelete: "false" #false表示在删除PVC时不会对数据进行存档，即删除数据
kubectl apply -f nfs-client-storageclass.yaml kubectl get storageclass
3.5 创建pvc绑定pv
vim test-pvc.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-nfs-pvc spec: accessModes: - ReadWriteMany storageClassName: nfs-client-storageclass #关联StorageClass对象 resources: requests: storage: 1Gi
kubectl apply -f test-pvc-pod.yaml kubectl get pvc,pv
3.5 创建pod挂载pvc
vim test-pod.yaml
apiVersion: v1 kind: Pod metadata: name: test-storageclass-pod spec: containers: - name: nginx image: nginx:1.14.1 ports: - name: http containerPort: 80 volumeMounts: - name: pvc-storage mountPath: /usr/share/nginx/html volumes: - name: pvc-storage persistentVolumeClaim: claimName: test-nfs-pvc
3.6挂载测试
nfs上
master
4、生命周期
PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：
资源供应：管理员手动创建底层存储和PV
资源绑定：用户创建PVC，kubernetes负责根据PVC的声明去寻找PV，并绑定
在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的
一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了
如果找不到，PVC则会无限期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV
PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行绑定了
资源使用：用户可在pod中像volume一样使用pvc
Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。
资源释放：用户删除pvc来释放pv
当存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标记为“已释放”，但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV才能再次使用。
资源回收：kubernetes根据pv设置的回收策略进行资源的回收
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用
四、配置存储
1、configMap（配置存储）
ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。
创建configmap.yaml
apiVersion: v1 kind: ConfigMap #定义configmap资源类型 metadata: name: configmap namespace: dev data: #这里不再是spec属性了，而是data数据 info: | #这里定义键值对，在后面的pod容器中键会变成文件名，值会变成文件内容 username:admin password:123456
# 创建configmap kubectl create -f configmap.yaml # 查看configmap详情 kubectl describe cm configmap -n dev
接下来创建一个pod-configmap.yaml，将上面创建的configmap挂载进去
apiVersion: v1 kind: Pod metadata: name: pod-configmap namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 volumeMounts: # 将configmap挂载到目录 - name: config mountPath: /configmap/config volumes: # 引用configmap - name: config configMap: name: configmap
# 创建pod kubectl create -f pod-configmap.yaml # 查看pod kubectl get pod pod-configmap -n dev #进入容器 kubectl exec -it pod-configmap -n dev /bin/sh # 可以看到映射已经成功，每个configmap都映射成了一个目录 # key--->文件 value---->文件中的内容 # 此时如果更新configmap的内容, 容器中的值也会动态更新
下面更新这个这个config资源的键值对内容，然后再进入容器中查看文件是否变化
kubectl edit cm configmap -n dev #编辑内容（修改值的内容） kubectl exec -it pod-configmap -n dev /bin/sh #再次进入容器中查看
2、Secret（加密配置存储）
在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。
首先使用base64对数据进行编码
echo -n 'admin' | base64 #准备username echo -n '123456' | base64 #准备password
编写secret.yaml
apiVersion: v1 kind: Secret metadata: name: secret namespace: dev type: Opaque data: username: YWRtaW4= password: MTIzNDU2
# 创建secret kubectl create -f secret.yaml # 查看secret详情 kubectl describe secret secret -n dev
创建pod-secret.yaml，将上面创建的secret挂载进去：
apiVersion: v1 kind: Pod metadata: name: pod-secret namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 volumeMounts: # 将secret挂载到目录 - name: config mountPath: /secret/config volumes: - name: config secret: secretName: secret
# 创建pod kubectl create -f pod-secret.yaml # 查看pod kubectl get pod pod-secret -n dev # 进入容器，查看secret信息，发现已经自动解码了 kubectl exec -it pod-secret /bin/sh -n dev
<img src="https://typoreydq.oss-cn-shanghai.aliyuncs.com/image-20221012230933980.png" alt="image-20221012230933980" style="zoom:67%;" /> ```javascript # 创建secret kubectl create -f secret.yaml # 查看secret详情 kubectl describe secret secret -n dev
# 创建pod kubectl create -f pod-secret.yaml # 查看pod kubectl get pod pod-secret -n dev # 进入容器，查看secret信息，发现已经自动解码了 kubectl exec -it pod-secret /bin/sh -n dev
