关于kubernetes:上篇一文了解K8S的ConfigMap

39次阅读

共计 4651 个字符,预计需要花费 12 分钟才能阅读完成。

写在开篇

什么是 ConfigMap?

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

ConfigMap 容许将这些数据与应用程序的容器进行解耦,从而使应用程序更加可移植和可配置。通过将配置数据存储在 ConfigMap 中,能够在不批改应用程序容器镜像的状况下,灵便地管理应用程序的配置。

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

官网文档可参考:https://kubernetes.io/zh-cn/docs/concepts/configuration/confi…

总之,ConfigMap 是 Kubernetes 中一种重要的配置管理形式,它能够帮忙咱们更好地管理应用程序的配置和数据。

ConfigMap 的作用是什么?

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

  1. 不足灵活性:在不从新构建和部署容器镜像的状况下,无奈更改应用程序的配置和数据。
  2. 平安问题:在容器镜像中存储敏感信息,如明码和密钥,可能会导致信息泄露的危险。
  3. 环境差别:因为在不同的环境中应用不同的配置和数据,因而在部署到不同的环境时,容器镜像中的配置和数据可能不适用于该环境。

ConfigMap 解决了上述问题。通过应用 ConfigMap,能够将应用程序的配置和数据与容器镜像拆散,并将其存储在 Kubernetes 集群中。这使得在不批改容器镜像的状况下,能够轻松更改应用程序的配置和数据,进步了灵活性和可移植性。此外,通过将敏感信息存储在 ConfigMap 中,而不是在容器镜像中,能够进步应用程序的安全性。最初,通过应用不同的 ConfigMap 来适应不同的环境,能够确保应用程序在不同的环境中具备统一的行为。

创立 ConfigMap

应用 kubectl 命令创立 ConfigMap

  1. 应用 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”
  1. 从文件中创立 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
  1. 从环境变量文件中创立 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

  1. 上面的 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 格局的字符串,其中蕴含了应用程序所需的配置信息。

  1. 上面的文件指定了两个键值对,别离是 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/confi…

以下是官网文档中提到的 4 种形式:

  • 在容器命令和参数内:能够将 ConfigMap 的值间接传递给容器的命令和参数。
  • 容器的环境变量:能够将 ConfigMap 的值注入到容器的环境变量中。
  • 在只读卷外面增加一个文件:能够将 ConfigMap 的值作为文件增加到 Pod 中
  • 编写代码在 Pod 中运行,应用 Kubernetes API 来读取 ConfigMap:能够应用 Kubernetes API 在 Pod 中读取 ConfigMap 的值。

本文转载于 WX 公众号:不背锅运维(喜爱的盆友关注咱们):https://mp.weixin.qq.com/s/7K8S2ebSYKJYxQS47u5iFw

正文完
 0