k8sConfigMap，Secret，Volumes（StorageClass），StatefulSet

Posted 2021-08-30 S4061222

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

目录

• 一、ConfigMap
• • 1. 创建ConfigMap的方式
  • • 1.1 使用字面值创建
    • 1.2 使用文件创建
    • 1.3 使用目录创建
    • 1.4 编写configmap的yaml文件创建
  • 2.configmap使用
  • • 2.1 环境变量的方式直接传递给pod
    • 2.2 使用conigmap设置命令行参数
    • 2.3 通过数据卷使用configmap
  • 3. configmap热更新
• 二、secret配置管理
• • 1 从文件中创建Secret
  • 2 编写一个 secret 对象
  • 3 将Secret挂载到Volume中
  • 4 向指定路径映射 secret 密钥
  • 5 将Secret设置为环境变量
  • 6 kubernetes.io/dockerconfigjson用于存储docker registry的认证信息
• 三、Volumes配置管理
• • 1 emptyDir卷
  • • 3.1 同一个pod下的两个容器共享volumes
    • 3.2 sizeLimit
  • 2 hostPath卷
  • • 2.1 查看pod调度节点是否创建相关目录
    • 2.2 NFS
  • 3 PersistentVolume（持久卷PV）
  • 3.1 PVC简介
  • 3.2 PersistentVolume原理
  • • 3.1 静态PV（创建NFS 静态PV卷）
    • 3.2 NFS动态分配PV
  • 4 StorageClass存储类
  • • 设定默认存储类
• 四、 StatefulSet控制器(有序+持久化)
• • 4.1 通过Headless Service维持Pod的拓扑状态
  • • 有序
  • 4.2 StatefulSet+持久化存储pvc

一、ConfigMap

• Configmap用于保存配置数据，以键值对形式存储。

• configMap 资源提供了向 Pod 注入配置数据的方法。

• 旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。

  • 典型的使用场景：

  • 填充环境变量的值

  • 设置容器内的命令行参数

  • 填充卷的配置文件

1. 创建ConfigMap的方式

1.1 使用字面值创建

创建字为my-config的configmap，key-value方式定义，key1的值是config1，key2的值是config2。
查看，产生了新的cm为my-config，并且键值已写进去。

1.2 使用文件创建

key的名称是文件名称，value的值是这个文件的内容

1.3 使用目录创建

目录中的文件名为key，文件内容是value

1.4 编写configmap的yaml文件创建

查看名为cm1-config的configmap的详细信息

2.configmap使用

• 通过环境变量的方式直接传递给pod

• 通过在pod的命令行下运行的方式

• 作为volume的方式挂载到pod内

2.1 环境变量的方式直接传递给pod

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
    - name: pod1
      image: busyboxplus
      command: ["/bin/sh", "-c", "env"]
      env:
        - name: key1
          valueFrom:
            configMapKeyRef:
              name: cm1-config		%把cm1-config中的db_host这个key改名为key1
              key: db_host
        - name: key2
          valueFrom:
            configMapKeyRef:
              name: cm1-config		%把cm1-config中的db_port这个key改名为key2
              key: db_port
  restartPolicy: Never

创建pod后查看pod1日志，key1和key2已写入

2.2 使用conigmap设置命令行参数

apiVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
    - name: pod2
      image: busyboxplus
      command: ["/bin/sh", "-c", "env"]%env查看变量
      envFrom:
        - configMapRef:
            name: cm1-config
  restartPolicy: Never

查看pod的日志

2.3 通过数据卷使用configmap

piVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
    - name: pod2
      image: nginx
      #command: ["/bin/sh", "-c", "cat /config/db_host"]	%查看/config/db_host
      volumeMounts:
      - name: config-volume
        mountPath: /config		%把cm1-config的数据卷挂载到pod2容器内的/config
  volumes:
    - name: config-volume		%变量来源于cm1-config
      configMap:
        name: cm1-config

信息来源cm1-config

3. configmap热更新

cat nginx.conf

文件方式创建名为nginxconf的configmap

查看名为nginxconf的configmap的详细信息

,编写清单 nginx.yaml文件, 挂载覆盖nginx配置文件
cat nginx.yaml

创建名为my-nginx的pod

更新nginx的配置文件nginx.conf，修改端口为8080

测试：

查看分配端口并访问

修改端口8080为8000

访问，发现未更改，此时还是访问的8080端口

可以看出configmap热更新以生效,但访问Pod的8000端口是无效的：

configmap热更新后，并不会触发相关Pod的滚动更新，需要手动触发, 这样才能再次加载nginx.conf配置文件：

