写在开篇

什么是 ConfigMap？

在 Kubernetes 中，ConfigMap 是一种 API 资源对象，用于存储非密钥/值数据，例如配置文件、环境变量和命令行参数等。

ConfigMap 允许将这些数据与应用程序的容器进行解耦，从而使应用程序更加可移植和可配置。通过将配置数据存储在 ConfigMap 中，可以在不修改应用程序容器镜像的情况下，灵活地管理应用程序的配置。

ConfigMap 可以通过 kubectl 命令或 YAML 文件进行创建、更新和删除。应用程序容器可以通过挂载 ConfigMap，从而访问其中存储的配置数据，也可以将 ConfigMap 中的数据作为环境变量或命令行参数注入到容器中。

官方文档可参考：https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/

❝

总之，ConfigMap 是 Kubernetes 中一种重要的配置管理方式，它可以帮助我们更好地管理应用程序的配置和数据。

❞

ConfigMap 的作用是什么？

ConfigMap 的主要作用是存储应用程序的配置和数据。在 Kubernetes 中，应用程序的配置和数据通常是存储在容器镜像中的文件或环境变量中。但是，将配置和数据硬编码到容器镜像中会导致以下问题：

缺乏灵活性：在不重新构建和部署容器镜像的情况下，无法更改应用程序的配置和数据。
安全问题：在容器镜像中存储敏感信息，如密码和密钥，可能会导致信息泄露的风险。
环境差异：由于在不同的环境中使用不同的配置和数据，因此在部署到不同的环境时，容器镜像中的配置和数据可能不适用于该环境。

ConfigMap 解决了上述问题。通过使用 ConfigMap，可以将应用程序的配置和数据与容器镜像分离，并将其存储在 Kubernetes 集群中。这使得在不修改容器镜像的情况下，可以轻松更改应用程序的配置和数据，提高了灵活性和可移植性。此外，通过将敏感信息存储在 ConfigMap 中，而不是在容器镜像中，可以提高应用程序的安全性。最后，通过使用不同的 ConfigMap 来适应不同的环境，可以确保应用程序在不同的环境中具有一致的行为。

创建 ConfigMap

使用 kubectl 命令创建 ConfigMap

使用kubectl命令行工具创建一个名为“testcm”的ConfigMap资源

[root@k8s-b-master configmap-test]# kubectl create configmap testcm --from-literal=ip=10.1.1.16 --from-literal=hostname=web01
configmap/testcm created

包含两个键值对：

“ip”键的值为“10.1.1.16”
“hostname”键的值为“web01”

从文件中创建 ConfigMap：

# config-files目录下有如下两个配置文件：
[root@k8s-b-master configmap-test]# ls -l config-files/
total 8
-rw-r--r-- 1 root root 45 May  1 22:48 config.yaml
-rw-r--r-- 1 root root 42 May  1 22:47 default.yaml

# 创建名为 my-config 的 ConfigMap，并将 config-files/ 目录中的所有文件添加到其中：
[root@k8s-b-master configmap-test]# kubectl create configmap my-config --from-file=config-files/
configmap/my-config created

从环境变量文件中创建 ConfigMap：

# 准备env-vars.env环境变量文件：
[root@k8s-b-master configmap-test]# cat env-vars.env 
MY_K8S_MASTER_IP=192.168.11.100
MY_K8S_MASTER_HOSTNAME=k8s-b-master

# 从名为 env-vars.env 的环境变量文件中创建名为 my-cf 的 ConfigMap。
[root@k8s-b-master configmap-test]# kubectl create cm my-cf --from-env-file=env-vars.env 
configmap/my-cf created

使用 YAML 文件创建 ConfigMap

下面的 ConfigMap 资源有两个数据项，分别是 “db.yaml” 和 “default.yaml”：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-cm01
data:
  db.yaml: |
    db:
      dbname: cmdb
      dbhost: 10.1.1.19
  default.yaml: |
    web:
      domain: test.noblameops.local
      ip: 10.1.1.10

kubectl create -f my-cm01.yaml

❝

这些数据项本质上是键值对，其中键是文件名，值是一个 YAML 格式的字符串，其中包含了应用程序所需的配置信息。

❞

