1 数据存储
- 1.1存储概述
- 1.2 k8s支持的Volume类型
2 临时存储
3 持久化存储
4 配置
- 4.1 Secret
  - 4.1.1 secret介绍
  - 4.1.2 创建Secret
准备好username
准备password
创建
- 4.1.4 使用Secret之环境引用
- 4.1.5 使用Secret之卷挂载
4.2 ConfigMap
- 4.2.1 创建 ConfigMap、环境变量引用、卷挂载

1 数据存储

1.1存储概述

在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

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

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

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

1.2 k8s支持的Volume类型

Kubernetes 目前支持多达 28 种数据卷类型（其中大部分特定于具体的云环境如 GCE/AWS/Azure 等）

非持久性存储：
- emptyDir
- HostPath
网络连接性存储：
- SAN：iSCSI、ScaleIO Volumes、FC (Fibre Channel)
- NFS：nfs，cfs
分布式存储
- Glusterfs
- RBD (Ceph Block Device)
- CephFS
- Portworx Volumes
- Quobyte Volumes
云端存储
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- AzureDisk
- Cinder (OpenStack block storage)
- VsphereVolume
- StorageOS
自定义存储
- FlexVolume

2 临时存储

2.1 概述

Kubernetes 为了不同的目的，支持几种不同类型的临时卷：
- emptyDir： Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存
- configMap、 downwardAPI、 secret：将不同类型的 Kubernetes 数据注入到 Pod 中
- CSI 临时卷：类似于前面的卷类型，但由专门支持此特性的指定 CSI 驱动程序提供
- 通用临时卷：它可以由所有支持持久卷的存储驱动程序提供
emptyDir、configMap、downwardAPI、secret 是作为本地临时存储提供的。它们由各个节点上的 kubelet 管理。
CSI 临时卷 必须 由第三方 CSI 存储驱动程序提供。
通用临时卷 可以 由第三方 CSI 存储驱动程序提供，也可以由支持动态配置的任何其他存储驱动程序提供。一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态供应：因此这些驱动程序不能用于通用临时卷。
使用第三方驱动程序的优势在于，它们可以提供 Kubernetes 本身不支持的功能，例如，与 kubelet 管理的磁盘具有不同运行特征的存储，或者用来注入不同的数据。

2.2 emptyDir

Pod 分派到某个 Node 上时，emptyDir 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。
就像其名称表示的那样，卷最初是空的。
尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，这些容器都可以读写 emptyDir 卷中相同的文件。
当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会被永久删除。

注意：容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃期间 emptyDir 卷中的数据是安全的。

emptyDir 的一些用途：
- 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。
emptyDir 卷存储在该节点的磁盘或内存中，如果设置 emptyDir.medium = Memory ，那么就告诉 Kubernetes 将数据保存在内存中，并且在 Pod 被重启或删除前，所写入的所有文件都会计入容器的内存消耗，受到容器内存限制约束。

2.2.1 创建存储

vi nginx-emptyDir-test.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-emptyDir-test
  namespace: dev
  labels:
    app: nginx-emptyDir-test
spec:
  containers:
  - name: nginx
    image: nginx:1.20.2
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi    
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /usr/share/nginx/html
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","while true;do sleep 1; date > /app/index.html;done"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi    
    volumeMounts:
    - name: app
      mountPath: /app     
  volumes:
    - name: app
      emptyDir: {} # emptyDir 临时存储
  restartPolicy: Always

kubectl apply -f nginx-emptyDir-test.yaml

2.3 hostPath

EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

hostPath 之所以被归为临时存储，是因为实际开发中，我们一般都是通过 Deployment 部署 Pod 的，一旦 Pod 被 Kubernetes 杀死或重启拉起等，并不一定会部署到原来的 Node 节点中。

创建存储

vi hostpath-test.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-test
  namespace: dev
  labels:
    app: nginx-hostpath
spec:
  containers:
  - name: nginx
    image: nginx:1.20
    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: 
      path: /root/logs
      type: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

注：
关于type的值的一点说明：
DirectoryOrCreate 目录存在就使用，不存在就先创建后使用
Directory 目录必须存在
FileOrCreate 文件存在就使用，不存在就先创建后使用
File 文件必须存在
Socket unix套接字必须存在
CharDevice 字符设备必须存在
BlockDevice 块设备必须存在

