K8S之数据存储

K8S之数据存储

简介#

在 K8S 中容器的生命周期可能会很短暂,即频繁的创建删除,当容器被删除的时候保存在容器内部的数据也会被删除,众所周知数据安全极为重要,当容器被删除导致数据丢失这个我们不能忍受的,因此 K8S 为了保证数据的持久化存储引入了 Volume(数据卷) 的概念

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里面的多个容器挂载到具体的文件目录,K8S通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命周期不和Pod中的单个容器的生命周期有关，当容器终止或者重启的时候，Volume中的数据也不会丢失

kubernetes的Volume支持多种类型，比较常见的有下面的几个：

• 简单存储:EmptyDir、HostPath、NFS
• 高级存储:PV PVC
• 配置存储:ConfigMap Secret

基本存储#

EmptyDir#

简介#

• EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

• EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时，EmptyDir中的数据也会被永久删除。

• EmptyDir的用途如下：

  • 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。

  • 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

• 接下来，通过一个容器之间的共享案例来使用描述一个EmptyDir。

• 在一个Pod中准备两个容器nginx和busybox，然后声明一个volume分别挂载到两个容器的目录中，然后nginx容器负责向volume中写日志，busybox中通过命令将日志内容读到控制台

Copy
# 创建配置文件
cat > volume-emptydir.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-emptydir
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      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: {}
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f volume-emptydir.yaml

# 查看Pod
[root@master k8s]# kubectl get pod volume-emptydir -n dev -o wide

Copy
# 动态展示 busybox 日志
[root@master k8s]# kubectl logs -n dev -c -f volume-emptydir -c busybox

Copy
# 访问容器
curl 10.244.2.20

可以看到在上述的实验中使用 Emptydir 进行数据卷挂载的时候可以进行数据的共享

HostPath#

概述#

在上述的 Emptydir 中数据只能共享但是不能够提供持久化,显然该模式不能满足我们的需求,在 K8S 中提供了 Hostpath 在该模式下Pod 会与节点中目录进行映射,将 pod 中的数据保存到物理节点路径中,当 Pod 被销毁的时候也不会影响物理节点

Copy
# 创建配置文件
cat > volume-hostpath.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件
      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs
        - name: logs-volume
          mountPath: /logs
  volumes: # 声明volume，name为logs-volume，类型为hostPath
    - name: logs-volume
      hostPath:
        path: /root/logs # 与物理机映射的目录
        type: DirectoryOrCreate # 目录存在就使用，不存在就先创建再使用
EOF

# 生成pod
[root@master k8s]# kubectl create -f volume-hostpath.yaml

# 查看pod
[root@master k8s]# kubectl get -n dev pod volume-hostpath -o wide

Copy
# 查看 node1 文件
# pod在那个节点被创建 映射目录在那个节点被创建
[root@node1 ~]# ls /root/logs/

Copy
# 访问nginx
[root@node1 ~]# curl 10.244.1.22

Copy
# 查看日志
[root@master ~]# tail -f /root/logs/access.log

Copy
# 删除pod
[root@master k8s]# kubectl delete -f volume-hostpath.yaml

# 查看 node 中映射目录
[root@node1 ~]# cat /root/logs/access.log

NFS#

概述#

在上述 hostpath 中虽然解决了数据持久化的问题,但是当运行 pod 的 node 节点出现故障 ,导致 pod 不能正确被运行,此时控制器会将 pod 运行到可用 node 之上,但是当 pod 运行到其余节点上,新节点不存在原有节点的数据,因此数据依旧不可靠,所以此时我们需要准备一个网络存储文件系统,例如 NFS/CIFS 等

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样，无论Pod在节点上怎么转移，只要Node和NFS的对接没有问题，数据就可以成功访问。

NFS搭建#

Copy
# 简化实验此时直接在 master 搭建 nfs 服务器

# 安装 NFS
yum install -y nfs-utils 

# 创建共享目录
mkdir -pv /root/data/nfs

# 将共享目录以读写暴露给172.16.137.0/24这个网段
echo /root/data/nfs 172.16.137.0/24(rw,no_root_squash) > /etc/exports

# 开启 NFS
systemctl start nfs && systemctl enable nfs

# 查看 master 节点是否成功挂载
showmount -e 172.16.137.128

Copy
# 在 node 节点上安装 NFS以便 NFS 能够驱动 NFS 设备
# 在Node节点上安装NFS服务，不需要启动
yum -y install nfs-utils

# 查看是否挂载
showmount -e 172.16.137.128

创建 Pod#

Copy
# 创建配置文件
cat > volume-nfs.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件
      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs
        - name: logs-volume
          mountPath: /logs
  volumes: # 声明volume
    - name: logs-volume
      nfs:
        server: 172.16.137.128 # NFS服务器地址
        path: /root/data/nfs # 共享文件路径
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f volume-nfs.yaml