下面的文件指定了两个键值对，分别是 MY_K8S_MASTER_HOSTNAME 和 MY_K8S_MASTER_IP：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-cm02
data:
  MY_K8S_MASTER_HOSTNAME: k8s-b-master
  MY_K8S_MASTER_IP: 192.168.11.100

kubectl create -f my-cm02.yaml

查看 ConfigMap

使用 kubectl 命令查看 ConfigMap

[root@k8s-b-master configmap-test]# kubectl get configmap
NAME               DATA   AGE
kube-root-ca.crt   1      47h
my-cm01            2      96s
my-cm02            2      9m47s

字段解释：

NAME：ConfigMap 的名称。
DATA：ConfigMap 中包含的数据项数量。
AGE：ConfigMap 创建以来的时间，格式为 d天 h小时 m分钟 s秒。

查看 ConfigMap 的详细信息

[root@k8s-b-master configmap-test]# kubectl describe configmap my-cm02
Name:         my-cm02
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
MY_K8S_MASTER_HOSTNAME:
----
k8s-b-master
MY_K8S_MASTER_IP:
----
192.168.11.100

BinaryData
====

Events:  <none>
[root@k8s-b-master configmap-test]#

部分解释:

Name: my-cm02：ConfigMap 的名称为 my-cm02。
Namespace: default：ConfigMap 所在的命名空间为 default。
Labels:：ConfigMap 没有标签。
Annotations:：ConfigMap 没有注释。
Data：ConfigMap 包含的数据项如下：

MY_K8S_MASTER_HOSTNAME: k8s-b-master：键名为 MY_K8S_MASTER_HOSTNAME，对应的值为 k8s-b-master。
MY_K8S_MASTER_IP: 192.168.11.100：键名为 MY_K8S_MASTER_IP，对应的值为 192.168.11.100。

BinaryData：ConfigMap 中没有二进制数据。
Events:：ConfigMap 没有事件。

删除 ConfigMap

在生产环境中，删除ConfigMap是一件比较危险的事情，需要考虑清楚以下问题：

检查 ConfigMap 是否仍在使用
检查删除操作是否会影响应用程序的运行
确定 ConfigMap 是否存在备份
确定 ConfigMap 是否在版本控制系统中

删除操作很简单，但往往简单的背后都暗藏着“背锅的可能性”，正所谓三思而后行：

[root@k8s-b-master configmap-test]# kubectl delete cm my-cm01
configmap "my-cm01" deleted
[root@k8s-b-master configmap-test]# kubectl delete cm my-cm02
configmap "my-cm02" deleted
[root@k8s-b-master configmap-test]# kubectl delete cm testcm
configmap "testcm" deleted

❝

总之，删除操作在上产环境中是不能随便执行的。那么在删除 ConfigMap 之前，请确保你已经检查过所有相关的事项，并且明确了它们对应用程序和系统的影响。否则，就是有你背锅的时候。

❞

如果你已经很清楚自己在干什么，且已经删除了ConfigMap，那删除之后建议您：

修改应用程序配置：删除后，需要考虑更新应用程序配置以删除对 ConfigMap 的依赖。可以使用 kubectl edit 命令修改 Pod 或其他 Kubernetes 对象的配置，以将它们与 ConfigMap 分离。
跟踪删除 ConfigMap 的影响：如果删除了 ConfigMap，您需要跟踪应用程序是否会受到影响。可以通过查看应用程序的日志来查找任何错误或异常，并使用 kubectl describe 命令查看 Pod 或其他 Kubernetes 对象的详细信息，以确定它们是否正在使用 ConfigMap。

关于下篇

❝

内容太长，担心很多朋友会没有耐心看下去。因此，关于使用ConfigMap的实战内容，我计划放在下篇。那么，下篇的内容我将会分享官方提到的4种使用姿势。

❞

关于使用ConfigMap的更多详情，可提前参考官方文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/#using-configmaps

以下是官方文档中提到的4种方式：

在容器命令和参数内：可以将 ConfigMap 的值直接传递给容器的命令和参数。
容器的环境变量：可以将 ConfigMap 的值注入到容器的环境变量中。
在只读卷里面添加一个文件：可以将 ConfigMap 的值作为文件添加到 Pod 中
编写代码在 Pod 中运行，使用 Kubernetes API 来读取 ConfigMap：可以使用 Kubernetes API 在 Pod 中读取 ConfigMap 的值。