【k8s】9、数据存储

文章目录

  • 一、数据存储的概念
  • 二、基本存储
    • 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中通过命令将日志内容读到控制台。
【k8s】9、数据存储_第1张图片

创建一个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: {}

【k8s】9、数据存储_第2张图片

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

【k8s】9、数据存储_第3张图片

image-20221011232803375

2、HostPath

EmptyDir中数据不会被持久化,它会随着Pod的结束而销毁,如果想简单的将数据持久化到主机中,可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中,以供容器使用,这样的设计就可以保证Pod销毁了,但是数据依据可以存在于Node主机上。

【k8s】9、数据存储_第4张图片

创建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 块设备必须存在
【k8s】9、数据存储_第5张图片
# 创建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目录下查看存储的文件了

【k8s】9、数据存储_第6张图片

【k8s】9、数据存储_第7张图片

//然后删除pod,再次查看挂载的目录是否存在

# 同样的道理,如果在此目录下创建一个文件,到容器中也是可以看到的

image-20221011234302512

【k8s】9、数据存储_第8张图片

3、NFS

HostPath可以解决数据持久化的问题,但是一旦Node节点故障了,Pod如果转移到了别的节点,又会出现问题了,此时需要准备单独的网络存储系统,比较常用的用NFS、CIFS。

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

【k8s】9、数据存储_第9张图片

3.1 安装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

【k8s】9、数据存储_第10张图片

3.2 每个node节点安装nfs

yum -y install nfs-utils

3.3 编写yaml,创建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   #共享文件路径
【k8s】9、数据存储_第11张图片
kubctl create -f volume-nfs.yaml

kubectl get pods volume-nfs -n dev
#查看pod

###再去nfs服务上,查看是否生成对应的日志文件

【k8s】9、数据存储_第12张图片

【k8s】9、数据存储_第13张图片

三、高级存储

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

  • PV (Persistent Volume) 是持久化卷的意思, 是对底层的共享存储的一种抽象,一般情况下PV由k8s管理员进行创建和配置,它与底层的共享存储技术有关,并通过插件完成共享存储的对接。
  • PVC (Persistent Volume Claim)是持久卷声明的意思, 是用户对于存储需求的一种声明。换句话说,PVC起始就是用户向k8s系统发出的一种资源需求申请。
【k8s】9、数据存储_第14张图片

使用了PV和PVC之后,工作可以得到进一步的细分

  • 存储:存储工程师维护
  • PV:k8s管理员维护
  • PVC:k8s用户维护

1、PV(持久化卷)

PV是存储资源的抽象,下面是资源清单文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2   #注意:pv是存储资源的抽象,它不存命名空间的定义
spec:
  nfs:         #存储类型,与底层真正存储对应(有多种,比如NFSGFSCIFS)
  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服务

【k8s】9、数据存储_第15张图片

创建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
【k8s】9、数据存储_第16张图片

创建pv

kubectl creaye -f pv.yaml
#创建pv

kubectl get pv -o wide
#查看pv的信息

【k8s】9、数据存储_第17张图片

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
【k8s】9、数据存储_第18张图片
kubectl create -f pvc.yaml
#创建pvc

kubectl get pvc -n dev -o wide
#查看pvc

kubectl get pv -o wide
#查看pv

【k8s】9、数据存储_第19张图片

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

【k8s】9、数据存储_第20张图片

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
【k8s】9、数据存储_第21张图片 【k8s】9、数据存储_第22张图片

2.3 删除pvc

kubectl delete -f pvc.yaml
#删除pvc

###删除pvc后,查看pv的状态,发现状态为释放状态,也就是pvc断开了连接。但是数据还是存储的,因为回收策略为保留。

//

【k8s】9、数据存储_第23张图片

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服务器上暴露共享目录

【k8s】9、数据存储_第24张图片

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

通过上面得配置,设置nfs-client对PV,PVC,StorageClass等得规则。接下来我们创建这个YAML文件:

kubectl apply -f nfs-client-sa.yaml
#创建一些规则

image-20221014192052476

3.3 使用deployment来创建nfs provisioner

NFS Provisione(即 nfs-client),有两个功能:一个是在 NFS 共享目录下创建挂载点(volume),另一个则是将 PV 与 NFS 的挂载点建立关联。

由于 1.20 版本启用了 selfLink,所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错,解决方法如下:

vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false       #添加这一行
    - --advertise-address=20.0.0.55
......

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
kubectl delete pods kube-apiserver -n kube-system 
kubectl get pods -n kube-system | grep apiserver

【k8s】9、数据存储_第25张图片

创建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

【k8s】9、数据存储_第26张图片

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

image-20221014195314259

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

【k8s】9、数据存储_第27张图片

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

【k8s】9、数据存储_第28张图片

3.6 测试挂载

nfs服务器上操作

image-20221014224025060

master节点操作

【k8s】9、数据存储_第29张图片

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绑定和使用

【k8s】9、数据存储_第30张图片

四、配置存储

1、configMap(配置存储)

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

创建configmap.yaml

apiVersion: v1
kind: ConfigMap    #定义configmap资源类型
metadata:
  name: configmap
  namespace: dev
data:             #这里不再是spec属性了,而是data数据
  info: |           #这里定义键值对,在后面的pod容器中键会变成文件名,值会变成文件内容
    username:admin
    password:123456
【k8s】9、数据存储_第31张图片
# 创建configmap
kubectl create -f configmap.yaml

# 查看configmap详情
kubectl describe cm configmap -n dev

【k8s】9、数据存储_第32张图片

接下来创建一个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

【k8s】9、数据存储_第33张图片

# 创建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的内容, 容器中的值也会动态更新

【k8s】9、数据存储_第34张图片

下面更新这个这个config资源的键值对内容,然后再进入容器中查看文件是否变化

kubectl edit cm configmap -n dev
#编辑内容(修改值的内容)

kubectl exec -it pod-configmap -n dev /bin/sh
#再次进入容器中查看
【k8s】9、数据存储_第35张图片 【k8s】9、数据存储_第36张图片

2、Secret(加密配置存储)

在kubernetes中,还存在一种和ConfigMap非常类似的对象,称为Secret对象。它主要用于存储敏感信息,例如密码、秘钥、证书等等。

首先使用base64对数据进行编码

echo -n 'admin' | base64    #准备username

echo -n '123456' | base64   #准备password

【k8s】9、数据存储_第37张图片

接下来编写secret.yaml,并创建Secret

apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2
【k8s】9、数据存储_第38张图片
# 创建secret
kubectl create -f secret.yaml

# 查看secret详情
kubectl describe secret secret -n dev

【k8s】9、数据存储_第39张图片

创建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

【k8s】9、数据存储_第40张图片

# 创建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

kind: Secret
metadata:
name: secret
namespace: dev
type: Opaque
data:
username: YWRtaW4=
password: MTIzNDU2


image-20221012230933980

```javascript
# 创建secret
kubectl create -f secret.yaml

# 查看secret详情
kubectl describe secret secret -n dev

[外链图片转存中…(img-VTPWNCBZ-1668959486736)]

创建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

[外链图片转存中…(img-D2smMAAD-1668959486736)]

# 创建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

【k8s】9、数据存储_第41张图片

你可能感兴趣的:(k8s,kubernetes,运维,docker)