# 查看 Pod
[root@master k8s]# kubectl get pod -n dev volume-nfs -o wide

Copy
# 查看 nfs 共享文件夹
[root@master k8s]# ls /root/data/nfs/

Copy
# 访问 nginx 服务
curl 10.244.1.23

Copy
# 动态查看日志
[root@master k8s]# tail -f /root/data/nfs/access.log

高级存储#

PV/PVC简介#

前面我们已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全部掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用，kubernetes引入了PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它和底层具体的共享存储技术有关，并通过插件完成和共享存储的对接。

PVC（Persistent Volume Claim）是持久化卷声明的意思，是用户对于存储需求的一种声明。换言之，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

• PV:类似于后端存储暴露给外部的一个接口,用户无需关心后端存储的细节,若用户有需求只需求和接口交互即可
• PVC:即客户想后端申请存储的资源

PV#

PV 资源清单文件#

Copy
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型，和底层正则的存储对应
    path:
    server:
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes: # 访问模式
    -
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

• 存储类型:底层存储的实际存储类型 例如:NFS/CIFS

• 存储能力(capacity):目前只支持存储空间的设置（storage=1Gi

• 访问模式(accessModes):用来描述用户对底层存储操作权限

  • ReadWriteOnce:读写权限但是只能被单个节点挂载
  • ReadOnlyMany:只读权限，可以被多个节点挂载。
  • ReadWriteMany:只读权限，可以被多个节点挂载。

