云原生Kubernetes：K8S配置资源管理

一、理论

1.Secret

2.Secret创建

3.Secret使用

4.Configmap

5.Configmap创建

6.Configmap使用

二、实验

1.Secret创建

2.Secret使用

3.Configmap创建

4.Configmap使用

三、问题

1.变量引用生成资源报错

2.查看pod日志失败

3.创建configmap报错

4.YAML创建configmap报错

5. 生成资源报错

6.文件挂载pod报错Error

四、总结

一、理论

1.Secret

(1) 概念

Secret 解决了密码、token、秘钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。这样的信息可能会被放在 Pod 规约中或者镜像中。使用 Secret 意味着你不需要在应用程序代码中包含机密数据。

由于创建 Secret 可以独立于使用它们的 Pod，因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施，例如避免将机密数据写入非易失性存储。

Secret 类似于 ConfigMap但专门用于保存机密数据。

（2）参数

secret 可选参数有三种:

1）generic: 通用类型，通常用于存储密码数据。

2）tls：此类型仅用于存储私钥和证书。

3）docker-registry: 若要保存 docker 仓库的认证信息的话，就必须使用此种类型来创建。

（3）类型

secret 常用类型:

1）Service Account：
用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod的/run/secrets/kubernetes.io/serviceaccount 目录中。

2）Opaque：
base64 编码格式的 Secret，用来存储密码、秘钥等。可以通过 base64 --decode 解码获得原始数据，因此安全性弱。

3）kubernetes.io/dockerconfigjson：
用来存储私有 docker registry 的认证信息。

创建 Secret 时，你可以使用 Secret 资源的 type 字段，或者与其等价的 kubectl 命令行参数（如果有的话）为其设置类型。 Secret 的 type 有助于对不同类型机密数据的编程处理。

Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。

内置类型	用法
`Opaque`	用户定义的任意数据
`kubernetes.io/service-account-token`	服务账号令牌
`kubernetes.io/dockercfg`	`~/.dockercfg` 文件的序列化形式
`kubernetes.io/dockerconfigjson`	`~/.docker/config.json` 文件的序列化形式
`kubernetes.io/basic-auth`	用于基本身份认证的凭据
`kubernetes.io/ssh-auth`	用于 SSH 身份认证的凭据
`kubernetes.io/tls`	用于 TLS 客户端或者服务器端的数据
`bootstrap.kubernetes.io/token`	启动引导令牌数据

通过为 Secret 对象的 type 字段设置一个非空的字符串值，你也可以定义并使用自己 Secret 类型。如果 type 值为空字符串，则被视为 Opaque 类型。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一，则你必须满足为该类型所定义的所有要求。

2.Secret创建

（1）命令行创建

Secret的命令行创建方法与configmap一样，可以通过命令行或者文件/目录的方式创建，这里就不过多介绍，此处使用命名行创建，其它方法可以参照后面的方法进行创建

把 mysql 的 root 用户的 password 创建成 secret

kubectl create secret generic mysql-password --from-literal=password=xy123456
# 查看secret详细信息
kubectl describe secret mysql-password

（2）YAML文件创建

通过手动加密，基于base64加密

echo -n 'admin' | base64
YWRtaW4=
echo -n 'xy123456' | base64
eHkxMjM0NTY=

创建YAML

vim  secret.yaml 

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: eHkxMjM0NTY=

kubectl apply -f secret.yaml 
kubectl get secret
kubectl describe secret mysecret

3.Secret使用

secret使用有2种方法

（1）变量引用

vim secret-pod.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: secretpod
spec:
  containers:
  - name: busybox
    image: busybox
    command: [ "/bin/sh","-c","echo $(SECRET_USERNAME) $(SECRET_PASSWORD)" ]
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

kubectl apply -f secret-pod.yaml 
kubectl get pod
kubectl logs secretpod

（2）文件挂载

将 Secret 挂载到 Volume 中

vim pod_secret_volume.yaml

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

kubectl apply -f pod_secret_volume.yaml 
kubectl get pod
kubectl exec -it secret-volume-pod /bin/bash

进入pod可以看到/etc/secret下有password和username两个文件，查看内容和我们创建的secret内容吻合。

kubectl exec -it secret-volume-pod /bin/bash
root@secret-volume-pod:/# cd /etc/secret
root@secret-volume-pod:/etc/secret# ls
password  username
root@secret-volume-pod:/etc/secret# cat username 
adminroot@secret-volume-pod:/etc/secret# cat password 
xy123456root@secret-volume-pod:/etc/secret# exit
exit

4.Configmap

（1）概念

Configmap 是 k8s 中的资源对象，用于保存非机密性的配置的，数据可以用 key/value 键值对的形式保存，也可通过文件的形式保存。

ConfigMap来替代环境变量，ConfigMap可以被用来填入环境变量; configmap里面的信息读入环境变量，而容器启动的时候可以利用这些环境变量.

ConfigMap是以key:value的形式保存配置项，既可以用于表示一个变量的值（例如config=info），也可以用于表示一个完整配置文件的内容（例如server.xml=<?xml…>…）。

（2）作用

在部署服务的时候，每个服务都有自己的配置文件：

1）如果一台服务器上部署多个服务：nginx、tomcat、apache等，那么这些配置都存在这个节点上

2）假如一台服务器不能满足线上高并发的要求，需要对服务器扩容，扩容之后的服务器还是需要部署多个服务：

3）nginx、tomcat、apache，新增加的服务器上还是要管理这些服务的配置

4）如果有一个服务出现问题，需要修改配置文件，每台物理节点上的配置都需要修改，这种方式肯定满足不了线上大批量的配置变更要求
所以，k8s 中引入了 Configmap资源对象，可以当成 volume 挂载到 pod 中，实现统一的配置管理。