kubectl apply -f hostpath-test.yaml

3 持久化存储

3.1 NFS

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

3.1.1 首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器

#在nfs服务器上安装nfs服务
yum install -y nfs-utils

在nfs服务器（即master节点）操作如下

# * 表示暴露权限给所有主机；
echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports

mkdir -p /nfs/data

systemctl enable rpcbind --now

systemctl enable nfs-server --now

#让配置生效
exportfs -r

#查看配置
exportfs

3.1.2 在所有Node节点操作

yum install -y nfs-utils

#检查有哪些内容可以挂载
showmount -e 172.20.1.82  

#执行以下命令挂载 nfs 服务器上的共享目录到本机路径
mkdir -p /home/nfs/data
mount -t nfs 172.20.1.82:/nfs/data /home/nfs/data

# 在master节点新建一个测试文件
echo "test" > /nfs/data/test.txt

#在任意Node节点新建一个测试文件
echo "hello nfs server" > /home/nfs/data/test123.txt

3.1.3 新建pod挂载数据

vi nfs-nginx-test.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-nginx-test
  namespace: test
  labels:
    app: nfs-nginx-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nfs-nginx-test
  template:
    metadata:
      labels:
        app: nfs-nginx-test
    spec:
      containers:
      - image: nginx:1.20
        name: nginx
        ports:
         - containerPort: 80
         name:  http  
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html/
      volumes:
        - name: html
          nfs:
            server: 172.20.1.82
            path: /nfs/data/nginx-nfs #挂载在本地的路径

kubectl apply -f nfs-nginx-test.yaml

3.2 PV和PVC

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

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

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

存储：存储工程师维护
PV： kubernetes管理员维护
PVC：kubernetes用户维护

3.2.1 PV和PVC的创建

创建PV池-静态供应

mkdir -pv /nfs/data/10m
mkdir -pv /nfs/data/20m
mkdir -pv /nfs/data/500m
mkdir -pv /nfs/data/1Gi

创建PV
```
vi nfs-pv-k8s.yaml
```
```yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv-10m spec: storageClassName: nfs-storage # 用于分组 capacity: storage: 10m accessModes:
- ReadWriteOnce nfs: # 使用 nfs 存储驱动 path: /nfs/data/10m # nfs 共享的目录 server: 172.20.1.82 # nfs 服务端的 IP 地址或 hostname

apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv-20m spec: storageClassName: nfs-storage # 用于分组 capacity: storage: 20m accessModes:

- ReadWriteOnce

nfs: # 使用 nfs 存储驱动 path: /nfs/data/20m # nfs 共享的目录

server: 172.20.1.82 # nfs 服务端的 IP 地址或 hostname

apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv-500m spec: storageClassName: nfs-storage # 用于分组 capacity: storage: 500m accessModes:

- ReadWriteOnce

nfs: # 使用 nfs 存储驱动 path: /nfs/data/500m # nfs 共享的目录

server: 172.20.1.82 # nfs 服务端的 IP 地址或 hostname

apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv-1g spec: storageClassName: nfs-storage # 用于分组 capacity: storage: 1Gi accessModes:

- ReadWriteOnce

nfs: # 使用 nfs 存储驱动 path: /nfs/data/1Gi # nfs 共享的目录 server: 172.20.1.82 # nfs 服务端的 IP 地址或 hostname

```yaml
kubectl apply -f nfs-pv-k8s.yaml

创建PVC
```
vi nfs-pvc-k8s.yaml
```
```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nginx-pvc-500m namespace: test labels: app: nginx-pvc-500m spec: storageClassName: nfs-storage accessModes:
- ReadWriteOnce resources: requests: storage: 500m

apiVersion: v1 kind: Pod metadata: name: nginx-pvc namespace: test labels: app: nginx spec: containers:

name: nginx image: nginx:1.20.2 resources: limits:
```
cpu: 200m
memory: 500Mi
```
requests:
```
cpu: 100m
memory: 200Mi
```
ports:
- containerPort: 80 name: http volumeMounts:
- name: localtime mountPath: /etc/localtime
- name: html mountPath: /usr/share/nginx/html/ volumes:
- name: localtime hostPath: path: /usr/share/zoneinfo/Asia/Shanghai
- name: html
  persistentVolumeClaim: claimName: nginx-pvc-500m readOnly: false
  restartPolicy: Always
```
```yaml
  kubectl apply -f nfs-pvc-k8s.yaml
```