• 每次通过修改“version/config”来触发Pod滚动更新。

• 使用configmap挂载的env环境变量是不会更新的。

刷新副本

访问8000端口成功，ip由10.244.22.35变化为10.244.22.36，访问重新分配的IP

二、secret配置管理

• Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。

• 敏感信息放在 secret 中比放在 Pod 的定义或者容器镜像中来说更加安全和灵活。

• Pod 可以用两种方式使用 secret：

  • 作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里。

  • 当 kubelet 为 pod 拉取镜像时使用。

• Secret的类型：

  • Service Account：Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改 pod 以使用此类型的 secret。

  • Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。

  • kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。

每个namespace下有一个名为default的默认的ServiceAccount对象

ServiceAccount里有一个名为Tokens的可以作为Volume一样被Mount到Pod里的Secret，当Pod启动时这个Secret会被自动Mount到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权过程。

serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中

1 从文件中创建Secret

创建认证文本文件

echo -n 'admin' > ./username.txt
echo -n 'westos' > ./password.txt
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
kubectl get secrets

查看名为db-user-pass的secret的认证信息

默认情况下 kubectl get和kubectl describe 为了安全是不会显示密码的内容

Opaque Secret 其value为base64编码后的值。
如果密码具有特殊字符，则需要使用 \\ 字符对其进行转义

可以通过以下方式查看密码的内容
查看yaml格式的secret ，可以看到base64格式的认证信息

2 编写一个 secret 对象

cat secret.yaml

3 将Secret挂载到Volume中

cat secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysecret
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/secret"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret

进入mysecret pod节点，查看挂载情况，文件挂载在根目录下的/secret/中

4 向指定路径映射 secret 密钥

cat secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysecret
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/secret"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

进入mysecret pod节点，查看文件挂载在指定路径my-group/my-username下

5 将Secret设置为环境变量

cat secret.yaml

查看pod状态

进入secret-env 的pod节点，env 查看环境变量中是否有认证文件信息

环境变量读取Secret很方便，无法支撑Secret动态更新。
修改密码为redhat

发现未变

6 kubernetes.io/dockerconfigjson用于存储docker registry的认证信息

secret的格式为docker-registry

编写资源清单，拉取私有仓库中的镜像



查看pod节点详细信息，发现拉取成功

三、Volumes配置管理

• 容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失,因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。

• Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。

• 卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。

• Kubernetes 支持下列类型的卷：

  • awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi
  • downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker
  • gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、
  • nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd
  • scaleIO、secret、storageos、vsphereVolume
  • https://kubernetes.io/zh/docs/concepts/storage/volumes/

1 emptyDir卷

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

• emptyDir 的使用场景：
  缓存空间，例如基于磁盘的归并排序。
  为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
  在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。

• 默认情况下， emptyDir 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 但是，您可以将 emptyDir.medium 字段设置为 “Memory”，以告诉 Kubernetes 为您安装 tmpfs（基于内存的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。

3.1 同一个pod下的两个容器共享volumes

一个卷挂在pod内两个容器的不同路径下，同一个pod内共享volumes

实验环境：

新建目录volumes

创建pod：两个容器nginx+busyboxplus

执行清单

访问节点，报错403，无默认页面

进入容器，创建默认发布文件

再次访问，成功

进入pod内的第二个容器，追加内容至默认发布页

进入pod内的第一个容器，访问，内容与第二个容器访问的内容相同，说明：
busyboxplus与nginx共享volumes

3.2 sizeLimit

看到文件超过sizeLimit，则一段时间后（1-2分钟）会被kubelet evict掉。之所以不是“立即”被evict，是因为kubelet是定期进行检查的，这里会有一个时间差。

• emptydir缺点：
  • 不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；
  • 影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；
  • 用户不能及时感知到内存不可用

创建大于设定100M大小的文件，节点会坏掉

pod不running！！！

查看pod的详细信息，发现有报错

2 hostPath卷

• hostPath 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。

• hostPath 的一些用法有：

  • 运行一个需访问 Docker 引擎内部机制的容器,挂载 /var/lib/docker 路径。
  • 在容器中运行 cAdvisor 时，以 hostPath 方式挂载 /sys。
  • 允许 Pod 指定给定的 hostPath 在运行 Pod 之前是否应该存在，是否应该创建以及应该以什么方式存在。

• 除了必需的 path 属性之外，用户可以选择性地为 hostPath 卷指定 type
  

• 当使用这种类型的卷时要小心，因为：

  • 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
  • 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 hostPath 使用的资源。
  • 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 hostPath 卷

