当在K8S中存储配置信息的时候，有多种方式供你选择：Volume挂载、ConfigMap、Secret、自定义CRD，接下来本文将简要介绍上述四种方式的定义以及特点。
Volume
Volume 是一种持久化的存储资源，它可以被挂载到 Pod 中的容器上。
Volume 的特点
-
持久性:
- Volume 在 Pod 的生命周期内是持久存在的。
- 即使 Pod 重启或重新调度，Volume 中的数据也不会丢失。
-
共享性:
- Volume 可以被 Pod 中的多个容器共享。
- 这使得多个容器可以访问相同的数据集。
☝ Volume 的数据并不一定存储在 etcd 中，也可以存储在其他云存储服务中，如 NFS、iSCSI 、AWS EBS等。但是Volume的元数据（如名称、类型、挂载点等）会存储在etcd中，以便 Kubernetes API Server 能够管理和跟踪这些资源。
ConfigMap
ConfigMap 用于存储非敏感的配置信息，数据存储在 etcd 中，以明文形式存储。
ConfigMap的特点
-
键值对形式:
- ConfigMap 存储的数据是以键值对的形式。
- 键通常是一个字符串，而值可以是字符串或二进制数据（Base64 编码的）。
-
持久性:
- ConfigMap 的生命周期与 Pod 的生命周期解耦。
- 即使 Pod 被删除或重建，ConfigMap 仍然存在。
☝ ConfigMap 不仅可以作为环境变量或者命令行参数注入到Pod中，也可以作为 Volume 挂在到Pod当中，以提供相关数据。
Secret
secret 用于存储敏感信息（如密码、密钥等），数据存储在 etcd 中，经过Base64编码后存储。
❗ 目前 Secret 的实现，就是 ConfigMap 把 value 用 base64 encode了一下，所以，其实不存在任何安全性，只要 decode 一下就能出现原来结果，相当于明文存储。如果有安全性的需求，可以引入KMS（Key Management System）服务。
Custom Resource Definition (CRD)
一种让用户可以在 Kubernetes 集群中定义自己的资源类型的机制。通过 CRD，开发者可以扩展 Kubernetes 的 API，以便在集群中管理和操作自定义资源，就像内建的 Kubernetes 资源（如 Pod、Service 等）一样。
CRD的特点
-
结构化数据存储:
- 自定义资源可以根据需求进行复杂的结构定义，支持嵌套对象、数组等，能够描述任意复杂的配置。
-
适应复杂业务场景:
- 在需要处理复杂的配置和逻辑时，可以为每个自定义资源实现一个控制器，控制器可以在 CRD 资源发生变化时执行特定的业务逻辑。具体参考：kubernetes.io/zh-cn/docs/…
☝ 如果你的配置资源比较复杂，或者你希望在操作（增删改）配置资源时触发某些业务逻辑。那么建议使用crd来定义你的配置资源。