（3）特点

1）Configmap 是 k8s 中的资源， 相当于配置文件，可以有一个或者多个 Configmap；

2）Configmap 可以做成 Volume，k8s pod 启动之后，通过 volume 形式映射到容器内部指定目录上；

3）容器中应用程序按照原有方式读取容器特定目录上的配置文件；

4）在容器看来，配置文件就像是打包在容器内部特定目录，整个过程对应用没有任何侵入。

（4）结构

5.Configmap创建

configmap创建有二种方式，

一是命令行方式，分为从字面读取（--from-literal）和从目录（--from-file）读取。

二是yaml方式。

（1）命令行直接创建

直接在命令行中指定 configmap 参数创建，通过**–from-literal** 指定参数

#创建
kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=nginx
#查看configmap
kubectl describe configmap nginx-config

（2）通过文件/目录创建

通过指定文件创建一个 configmap，–from-file=<文件/目录>

vim nginx.conf
 
server {
 server_name www.nginx.com;
 listen 80;
 root /home/nginx/www/
}

通过指定文件创建

 kubectl create configmap www-nginx --from-file=www=/opt/config/nginx.conf
 kubectl describe configmap www-nginx

通过目录创建

当某些服务存在多个配置文件时，放在同一目录下，我们可以指定目录，进行创建

kubectl create configmap www-nginx2 --from-file=/opt/config/
kubectl describe configmap www-nginx2

（3）YAML创建

 vim nginx_conf.yaml


apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
  labels:
    app: nginx-conf
data:
  nginx.conf: |
    server {
     server_name www.nginx.com;
     listen 80;
     root /home/nginx/www/
    }

6.Configmap使用

（1）新创一个configmap用于测试

apiVersion: v1
kind: ConfigMap
metadata:
  name: test
  labels:
    app: test
data:
  xy: "xuexi"
  hw: "hello world"

kubectl apply -f test.yaml

（2）变量引入

创建一个pod，引用configmap

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: busybox
      image: busybox
      command: [ "/bin/sh", "-c", "echo $(LEVEL) $(TYPE)" ]
      env:
        - name: LEVEL
          valueFrom:
            configMapKeyRef:
              name: test
              key: xy
        - name: TYPE
          valueFrom:
            configMapKeyRef:
              name: test
              key: hw
  restartPolicy: Never

kubectl apply -f pod-configmap.yaml 
kubectl get pod
kubectl logs mypod

（3）文件挂载

apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
    - name: busybox
      image: busybox
      command: [ "/bin/sh","-c","cat /etc/config/hi" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: test
  restartPolicy: Never

#创建pod
kubectl apply -f cm.yaml
#查看pod日志
kubectl logs mypod1

二、实验

1.Secret创建

（1）命令行创建

把 mysql 的 root 用户的 password 创建成 secret

密文类型威Opaque,查询不会显示password的值

（2）YAML文件创建

通过手动加密，基于base64加密

创建YAML

生成资源

查看信息

2.Secret使用

（1）变量引用

生成资源

查看信息

（2）文件挂载

将 Secret 挂载到 Volume 中

生成资源

查看信息

进入pod可以看到/etc/secret下有password和username两个文件，查看内容和我们创建的secret内容吻合。

3.Configmap创建

（1）命令行直接创建

直接在命令行中指定 configmap 参数创建，通过**–from-literal** 指定参数

（2）通过文件/目录创建

通过指定文件创建一个 configmap，–from-file=<文件/目录>

通过指定文件创建

通过目录创建

当某些服务存在多个配置文件时，放在同一目录下，我们可以指定目录，进行创建

（3）YAML创建

生成资源

查看信息

4.Configmap使用

（1）新创一个configmap用于测试

生成资源

（2）变量引入

创建一个pod，引用configmap

输出2个变量，用于测试

LEVEL：定义pod容器内的变量

test为configmap的名称

xw为tes中的key

（3）文件挂载

"cat /etc/config/hi"输出test配置种的key为hw的值

挂载在pod内容器的位置： /etc/config

test为configmap的名称

启动pod并查看pod日志

三、问题

1.变量引用生成资源报错

（1）报错

（2）原因分析

资源类型错误

（3）解决方法

修改前：

修改后：

成功：

2.查看pod日志失败

（1）报错

（2）原因分析

pod还在创建，未启动

（3）解决方法

等待几秒，再次查看

3.创建configmap报错

（1）报错

（2）原因分析

文件名已存在

（3）解决方法

删除已存在文件

4.YAML创建configmap报错

（1）报错

（2）原因分析

配置文件错误

（3）解决方法

修改前：

修改后：

5. 生成资源报错

（1）报错

（2）原因分析

配置文件错误

（3）解决方法

配置文件关键词“ConfigMap”，添加 “|”

修改前：

修改后：

成功：

6.文件挂载pod报错Error

（1）报错

（2）原因分析

配置文件错误

（3）解决方法

修改配置文件

修改前：

修改后：

成功

四、总结

使用secret的基本流程：

1.创建k8s集群
2.创建管理的文件
3.验证
4.解码
5.清理

configmap创建有二种方式，

一是命令行方式，分为从字面读取（--from-literal）和从目录（--from-file）读取。
下面是二者区别：
1.   --from-literal从字面读取的好处就是快速和便捷，你可以通过关键字参数的形式（**kargs），将配置信息直接传递至configmap，然后在pod启动的时候进行加载；同时这个方式的弊端就是，变量不能实时更新到pod容器。

2.   --from-file从目录读取的好处可以实时更新到pod容器。

二是yaml方式。

在容器看来，配置文件就像是打包在容器内部特定目录，整个过程对应用没有任何侵入。