• 回收策略:当 PV 不再使用的时候对底层存储资源处理策略

  • Retain(保留):保留数据需要管理员手动清除数据
  • Recycle(回收):清除 PV 中的数据 相当于执行了 rm -fr/volume/*
  • Delete(删除):和 PV 相连的后端存储完成 volume 删除

• 存储类别（storageClassName）：PV可以通过storageClassName参数指定一个存储类别。

  • 具有特定类型的PV只能和请求了该类别的PVC进行绑定。
  • 未设定类别的PV只能和不请求任何类别的PVC进行绑定。

• 状态(status):一个 PV 的什么周期,可能处于 4 种不同的阶段

  • Available（可用）：表示可用状态，还未被任何PVC绑定。
  • Bound（已绑定）：表示PV已经被PVC绑定。
  • Released（已释放）：表示PVC被删除，但是资源还没有被集群重新释放。
  • Failed（失败）：表示该PV的自动回收失败

NFS 环境搭建#

Copy
# 创建目录
mkdir -pv /root/data/{pv1,pv2,pv3}

# 设置目录权限
cat >> /etc/exports << EOF
/root/data/pv1     172.16.137.0/24(rw,no_root_squash)
/root/data/pv2     172.16.137.0/24(rw,no_root_squash)
/root/data/pv3     172.16.137.0/24(rw,no_root_squash)
EOF

# 重启服务
systemctl restart nfs

# 查看权限点
showmount -e 172.16.137.128

创建 PV#

Copy
cat > pv.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv1
    server: 172.16.137.128
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 1Gi
  accessModes: # 访问模式
    - ReadWriteMany		# 运行多 PVC 读写
  persistentVolumeReclaimPolicy: Retain # 回收策略

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv2
    server: 172.16.137.128
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes: # 访问模式
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain # 回收策略

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  nfs: # 存储类型吗，和底层正则的存储对应
    path: /root/data/pv3
    server: 172.16.137.128
  capacity: # 存储能力，目前只支持存储空间的设置
    storage: 3Gi
  accessModes: # 访问模式
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain # 回收策略
EOF

# 创建 PV
[root@master k8s]# kubectl create -f pv.yaml

# 查看PV
[root@master k8s]# kubectl get pv -o wide

pvc#

PVC资源清单文件#

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息，下面是PVC的资源清单文件：

Copy
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev
spec:
  accessModes: # 访客模式
    - 
  selector: # 采用标签对PV选择
  storageClassName: # 存储类别
  resources: # 请求空间
    requests:
      storage: 5Gi

PVC的关键配置参数说明：

• 访客模式（accessModes）：用于描述用户应用对存储资源的访问权限。

• 用于描述用户应用对存储资源的访问权限：

• • 选择条件（selector）：通过Label Selector的设置，可使PVC对于系统中已存在的PV进行筛选。
• • 存储类别（storageClassName）：PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出。
• • 资源请求（resources）：描述对存储资源的请求。

创建 PVC#

Copy
cat > pvc.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
  namespace: dev
spec:
  accessModes: # 访客模式
    - 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
EOF

# 创建 PVC
[root@master k8s]# kubectl create -f pvc.yaml

# 查看 PVC
[root@master k8s]# kubectl get -n dev pvc -o wide

创建 Pod 使用 PVC#

Copy
cat > pvc-pod.yaml << EOF
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;"]
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        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 pod1 >> /root/out.txt; sleep 10; done;"]
      volumeMounts:
        - name: volume
          mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false
EOF

# 创建 Pod
[root@master k8s]# kubectl create -f pvc-pod.yaml

# 查看 pod
[root@master k8s]# kubectl get -n dev pod -o wide

Copy
# 查看 PV1 目录内容
[root@master ~]# tail -n 5 /root/data/pv1/out.txt

1. 在上述中运行 Pod 的时候 Pod1 与 PVC1 进行绑定在一起
2. Pod1 将 /root 目录挂载在外部,同时对/root/out.txt 写入数据
3. 同时由于 PVC 与 PV 相关联绑定在一起,且 PV 绑定到物理机某路径
4. 因此最终 PVC 会通过 PV 将 Pod 产生的数据写入到 PV 绑定的路径中

配置存储#

Configmap#

ConfigMap是一个比较特殊的存储卷，它的主要作用是用来存储配置信息的。

资源清单文件#

Copy
apiVersion: v1
kind: ConfigMap
metadata:
  name: configMap
  namespace: dev
data: # <map[string]string>
  xxx

创建 ConfigMap#

Copy
# 创建配置文件
cat > configmap.yaml << EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap
  namespace: dev
data:
  info:
    username:admin
    password:root
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f configmap.yaml

# 查看配置文件
[root@master k8s]# kubectl describe -n dev configmaps configmap

创建 Pod#

Copy
# 创建配置文件
cat > pod-configmap.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      volumeMounts:
        # 使用上述挂载卷
        - mountPath: /configmap/config
          name: config
  volumes:
    # 声明挂载卷
    - name: config
      configMap:
        name: configmap
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f pod-configmap.yaml

# 查看 pod
[root@master k8s]# kubectl get -n dev pod pod-configmap -o wide

Copy
# 进入容器查看挂载目录
[root@master k8s]# kubectl exec -it -n dev pod-configmap /bin/bash

ConfigMap中的key映射为一个文件，value映射为文件中的内容。如果更新了ConfigMap中的内容，容器中的值也会动态更新。

高级部分#

在上述中我们已经可以实现创建 ConfigMap 但是 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。

如果需要保存超出此尺寸限制的数据，需要考虑挂载存储卷或者使用独立的数据库或者文件服务。

Copy
# 从目录中创建 ConfigMap
mkdir -pv configure-pod-container/configmap/

wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties --no-check-certificate

wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties --no-check-certificate

# 创建 configmap
[root@master ~]# kubectl create configmap cm1 --from-file=configure-pod-container/configmap/

# 查看
[root@master ~]# kubectl get cm cm1 -o yaml

Secret#

在上述使用 configmap 中虽然可以存储信息,但是可以明确查看信息内容,显然对于一些敏感文件使用该配置文件是不合理的,因此 K8S 推出了 Secret ,其配置和 ConfigMap 类似但是可以存放一些敏感文件

数据准备#

Copy
# 准备username使用 base64 编码
echo -n "admin" | base64

创建 Secret#

Copy
# 创建配置文件
cat > secret.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f secret.yaml

# 查看
[root@master k8s]# kubectl describe secret secret -n dev

创建 Pod#

Copy
cat > pod-secret.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      volumeMounts:
      # 挂载目录
        - mountPath: /secret/config
        # 使用数据卷
          name: config
  volumes:
    - name: config
      secret:
      # 使用上述 secret
        secretName: secret
EOF

# 加载配置文件
[root@master k8s]# kubectl create -f pod-secret.yaml

# 查看
[root@master k8s]# kubectl get -n dev pod pod-secret -o wide

Copy
# 进入容器查看挂载内容
[root@master k8s]# kubectl exec -it -n dev pod-secret /bin/bash

使用场景#

imagePullSecret Pod拉取私有镜像仓库的时使用的账户密码，会传递给kubelet，然后kubelet就可以拉取有密码的仓库里面的镜像。

Copy
# 创建私有仓库地址配置账户名密码
kubectl create secret docker-registry docker-harbor-registrykey --docker-server=172.16.137.128:85 \
          --docker-username=root --docker-password=root \
          --docker-email=srseans@163.com
      
# 查看仓库
kubectl get secret docker-harbor-registrykey

Copy
# 创建配置文件
cat > nginx.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: 172.16.137.128:85/yuncloud/nginx # 这是Harbor的镜像私有仓库地址
  imagePullSecrets:
    - name: docker-harbor-registrykey
EOF

# 加载配置文件
[root@master ~]# kubectl create -f nginx.yaml