2.1 查看pod调度节点是否创建相关目录

cat host.yaml

  apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: DirectoryOrCreate

执行清单，创建名为test-pd的pod

访问

pod被调度到server4上

server4查看pod调度节点是否创建相关目录

server2 上进入容器，测试挂载是否成功：
/test-pd目录已经创建，可以看到目录内已存在内容

在容器挂载目录中创建一个文件，受控node主机的相应目录也会自动生成相应文件

2.2 NFS

共享文件系统nfs使用

首先在所有结点上安装nfs，在仓库结点上配置nfs
server1仓库节点：

共享/mnt/nfs

server2：
cat nfs.yaml，在k8s集群利用nfs部署nginx

验证nfs配置是否有误

pod不running！！！server4未安装nfs，调度到那里需要安装，

pod此时running！！！

测试：
server1：

cd /mnt/nfs
echo www.westos.org > index.html

server2：
进入容器，测试挂载是否成功

[root@server1 volumes]# kubectl exec -it  test-pd -- sh
/# ls
bin  boot  dev	docker-entrypoint.d  docker-entrypoint.sh  etc	home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
/# cd /usr/share/nginx/html/
/# ls
index.html
/# cat index.html
www.westos.org
/# 

3 PersistentVolume（持久卷PV）

3.1 PVC简介

• PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。

• PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

• 有两种PV提供的方式：静态和动态。

  • 静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。

  • 动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

• PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。

3.2 PersistentVolume原理

• 使用
  Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。

• 释放
  当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。

• 回收
  PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外部存储（如AWS
  EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是会被删除。

• 访问模式
  ReadWriteOnce – 该volume只能被单个节点以读写的方式映射
  ReadOnlyMany – 该volume可以被多个节点以只读方式映射
  ReadWriteMany – 该volume可以被多个节点以读写的方式映射

  在命令行中，访问模式可以简写为：
  RWO - ReadWriteOnce
  ROX - ReadOnlyMany
  RWX -
  ReadWriteMany

• 回收策略
  Retain：保留，需要手动回收
  Recycle：回收，自动删除卷中数据
  Delete：删除，相关联的存储资产，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都会被删除

  –——当前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持删除操作。

• 状态：
  Available：空闲的资源，未绑定给PVC
  Bound：绑定给了某个PVC
  Released：PVC已经删除了，但是PV还没有被集群回收
  Failed：PV在自动回收中失败了
  ------命令行可以显示PV绑定的PVC名称。

3.1 静态PV（创建NFS 静态PV卷）

之前实验已经安装配置了nfs

[root@server1 volumes]# yum install -y nfs-utils
[root@server1 volumes]# vim /etc/exports
[root@server1 volumes]# systemctl  start nfs
[root@server1 volumes]# showmount  -e
Export list for server1:
/mnt/nfs *

在共享目录pv1 pv2下设置发布内容不同的index.html

vim pv.yaml，创建pv脚本pv.yml，指定位置为/mnt/nfs/pv1和 /mnt/nfs/pv2


vim pvc.yaml，创建pvc的脚本pvc.yml ，volume分别为pv1和pv2

查看pvc，pvc与pv已经绑定
查看pv，CLAIM 中为default/pvc1和default/pvc2，说明已经链接

vim pod.yaml，创建pod，使用持久化存储方式

查看pod的状态

查看pod的分配到的ip

测试：
访问pod不同，发布内容不同


删除pod再次建立，pvc依旧存在，依旧可以使用，注意ip需要重新获取

删除pvc，查看pv状态

pv状态为Available，自动回收！！！

nfs的server端pv1和pv2目录都消失

3.2 NFS动态分配PV

实验环境：

删除静态pv的pvc和pv

• StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。

• 每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。

StorageClass的属性

• Provisioner（存储分配器）：用来决定使用哪个卷插件分配 PV，该字段必须指定。可以指定内部分配器，也可以指定外部分配器。外部分配器的代码地址为：
  kubernetes-incubator/external-storage，其中包括NFS和Ceph等。

• Reclaim Policy（回收策略）：通过reclaimPolicy字段指定创建的Persistent Volume的回收策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。

• 更多属性查看：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

• NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一

  以上是关于k8sConfigMap，Secret，Volumes（StorageClass），StatefulSet的主要内容，如果未能解决你的问题，请参考以下文章

  k8s 配置存储之 Configmap & secret

  k8s 配置存储之 Configmap & secret

  环境变量方式使用 Secret转

  secret

  Rails 6 secret_key_base 与 secret_token

  Kubernetes(k8s)之Secret私密凭据