【k8s】9、数据存储

一、数据存储的概念

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的对接没问题，数据就可以成功访问。

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

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   #共享文件路径

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

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

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

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

创建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，并创建Secret

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

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

```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