企业运维实战--k8s学习笔记 k8s存储之configMap配置管理、Secret配置管理和Volumes配置管理

1.ConfigMap简介

Configmap用于保存配置数据，以键值对形式存储。
configMap 资源提供了向 Pod 注入配置数据的方法。
让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。

典型的使用场景：

填充环境变量的值
设置容器内的命令行参数
填充卷的配置文件

2.创建configmap

创建ConfigMap的方式有4种：

使用字面值创建
使用文件创建
使用目录创建
编写configmap的yaml文件创建

2.1.使用字面值创建

创建cm，并查看信息

kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
kubectl  get cm
kubectl  describe  cm my-config 

2.2文件创建

kubectl create configmap my-config-2 --from-file=/etc/resolv.conf
kubectl describe cm my-config-2

2.3使用目录创建

mkdir configmap
cd configmap/
mkdir test
cp /etc/passwd test/
cp /etc/fstab test/

kubectl create configmap my-config-3 --from-file=test
kubectl describe cm my-config-3

2.4.编写configmap的yaml文件

vi config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm1-config
data:
  db_host: "172.25.76.250"
  db_port: "3306"

kubectl apply -f config.yaml
kubectl describe cm cm1-config

3.ConfigMap使用

如何使用configmap：

通过环境变量的方式直接传递给pod
通过在pod的命令行下运行的方式
作为volume的方式挂载到pod内

3.1.设置环境变量的方式

vi pod.yaml

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
              key: db_host
        - name: key2
          valueFrom:
            configMapKeyRef:
              name: cm1-config
              key: db_port
  restartPolicy: Never

执行pod.yaml文件，查看pod
查看pod的信息之后可以删掉pod1

kubectl apply -f pod.yaml
kubectl get pod

我们可以看到创建节点完成之后就自动退出了

容器执行已完成，在pod日志中查看结果

kubectl logs pod1

使用默认名称
vi pod1.yaml

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

执行文件pod1.yml ，并查看

kubectl apply -f pod1.yaml
kubectl logs pod2

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

vi pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod3
spec:
  containers:
    - name: pod3
      image: busybox
      command: ["/bin/sh", "-c", "cat /config/db_host"]
      volumeMounts:
      - name: config-volume
        mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: cm1-config

  restartPolicy: Never

kubectl apply -f pod2.yaml
kubectl logs pod3

将前面实验的cm删掉：

kubectl get cm
kubectl delete cm my-config
kubectl delete cm my-config-2
kubectl delete cm my-config-3

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

先写入nginx的配置文件nginx.conf，然后创建cm
vi nginx.conf

server {
     
    listen       8000;
    server_name  _;

    location / {
     
        root /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

kubectl create configmap nginxconf --from-file=nginx.conf

编写nginx.yaml
vi nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
          - name: config-volume
            mountPath: /etc/nginx/conf.d
      volumes:
        - name: config-volume
          configMap:
            name: nginxconf

编辑nginxconf的内容修改端口为8080(若执行yaml后编辑则conf会有延迟更新在下面会详细讲解)

kubectl edit cm nginxconf

执行清单nginx.yaml
查看pod信息

kubectl apply -f nginx.yaml
kubectl get pod -o wide

测试访问：
curl 10.244.179.78:8080

再次修改端口为8000

kubectl edit cm nginxconf

listen 8000;

再次访问失败
是因为我们需要刷新一下
刷新有两种办法：
1.
删除pod

kubectl delete  pod my-nginx-b9b58dbdf-hvsn4

因为是deployment所以会再次生成一个pod再次生成一个pod即可通过get pod查找新的ip后访问
2.

 kubectl patch deployments.apps my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20200219"}}}}}'

kubectl get all后发现重新生成rs 说明刷新成功
此时会刷新ip则

kubectl get pod -o wide #查看新ip

curl 10.244.141.198:8000 #访问成功

4.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的认证信息。

4.1Service Account

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

kubectl  run nginx --image=nginx
kubectl  exec -it   nginx  -- bash
cd /var/run/secrets/kubernetes.io/serviceaccount/
ls

查看secrets

kubectl get secrets

查看secrets的信息

kubectl describe secrets default-token-9lq8n

4.2secret应用

4.2.1.5.docker registry

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

kubectl create secret docker-registry myregistrykey --docker-server=reg.westos.org --docker-username=admin --docker-password=westos --docker-email=[email protected]  

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

vi docker.conf

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: game2048
      image: reg.westos.org/westos/game2048
  imagePullSecrets:
    - name: myregistrykey

执行registry.yaml文件。

kubectl apply -f registry.yaml
kubectl get pod
kubectl describe pod 

还有一种方法为

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: game2048
      image: reg.westos.org/westos/game2048
  #imagePullSecrets:
  #  - name: myregistrykey

先注释掉后

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

kubectl apply -f docker.conf
查看pod同样运行成功

5.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

5.1 emptyDir卷

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

emptyDir 的使用场景：

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

5.1.1emptyDir卷创建

mkdir volumes
cd volumes/
vi pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: vol1
spec:
  containers:
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - name: vm2
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      medium: Memory
      sizeLimit: 100Mi

执行pod.yaml文件

kubectl apply -f pod.yaml
kubectl exec -it vol1 -c vm1 -- bash
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
command terminated with exit code 126
[root@server1 volumes]# kubectl exec -it vol1 -c vm1 -- sh
/ # cd /cache/
/cache # ls
/cache # echo www.westos.org > index.html
/cache # curl localhost
www.westos.org

说明资源共享

/cache # dd if=/dev/zero of=bigfile bs=1M count=200
dd: writing 'bigfile': No space left on device
101+0 records in
99+1 records out

可以看到文件超过sizeLimit，则一段时间后（1-2分钟）会被kubelet evict掉。之所以不是“立即”被evict，是因为kubelet是定期进行检查的，这里会有一个时间差。
emptydir缺点：
不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；用户不能及时感知到内存不可用

5.2hostPath 卷

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

hostPath 的一些用法有

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

vi pod2.yaml

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

执行host.yaml文件，并查看pod节点

kubectl apply -f pod2.yaml 
kubectl get pod -o wide

我们在node节点server2上可以看到文件目录自动创建了

5.2.1.结合nfs

共享文件系统nfs使用，首先在所有结点上安装nfs，在仓库结点上配置nfs
在server123安装:

yum install -y nfs-utils

在server5上：

yum install -y nfs-utils
vim /etc/exports
/nfsdata        *(rw,no_root_squash)
systemctl start nfs
showmount -e
mkdir /nfsdata

在server1上
编写清单文件：

vi nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 172.25.76.5
      path: /nfsdata

验证nfs配置是否有误
showmount -e 172.25.76.5
删除之前创建的pod后执行
kubectl apply -f nfs.yaml
kubectl get pod

成功运行