3.2.2 PV访问模式（accessModes）

用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

需要注意的是，底层不同的存储类型可能支持的访问模式不同

3.2.3 PV回收策略（persistentVolumeReclaimPolicy）

当PV不再被使用了之后，对其的处理方式。目前支持三种策略：

Retain （保留）保留数据，需要管理员手工清理数据
Recycle（回收）清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*
Delete （删除）与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务

3.2.4 PV状态

一个 PV 的生命周期，可能会处于 4 种不同的阶段：
- Available（可用）：表示可用状态，还未被任何 PVC 绑定。
- Bound（已绑定）：表示 PV 已经被 PVC 绑定。
- Released（已释放）：表示 PVC 被删除，但是资源还没有被集群重新释放。
- Failed（失败）：表示该 PV 的自动回收失败。

3.2.5 生命周期

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

3.3 动态供应

3.3.1 简介

静态供应：集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群用户可用（可见）。PV 卷对象存在于 Kubernetes API 中，可供用户消费（使用）。
动态供应：集群自动根据 PVC 创建出对应 PV 进行使用。

3.3.2 设置nfs动态供应

注意：不一定需要设置 NFS 动态供应，可以直接使用云厂商提供的 StorageClass 。

部署NFS动态供应：

vi nfs-provisioner.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 指定一个供应商的名字 
# or choose another name, 必须匹配 deployment 的 env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false" # 删除 PV 的时候，PV 中的内容是否备份
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  namespace: default
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: ccr.ccs.tencentyun.com/gcr-containers/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 192.168.65.100 # NFS 服务器的地址
            - name: NFS_PATH
              value: /nfs/data # NFS 服务器的共享目录
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.65.100
            path: /nfs/data
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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: ["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: default
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: default
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: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f nfs-provisioner.yaml

测试动态供应：

vi nginx-pv-provisioner.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
  namespace: default
  labels:
    app: nginx-pvc
spec:
  storageClassName: nfs-client # 注意此处
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.20.2
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: localtime
      mountPath: /etc/localtime
    - name: html
      mountPath: /usr/share/nginx/html/ 
  volumes:
    - name: localtime
      hostPath:
        path: /usr/share/zoneinfo/Asia/Shanghai
    - name: html    
      persistentVolumeClaim:
        claimName:  nginx-pvc
        readOnly: false  
  restartPolicy: Always

kubectl apply -f nginx-pv-provisioner.yaml

4 配置

4.1 Secret

4.1.1 secret介绍

Secret 对象类型用来保存敏感信息，如：密码、OAuth2 令牌以及 SSH 密钥等。将这些信息放到 Secret 中比放在 Pod 的定义或者容器镜像中更加安全和灵活。
由于创建 Secret 可以独立于使用它们的 Pod，因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施，如：避免将机密数据写入非易失性存储。
Secret 类似于 ConfigMap 但专门用于保存机密数据。

4.1.2 创建Secret

命令行创建Secret：

kubectl create secret generic secret-1 \
 --from-literal=username=admin \
 --from-literal=password=admin123

对数据进行编码： ```yaml

准备好username

echo -n ‘admin’ | base64

准备password

echo -n ‘admin123’ | base64


- yaml方式创建Secret：
```yaml
vi k8s-secret-test.yaml

apiVersion: v1
kind: Secret
metadata:
  name: k8s-secret-test
  namespace: test
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2

kubectl apply -f k8s-secret-test.yaml

根据文件创建Secret： ```yaml echo -n ‘admin’ > username.txt echo -n ‘admin123’ > password.txt

创建

kubectl create secret generic k8s-secret-test2 \ —from-file=username.txt \ —from-file=password.txt


<a name="pme52"></a>
#### 4.1.3 查看secret
```yaml
#查看命名空间test下的secret
kubectl get -n test secret

#以yaml方式查看secret
kubectl get -n test secret k8s-secret-test  -o yaml

#以 JOSN 的形式提取 data
kubectl get -n test secret k8s-secret-test  -o jsonpath='{.data}'

4.1.4 使用Secret之环境引用

vi k8s-secret-test1.yaml

apiVersion: v1
kind: Secret
metadata:
  name: k8s-secret-test1
  namespace: test
type: Opaque
stringData: 
  username: admin
  password: "admin123"
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret-test
  namespace: test
  labels:
    app: pod-secret-test
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi
    env:
    - name: SECRET_USERNAME # 容器中的环境变量名称
      valueFrom:
        secretKeyRef: 
          name: k8s-secret-test1 #  指定 secret 的名称
          key: username # secret 中 key 的名称，会自动 base64 解码
    - name: SECRET_PASSWORD # 容器中的环境变量名称
      valueFrom:
        secretKeyRef:
          name: k8s-secret-test1 #  指定 secret 的名称
          key: password # secret 中 key 的名称   
    - name: POD_NAME
      valueFrom: 
        fieldRef:  # 属性引用
          fieldPath: metadata.name
    - name: POD_LIMITS_MEMORY
      valueFrom:
        resourceFieldRef:  # 资源限制引用 
          containerName: alpine  
          resource: limits.memory       
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: localtime
      mountPath: /etc/localtime
  volumes:
    - name: localtime
      hostPath:
        path: /usr/share/zoneinfo/Asia/Shanghai
  restartPolicy: Always

kubectl apply -f k8s-secret-test1.yaml

4.1.5 使用Secret之卷挂载

vi k8s-secret-test2.yaml

apiVersion: v1
kind: Secret
metadata:
  name: k8s-secret-test2
  namespace: test
type: Opaque
stringData: 
  username: admin
  password: "admin123"
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret-test2
  namespace: test
  labels:
    app: pod-secret-test2
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi     
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /app  
  volumes:
    - name: app
      secret:
        secretName: k8s-secret-test2 # secret 的名称，Secret 中的所有 key 全部挂载出来
  restartPolicy: Always

kubectl apply -f k8s-secret-test2.yaml

注：

如果 Secret 以卷挂载的方式，Secret 里面的所有 key 都是文件名，内容就是 key 对应的值。
如果 Secret 以卷挂载的方式，Secret 的内容更新，那么容器对应的值也会被更新（subPath 引用除外）。
如果 Secret 以卷挂载的方式，默认情况下，挂载出来的文件是只读的。

4.2 ConfigMap

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

4.2.1 创建 ConfigMap、环境变量引用、卷挂载

vi k8s-configmap-test.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: k8s-configmap-test
  namespace: test
data:
  # 类属性键；每一个键都映射到一个简单的值
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"
  # 类文件键
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true 
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap-test
  namespace: test
  labels:
    app: pod-configmap-test
spec:
  containers:
  - name: alpine
    image: "alpine"
    command: ["/bin/sh","-c","sleep 3600"]
    resources:
      limits:
        cpu: 200m
        memory: 500Mi
      requests:
        cpu: 100m
        memory: 200Mi
    env:
    - name: PLAYER_INITIAL_LIVES
      valueFrom:
        configMapKeyRef:
          name: k8s-configmap-test
          key: player_initial_lives
    ports:
    - containerPort:  80
      name:  http
    volumeMounts:
    - name: app
      mountPath: /app  
  volumes:
    - name: app
      configMap:
        name: k8s-configmap-test # secret 的名称，Secret 中的所有 key 全部挂载出来
        items:
          - key: ui_properties_file_name # secret 中 key 的名称，Secret 中的 ui_properties_file_name 的内容挂载出来
            path: ui_properties_file_name.md # 在容器内挂载出来的文件的路径
  restartPolicy: Always

kubectl apply -f k8s-configmap-test.yaml

注：

ConfigMap 和 Secret 一样，环境变量引用不会热更新，而卷挂载是可以热更新的。
最新版本的 ConfigMap 和 Secret 提供了不可更改的功能，即禁止热更新，只需要在 Secret 或 ConfigMap 中设置 immutable = true。

Kubernetes教程

k8s配置和存储